Load cups into easysw/current.

git-svn-id: svn+ssh://src.apple.com/svn/cups/easysw/current@2 a1ca3aef-8c08-0410-bb20-df032aa958be

38 files changed, 88467 insertions, 0 deletions

diff --git a/standards/pwg5100.1.pdf b/standards/pwg5100.1.pdf
new file mode 100644
index 000000000..80260170f
--- /dev/null
+++ b/standards/pwg5100.1.pdf
diff --git a/standards/pwg5100.2.pdf b/standards/pwg5100.2.pdf
new file mode 100644
index 000000000..6b0ad3abc
--- /dev/null
+++ b/standards/pwg5100.2.pdf
diff --git a/standards/pwg5100.3.pdf b/standards/pwg5100.3.pdf
new file mode 100644
index 000000000..0ac46446f
--- /dev/null
+++ b/standards/pwg5100.3.pdf
diff --git a/standards/pwg5100.4.pdf b/standards/pwg5100.4.pdf
new file mode 100644
index 000000000..3d6c0305f
--- /dev/null
+++ b/standards/pwg5100.4.pdf
diff --git a/standards/rfc1179.txt b/standards/rfc1179.txt
new file mode 100644
index 000000000..ef59411f7
--- /dev/null
+++ b/standards/rfc1179.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Printing Working Group                 L. McLaughlin III, Editor
+Request for Comments:  1179                         The Wollongong Group
+                                                             August 1990
+
+
+                      Line Printer Daemon Protocol
+
+Status of this Memo
+
+   This RFC describes an existing print server protocol widely used on
+   the Internet for communicating between line printer daemons (both
+   clients and servers).  This memo is for informational purposes only,
+   and does not specify an Internet standard.  Please refer to the
+   current edition of the "IAB Official Protocol Standards" for the
+   standardization state and status of this protocol.  Distribution of
+   this memo is unlimited.
+
+1. Introduction
+
+   The Berkeley versions of the Unix(tm) operating system provide line
+   printer spooling with a collection of programs: lpr (assign to
+   queue), lpq (display the queue), lprm (remove from queue), and lpc
+   (control the queue).  These programs interact with an autonomous
+   process called the line printer daemon.  This RFC describes the
+   protocols with which a line printer daemon client may control
+   printing.
+
+   This memo is based almost entirely on the work of Robert Knight at
+   Princeton University.  I gratefully acknowledge his efforts in
+   deciphering the UNIX lpr protocol and producing earlier versions of
+   this document.
+
+2. Model of Printing Environment
+
+   A group of hosts request services from a line printer daemon process
+   running on a host.  The services provided by the process are related
+   to printing jobs.  A printing job produces output from one file.
+   Each job will have a unique job number which is between 0 and 999,
+   inclusive.  The jobs are requested by users which have names.  These
+   user names may not start with a digit.
+
+3. Specification of the Protocol
+
+   The specification includes file formats for the control and data
+   files as well as messages used by the protocol.
+
+
+
+
+
+
+McLaughlin                                                      [Page 1]
+
+RFC 1179                          LPR                        August 1990
+
+
+3.1 Message formats
+
+   LPR is a a TCP-based protocol.  The port on which a line printer
+   daemon listens is 515.  The source port must be in the range 721 to
+   731, inclusive.  A line printer daemon responds to commands send to
+   its port.  All commands begin with a single octet code, which is a
+   binary number which represents the requested function.  The code is
+   immediately followed by the ASCII name of the printer queue name on
+   which the function is to be performed.  If there are other operands
+   to the command, they are separated from the printer queue name with
+   white space (ASCII space, horizontal tab, vertical tab, and form
+   feed).  The end of the command is indicated with an ASCII line feed
+   character.
+
+4. Diagram Conventions
+
+   The diagrams in the rest of this RFC use these conventions.  These
+   diagrams show the format of an octet stream sent to the server.  The
+   outermost box represents this stream.  Each box within the outermost
+   one shows one portion of the stream.  If the contents of the box is
+   two decimal digits, this indicates that the binary 8 bit value is to
+   be used.  If the contents is two uppercase letters, this indicates
+   that the corresponding ASCII control character is to be used.  An
+   exception to this is that the character SP can be interpreted as
+   white space.  (See the preceding section for a definition.)  If the
+   contents is a single letter, the ASCII code for this letter must be
+   sent.  Otherwise, the contents are intended to be mnemonic of the
+   contents of the field which is a sequence of octets.
+
+5. Daemon commands
+
+   The verbs in the command names should be interpreted as statements
+   made to the daemon.  Thus, the command "Print any waiting jobs" is an
+   imperative to the line printer daemon to which it is sent.  A new
+   connection must be made for each command to be given to the daemon.
+
+5.1 01 - Print any waiting jobs
+
+      +----+-------+----+
+      | 01 | Queue | LF |
+      +----+-------+----+
+      Command code - 1
+      Operand - Printer queue name
+
+   This command starts the printing process if it not already running.
+
+
+
+
+
+
+McLaughlin                                                      [Page 2]
+
+RFC 1179                          LPR                        August 1990
+
+
+5.2 02 - Receive a printer job
+
+      +----+-------+----+
+      | 02 | Queue | LF |
+      +----+-------+----+
+      Command code - 2
+      Operand - Printer queue name
+
+   Receiving a job is controlled by a second level of commands.  The
+   daemon is given commands by sending them over the same connection.
+   The commands are described in the next section (6).
+
+   After this command is sent, the client must read an acknowledgement
+   octet from the daemon.  A positive acknowledgement is an octet of
+   zero bits.  A negative acknowledgement is an octet of any other
+   pattern.
+
+5.3 03 - Send queue state (short)
+
+      +----+-------+----+------+----+
+      | 03 | Queue | SP | List | LF |
+      +----+-------+----+------+----+
+      Command code - 3
+      Operand 1 - Printer queue name
+      Other operands - User names or job numbers
+
+   If the user names or job numbers or both are supplied then only those
+   jobs for those users or with those numbers will be sent.
+
+   The response is an ASCII stream which describes the printer queue.
+   The stream continues until the connection closes.  Ends of lines are
+   indicated with ASCII LF control characters.  The lines may also
+   contain ASCII HT control characters.
+
+5.4 04 - Send queue state (long)
+
+      +----+-------+----+------+----+
+      | 04 | Queue | SP | List | LF |
+      +----+-------+----+------+----+
+      Command code - 4
+      Operand 1 - Printer queue name
+      Other operands - User names or job numbers
+
+   If the user names or job numbers or both are supplied then only those
+   jobs for those users or with those numbers will be sent.
+
+   The response is an ASCII stream which describes the printer queue.
+   The stream continues until the connection closes.  Ends of lines are
+
+
+
+McLaughlin                                                      [Page 3]
+
+RFC 1179                          LPR                        August 1990
+
+
+   indicated with ASCII LF control characters.  The lines may also
+   contain ASCII HT control characters.
+
+5.5 05 - Remove jobs
+
+      +----+-------+----+-------+----+------+----+
+      | 05 | Queue | SP | Agent | SP | List | LF |
+      +----+-------+----+-------+----+------+----+
+      Command code - 5
+      Operand 1 - Printer queue name
+      Operand 2 - User name making request (the agent)
+      Other operands - User names or job numbers
+
+   This command deletes the print jobs from the specified queue which
+   are listed as the other operands.  If only the agent is given, the
+   command is to delete the currently active job.  Unless the agent is
+   "root", it is not possible to delete a job which is not owned by the
+   user.  This is also the case for specifying user names instead of
+   numbers.  That is, agent "root" can delete jobs by user name but no
+   other agents can.
+
+6. Receive job subcommands
+
+   These commands  are processed when  the line printer  daemon  has
+   been given the  receive job command.  The  daemon will continue  to
+   process commands until the connection is closed.
+
+   After a subcommand is sent, the client must wait for an
+   acknowledgement from the daemon.  A positive acknowledgement is an
+   octet of zero bits.  A negative acknowledgement is an octet of any
+   other pattern.
+
+   LPR clients SHOULD be able to sent the receive data file and receive
+   control file subcommands in either order.  LPR servers MUST be able
+   to receive the control file subcommand first and SHOULD be able to
+   receive the data file subcommand first.
+
+6.1 01 - Abort job
+
+      Command code - 1
+      +----+----+
+      | 01 | LF |
+      +----+----+
+
+   No operands should be supplied.  This subcommand will remove any
+   files which have been created during this "Receive job" command.
+
+
+
+
+
+McLaughlin                                                      [Page 4]
+
+RFC 1179                          LPR                        August 1990
+
+
+6.2 02 - Receive control file
+
+      +----+-------+----+------+----+
+      | 02 | Count | SP | Name | LF |
+      +----+-------+----+------+----+
+      Command code - 2
+      Operand 1 - Number of bytes in control file
+      Operand 2 - Name of control file
+
+   The control file must be an ASCII stream with the ends of lines
+   indicated by ASCII LF.  The total number of bytes in the stream is
+   sent as the first operand.  The name of the control file is sent as
+   the second.  It should start with ASCII "cfA", followed by a three
+   digit job number, followed by the host name which has constructed the
+   control file.  Acknowledgement processing must occur as usual after
+   the command is sent.
+
+   The next "Operand 1" octets over the same TCP connection are the
+   intended contents of the control file.  Once all of the contents have
+   been delivered, an octet of zero bits is sent as an indication that
+   the file being sent is complete.  A second level of acknowledgement
+   processing must occur at this point.
+
+6.3 03 - Receive data file
+
+      +----+-------+----+------+----+
+      | 03 | Count | SP | Name | LF |
+      +----+-------+----+------+----+
+      Command code - 3
+      Operand 1 - Number of bytes in data file
+      Operand 2 - Name of data file
+
+   The data file may contain any 8 bit values at all.  The total number
+   of bytes in the stream may be sent as the first operand, otherwise
+   the field should be cleared to 0.  The name of the data file should
+   start with ASCII "dfA".  This should be followed by a three digit job
+   number.  The job number should be followed by the host name which has
+   constructed the data file.  Interpretation of the contents of the
+   data file is determined by the contents of the corresponding control
+   file.  If a data file length has been specified, the next "Operand 1"
+   octets over the same TCP connection are the intended contents of the
+   data file.  In this case, once all of the contents have been
+   delivered, an octet of zero bits is sent as an indication that the
+   file being sent is complete.  A second level of acknowledgement
+   processing must occur at this point.
+
+
+
+
+
+
+McLaughlin                                                      [Page 5]
+
+RFC 1179                          LPR                        August 1990
+
+
+7. Control file lines
+
+   This section  discusses the format of  the lines in the  control file
+   which is sent to the line printer daemon.
+
+   Each line of the control file consists of a single, printable ASCII
+   character which represents a function to be performed when the file
+   is printed.  Interpretation of these command characters are case-
+   sensitive.  The rest of the line after the command character is the
+   command's operand.  No leading white space is permitted after the
+   command character.  The line ends with an ASCII new line.
+
+   Those commands which have a lower case letter as a command code are
+   used to specify an actual printing request.  The commands which use
+   upper case are used to describe parametric values or background
+   conditions.
+
+   Some commands must be included in every control file.  These are 'H'
+   (responsible host) and 'P' (responsible user).  Additionally, there
+   must be at least one lower case command to produce any output.
+
+7.1 C - Class for banner page
+
+      +---+-------+----+
+      | C | Class | LF |
+      +---+-------+----+
+      Command code - 'C'
+      Operand - Name of class for banner pages
+
+   This command sets the class name to be printed on the banner page.
+   The name must be 31 or fewer octets.  The name can be omitted.  If it
+   is, the name of the host on which the file is printed will be used.
+   The class is conventionally used to display the host from which the
+   printing job originated.  It will be ignored unless the print banner
+   command ('L') is also used.
+
+7.2 H - Host name
+
+      +---+------+----+
+      | H | Host | LF |
+      +---+------+----+
+      Command code - 'H'
+      Operand - Name of host
+
+   This command specifies the name of the host which is to be treated as
+   the source of the print job.  The command must be included in the
+   control file.  The name of the host must be 31 or fewer octets.
+
+
+
+
+McLaughlin                                                      [Page 6]
+
+RFC 1179                          LPR                        August 1990
+
+
+7.3 I - Indent Printing
+
+      +---+-------+----+
+      | I | count | LF |
+      +---+-------+----+
+      Command code - 'I'
+      Operand - Indenting count
+
+   This command specifies that, for files which are printed with the
+   'f', of columns given.  (It is ignored for other output generating
+   commands.)  The identing count operand must be all decimal digits.
+
+7.4 J - Job name for banner page
+
+      +---+----------+----+
+      | J | Job name | LF |
+      +---+----------+----+
+      Command code - 'J'
+      Operand - Job name
+
+   This command sets the job name to be printed on the banner page.  The
+   name of the job must be 99 or fewer octets.  It can be omitted.  The
+   job name is conventionally used to display the name of the file or
+   files which were "printed".  It will be ignored unless the print
+   banner command ('L') is also used.
+
+7.5 L - Print banner page
+
+      +---+------+----+
+      | L | User | LF |
+      +---+------+----+
+      Command code - 'L'
+      Operand - Name of user for burst pages
+
+   This command causes the banner page to be printed.  The user name can
+   be omitted.  The class name for banner page and job name for banner
+   page commands must precede this command in the control file to be
+   effective.
+
+7.6 M - Mail When Printed
+
+      +---+------+----+
+      | M | user | LF |
+      +---+------+----+
+      Command code - 'M'
+      Operand - User name
+
+   This entry causes mail to be sent to the user given as the operand at
+
+
+
+McLaughlin                                                      [Page 7]
+
+RFC 1179                          LPR                        August 1990
+
+
+   the host specified by the 'H' entry when the printing operation ends
+   (successfully or unsuccessfully).
+
+7.7 N - Name of source file
+
+      +---+------+----+
+      | N | Name | LF |
+      +---+------+----+
+      Command code - 'N'
+      Operand - File name
+
+   This command specifies the name of the file from which the data file
+   was constructed.  It is returned on a query and used in printing with
+   the 'p' command when no title has been given.  It must be 131 or
+   fewer octets.
+
+7.8 P - User identification
+
+      +---+------+----+
+      | P | Name | LF |
+      +---+------+----+
+      Command code - 'P'
+      Operand - User id
+
+   This command specifies the user identification of the entity
+   requesting the printing job.  This command must be included in the
+   control file.  The user identification must be 31 or fewer octets.
+
+7.9 S - Symbolic link data
+
+      +---+--------+----+-------+----+
+      | S | device | SP | inode | LF |
+      +---+--------+----+-------+----+
+      Command code - 'S'
+      Operand 1 - Device number
+      Operand 2 - Inode number
+
+   This command is used to record symbolic link data on a Unix system so
+   that changing a file's directory entry after a file is printed will
+   not print the new file.  It is ignored if the data file is not
+   symbolically linked.
+
+
+
+
+
+
+
+
+
+
+McLaughlin                                                      [Page 8]
+
+RFC 1179                          LPR                        August 1990
+
+
+7.10 T - Title for pr
+
+      +---+-------+----+
+      | T | title | LF |
+      +---+-------+----+
+      Command code - 'T'
+      Operand - Title text
+
+   This command provides a title for a file which is to be printed with
+   either the 'p' command.  (It is ignored by all of the other printing
+   commands.)  The title must be 79 or fewer octets.
+
+7.11 U - Unlink data file
+
+      +---+------+----+
+      | U | file | LF |
+      +---+------+----+
+      Command code - 'U'
+      Operand - File to unlink
+
+   This command indicates that the specified file is no longer needed.
+   This should only be used for data files.
+
+7.12 W - Width of output
+
+      +---+-------+----+
+      | W | width | LF |
+      +---+-------+----+
+      Command code - 'W'
+      Operand - Width count
+
+   This command limits the output to the specified number of columns for
+   the 'f', 'l', and 'p' commands.  (It is ignored for other output
+   generating commands.)  The width count operand must be all decimal
+   digits.  It may be silently reduced to some lower value.  The default
+   value for the width is 132.
+
+7.13 1 - troff R font
+
+      +---+------+----+
+      | 1 | file | LF |
+      +---+------+----+
+      Command code - '1'
+      Operand - File name
+
+   This command specifies the file name for the troff R font.  [1] This
+   is the font which is printed using Times Roman by default.
+
+
+
+
+McLaughlin                                                      [Page 9]
+
+RFC 1179                          LPR                        August 1990
+
+
+7.14 2 - troff I font
+
+      +---+------+----+
+      | 2 | file | LF |
+      +---+------+----+
+      Command code - '2'
+      Operand - File name
+
+   This command specifies the file name for the troff I font.  [1] This
+   is the font which is printed using Times Italic by default.
+
+7.15 3 - troff B font
+
+      +---+------+----+
+      | 3 | file | LF |
+      +---+------+----+
+      Command code - '3'
+      Operand - File name
+
+   This command specifies the file name for the troff B font.  [1] This
+   is the font which is printed using Times Bold by default.
+
+7.16 4 - troff S font
+
+      +---+------+----+
+      | 4 | file | LF |
+      +---+------+----+
+      Command code - '4'
+      Operand - File name
+
+   This command specifies the file name for the troff S font.  [1] This
+   is the font which is printed using Special Mathematical Font by
+   default.
+
+7.17 c - Plot CIF file
+
+      +---+------+----+
+      | c | file | LF |
+      +---+------+----+
+      Command code - 'c'
+      Operand - File to plot
+
+   This command causes the data file to be plotted, treating the data as
+   CIF (CalTech Intermediate Form) graphics language. [2]
+
+
+
+
+
+
+
+McLaughlin                                                     [Page 10]
+
+RFC 1179                          LPR                        August 1990
+
+
+7.18 d - Print DVI file
+
+      +---+------+----+
+      | d | file | LF |
+      +---+------+----+
+      Command code - 'd'
+      Operand - File to print
+
+   This command causes the data file to be printed, treating the data as
+   DVI (TeX output). [3]
+
+7.19 f - Print formatted file
+
+      +---+------+----+
+      | f | file | LF |
+      +---+------+----+
+      Command code - 'f'
+      Operand - File to print
+
+   This command cause the data file to be printed as a plain text file,
+   providing page breaks as necessary.  Any ASCII control characters
+   which are not in the following list are discarded: HT, CR, FF, LF,
+   and BS.
+
+7.20 g - Plot file
+
+      +---+------+----+
+      | g | file | LF |
+      +---+------+----+
+      Command code - 'g'
+      Operand - File to plot
+
+   This command causes the data file to be plotted, treating the data as
+   output from the Berkeley Unix plot library. [1]
+
+7.21 k - Reserved for use by Kerberized LPR clients and servers.
+
+7.22 l - Print file leaving control characters
+
+      +---+------+----+
+      | l | file | LF |
+      +---+------+----+
+      Command code - 'l' (lower case L)
+      Operand - File to print
+
+   This command causes the specified data file to printed without
+   filtering the control characters (as is done with the 'f' command).
+
+
+
+
+McLaughlin                                                     [Page 11]
+
+RFC 1179                          LPR                        August 1990
+
+
+7.23 n - Print ditroff output file
+
+      +---+------+----+
+      | n | file | LF |
+      +---+------+----+
+      Command code - 'n'
+      Operand - File to print
+
+   This command prints the data file to be printed, treating the data as
+   ditroff output. [4]
+
+7.24 o - Print Postscript output file
+
+      +---+------+----+
+      | o | file | LF |
+      +---+------+----+
+      Command code - 'o'
+      Operand - File to print
+
+   This command prints the data file to be printed, treating the data as
+   standard Postscript input.
+
+7.25 p - Print file with 'pr' format
+
+      +---+------+----+
+      | p | file | LF |
+      +---+------+----+
+      Command code - 'p'
+      Operand - File to print
+
+   This command causes the data file to be printed with a heading, page
+   numbers, and pagination.  The heading should include the date and
+   time that printing was started, the title, and a page number
+   identifier followed by the page number.  The title is the name of
+   file as specified by the 'N' command, unless the 'T' command (title)
+   has been given.  After a page of text has been printed, a new page is
+   started with a new page number.  (There is no way to specify the
+   length of the page.)
+
+7.26 r - File to print with FORTRAN carriage control
+
+      +---+------+----+
+      | r | file | LF |
+      +---+------+----+
+      Command code - 'r'
+      Operand - File to print
+
+   This command causes the data file to be printed, interpreting the
+
+
+
+McLaughlin                                                     [Page 12]
+
+RFC 1179                          LPR                        August 1990
+
+
+   first column of each line as FORTRAN carriage control.  The FORTRAN
+   standard limits this to blank, "1", "0", and "+" carriage controls.
+   Most FORTRAN programmers also expect "-" (triple space) to work as
+   well.
+
+7.27 t - Print troff output file
+
+      +---+------+----+
+      | t | file | LF |
+      +---+------+----+
+      Command code - 't'
+      Operand - File to print
+
+   This command prints the data file as Graphic Systems C/A/T
+   phototypesetter input.  [5] This is the standard output of the Unix
+   "troff" command.
+
+7.28 v - Print raster file
+
+      +---+------+----+
+      | v | file | LF |
+      +---+------+----+
+      Command code - 'v'
+      Operand - File to print
+
+   This command prints a Sun raster format file. [6]
+
+7.29 z - Reserved for future use with the Palladium print system.
+
+REFERENCES and BIBLIOGRAPHY
+
+   [1] Computer Science Research Group, "UNIX Programmer's Reference
+       Manual", USENIX, 1986.
+
+   [2] Hon and Sequin, "A Guide to LSI Implementation", XEROX PARC,
+       1980.
+
+   [3] Knuth, D., "TeX The Program".
+
+   [4] Kernighan, B., "A Typesetter-independent TROFF".
+
+   [5] "Model C/A/T Phototypesetter", Graphic Systems, Inc. Hudson, N.H.
+
+   [6] Sun Microsystems, "Pixrect Reference Manual", Sun Microsystems,
+       Mountain View, CA, 1988.
+
+
+
+
+
+
+McLaughlin                                                     [Page 13]
+
+RFC 1179                          LPR                        August 1990
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Leo J. McLaughlin III
+   The Wollongong Group
+   1129 San Antonio Road
+   Palo Alto, CA 94303
+
+   Phone: 415-962-7100
+
+   EMail: ljm@twg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McLaughlin                                                     [Page 14]
+
\ No newline at end of file
diff --git a/standards/rfc1321.txt b/standards/rfc1321.txt
new file mode 100644
index 000000000..68af27d2b
--- /dev/null
+++ b/standards/rfc1321.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                          R. Rivest
+Request for Comments: 1321           MIT Laboratory for Computer Science
+                                             and RSA Data Security, Inc.
+                                                              April 1992
+
+
+                     The MD5 Message-Digest Algorithm
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Acknowlegements
+
+   We would like to thank Don Coppersmith, Burt Kaliski, Ralph Merkle,
+   David Chaum, and Noam Nisan for numerous helpful comments and
+   suggestions.
+
+Table of Contents
+
+   1. Executive Summary                                                1
+   2. Terminology and Notation                                         2
+   3. MD5 Algorithm Description                                        3
+   4. Summary                                                          6
+   5. Differences Between MD4 and MD5                                  6
+   References                                                          7
+   APPENDIX A - Reference Implementation                               7
+   Security Considerations                                            21
+   Author's Address                                                   21
+
+1. Executive Summary
+
+   This document describes the MD5 message-digest algorithm. The
+   algorithm takes as input a message of arbitrary length and produces
+   as output a 128-bit "fingerprint" or "message digest" of the input.
+   It is conjectured that it is computationally infeasible to produce
+   two messages having the same message digest, or to produce any
+   message having a given prespecified target message digest. The MD5
+   algorithm is intended for digital signature applications, where a
+   large file must be "compressed" in a secure manner before being
+   encrypted with a private (secret) key under a public-key cryptosystem
+   such as RSA.
+
+
+
+
+
+
+
+Rivest                                                          [Page 1]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+   The MD5 algorithm is designed to be quite fast on 32-bit machines. In
+   addition, the MD5 algorithm does not require any large substitution
+   tables; the algorithm can be coded quite compactly.
+
+   The MD5 algorithm is an extension of the MD4 message-digest algorithm
+   1,2]. MD5 is slightly slower than MD4, but is more "conservative" in
+   design. MD5 was designed because it was felt that MD4 was perhaps
+   being adopted for use more quickly than justified by the existing
+   critical review; because MD4 was designed to be exceptionally fast,
+   it is "at the edge" in terms of risking successful cryptanalytic
+   attack. MD5 backs off a bit, giving up a little in speed for a much
+   greater likelihood of ultimate security. It incorporates some
+   suggestions made by various reviewers, and contains additional
+   optimizations. The MD5 algorithm is being placed in the public domain
+   for review and possible adoption as a standard.
+
+   For OSI-based applications, MD5's object identifier is
+
+   md5 OBJECT IDENTIFIER ::=
+     iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5}
+
+   In the X.509 type AlgorithmIdentifier [3], the parameters for MD5
+   should have type NULL.
+
+2. Terminology and Notation
+
+   In this document a "word" is a 32-bit quantity and a "byte" is an
+   eight-bit quantity. A sequence of bits can be interpreted in a
+   natural manner as a sequence of bytes, where each consecutive group
+   of eight bits is interpreted as a byte with the high-order (most
+   significant) bit of each byte listed first. Similarly, a sequence of
+   bytes can be interpreted as a sequence of 32-bit words, where each
+   consecutive group of four bytes is interpreted as a word with the
+   low-order (least significant) byte given first.
+
+   Let x_i denote "x sub i". If the subscript is an expression, we
+   surround it in braces, as in x_{i+1}. Similarly, we use ^ for
+   superscripts (exponentiation), so that x^i denotes x to the i-th
+   power.
+
+   Let the symbol "+" denote addition of words (i.e., modulo-2^32
+   addition). Let X <<< s denote the 32-bit value obtained by circularly
+   shifting (rotating) X left by s bit positions. Let not(X) denote the
+   bit-wise complement of X, and let X v Y denote the bit-wise OR of X
+   and Y. Let X xor Y denote the bit-wise XOR of X and Y, and let XY
+   denote the bit-wise AND of X and Y.
+
+
+
+
+
+Rivest                                                          [Page 2]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+3. MD5 Algorithm Description
+
+   We begin by supposing that we have a b-bit message as input, and that
+   we wish to find its message digest. Here b is an arbitrary
+   nonnegative integer; b may be zero, it need not be a multiple of
+   eight, and it may be arbitrarily large. We imagine the bits of the
+   message written down as follows:
+
+          m_0 m_1 ... m_{b-1}
+
+   The following five steps are performed to compute the message digest
+   of the message.
+
+3.1 Step 1. Append Padding Bits
+
+   The message is "padded" (extended) so that its length (in bits) is
+   congruent to 448, modulo 512. That is, the message is extended so
+   that it is just 64 bits shy of being a multiple of 512 bits long.
+   Padding is always performed, even if the length of the message is
+   already congruent to 448, modulo 512.
+
+   Padding is performed as follows: a single "1" bit is appended to the
+   message, and then "0" bits are appended so that the length in bits of
+   the padded message becomes congruent to 448, modulo 512. In all, at
+   least one bit and at most 512 bits are appended.
+
+3.2 Step 2. Append Length
+
+   A 64-bit representation of b (the length of the message before the
+   padding bits were added) is appended to the result of the previous
+   step. In the unlikely event that b is greater than 2^64, then only
+   the low-order 64 bits of b are used. (These bits are appended as two
+   32-bit words and appended low-order word first in accordance with the
+   previous conventions.)
+
+   At this point the resulting message (after padding with bits and with
+   b) has a length that is an exact multiple of 512 bits. Equivalently,
+   this message has a length that is an exact multiple of 16 (32-bit)
+   words. Let M[0 ... N-1] denote the words of the resulting message,
+   where N is a multiple of 16.
+
+3.3 Step 3. Initialize MD Buffer
+
+   A four-word buffer (A,B,C,D) is used to compute the message digest.
+   Here each of A, B, C, D is a 32-bit register. These registers are
+   initialized to the following values in hexadecimal, low-order bytes
+   first):
+
+
+
+
+Rivest                                                          [Page 3]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+          word A: 01 23 45 67
+          word B: 89 ab cd ef
+          word C: fe dc ba 98
+          word D: 76 54 32 10
+
+3.4 Step 4. Process Message in 16-Word Blocks
+
+   We first define four auxiliary functions that each take as input
+   three 32-bit words and produce as output one 32-bit word.
+
+          F(X,Y,Z) = XY v not(X) Z
+          G(X,Y,Z) = XZ v Y not(Z)
+          H(X,Y,Z) = X xor Y xor Z
+          I(X,Y,Z) = Y xor (X v not(Z))
+
+   In each bit position F acts as a conditional: if X then Y else Z.
+   The function F could have been defined using + instead of v since XY
+   and not(X)Z will never have 1's in the same bit position.) It is
+   interesting to note that if the bits of X, Y, and Z are independent
+   and unbiased, the each bit of F(X,Y,Z) will be independent and
+   unbiased.
+
+   The functions G, H, and I are similar to the function F, in that they
+   act in "bitwise parallel" to produce their output from the bits of X,
+   Y, and Z, in such a manner that if the corresponding bits of X, Y,
+   and Z are independent and unbiased, then each bit of G(X,Y,Z),
+   H(X,Y,Z), and I(X,Y,Z) will be independent and unbiased. Note that
+   the function H is the bit-wise "xor" or "parity" function of its
+   inputs.
+
+   This step uses a 64-element table T[1 ... 64] constructed from the
+   sine function. Let T[i] denote the i-th element of the table, which
+   is equal to the integer part of 4294967296 times abs(sin(i)), where i
+   is in radians. The elements of the table are given in the appendix.
+
+   Do the following:
+
+   /* Process each 16-word block. */
+   For i = 0 to N/16-1 do
+
+     /* Copy block i into X. */
+     For j = 0 to 15 do
+       Set X[j] to M[i*16+j].
+     end /* of loop on j */
+
+     /* Save A as AA, B as BB, C as CC, and D as DD. */
+     AA = A
+     BB = B
+
+
+
+Rivest                                                          [Page 4]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+     CC = C
+     DD = D
+
+     /* Round 1. */
+     /* Let [abcd k s i] denote the operation
+          a = b + ((a + F(b,c,d) + X[k] + T[i]) <<< s). */
+     /* Do the following 16 operations. */
+     [ABCD  0  7  1]  [DABC  1 12  2]  [CDAB  2 17  3]  [BCDA  3 22  4]
+     [ABCD  4  7  5]  [DABC  5 12  6]  [CDAB  6 17  7]  [BCDA  7 22  8]
+     [ABCD  8  7  9]  [DABC  9 12 10]  [CDAB 10 17 11]  [BCDA 11 22 12]
+     [ABCD 12  7 13]  [DABC 13 12 14]  [CDAB 14 17 15]  [BCDA 15 22 16]
+
+     /* Round 2. */
+     /* Let [abcd k s i] denote the operation
+          a = b + ((a + G(b,c,d) + X[k] + T[i]) <<< s). */
+     /* Do the following 16 operations. */
+     [ABCD  1  5 17]  [DABC  6  9 18]  [CDAB 11 14 19]  [BCDA  0 20 20]
+     [ABCD  5  5 21]  [DABC 10  9 22]  [CDAB 15 14 23]  [BCDA  4 20 24]
+     [ABCD  9  5 25]  [DABC 14  9 26]  [CDAB  3 14 27]  [BCDA  8 20 28]
+     [ABCD 13  5 29]  [DABC  2  9 30]  [CDAB  7 14 31]  [BCDA 12 20 32]
+
+     /* Round 3. */
+     /* Let [abcd k s t] denote the operation
+          a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
+     /* Do the following 16 operations. */
+     [ABCD  5  4 33]  [DABC  8 11 34]  [CDAB 11 16 35]  [BCDA 14 23 36]
+     [ABCD  1  4 37]  [DABC  4 11 38]  [CDAB  7 16 39]  [BCDA 10 23 40]
+     [ABCD 13  4 41]  [DABC  0 11 42]  [CDAB  3 16 43]  [BCDA  6 23 44]
+     [ABCD  9  4 45]  [DABC 12 11 46]  [CDAB 15 16 47]  [BCDA  2 23 48]
+
+     /* Round 4. */
+     /* Let [abcd k s t] denote the operation
+          a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */
+     /* Do the following 16 operations. */
+     [ABCD  0  6 49]  [DABC  7 10 50]  [CDAB 14 15 51]  [BCDA  5 21 52]
+     [ABCD 12  6 53]  [DABC  3 10 54]  [CDAB 10 15 55]  [BCDA  1 21 56]
+     [ABCD  8  6 57]  [DABC 15 10 58]  [CDAB  6 15 59]  [BCDA 13 21 60]
+     [ABCD  4  6 61]  [DABC 11 10 62]  [CDAB  2 15 63]  [BCDA  9 21 64]
+
+     /* Then perform the following additions. (That is increment each
+        of the four registers by the value it had before this block
+        was started.) */
+     A = A + AA
+     B = B + BB
+     C = C + CC
+     D = D + DD
+
+   end /* of loop on i */
+
+
+
+Rivest                                                          [Page 5]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+3.5 Step 5. Output
+
+   The message digest produced as output is A, B, C, D. That is, we
+   begin with the low-order byte of A, and end with the high-order byte
+   of D.
+
+   This completes the description of MD5. A reference implementation in
+   C is given in the appendix.
+
+4. Summary
+
+   The MD5 message-digest algorithm is simple to implement, and provides
+   a "fingerprint" or message digest of a message of arbitrary length.
+   It is conjectured that the difficulty of coming up with two messages
+   having the same message digest is on the order of 2^64 operations,
+   and that the difficulty of coming up with any message having a given
+   message digest is on the order of 2^128 operations. The MD5 algorithm
+   has been carefully scrutinized for weaknesses. It is, however, a
+   relatively new algorithm and further security analysis is of course
+   justified, as is the case with any new proposal of this sort.
+
+5. Differences Between MD4 and MD5
+
+     The following are the differences between MD4 and MD5:
+
+       1.   A fourth round has been added.
+
+       2.   Each step now has a unique additive constant.
+
+       3.   The function g in round 2 was changed from (XY v XZ v YZ) to
+       (XZ v Y not(Z)) to make g less symmetric.
+
+       4.   Each step now adds in the result of the previous step.  This
+       promotes a faster "avalanche effect".
+
+       5.   The order in which input words are accessed in rounds 2 and
+       3 is changed, to make these patterns less like each other.
+
+       6.   The shift amounts in each round have been approximately
+       optimized, to yield a faster "avalanche effect." The shifts in
+       different rounds are distinct.
+
+
+
+
+
+
+
+
+
+
+Rivest                                                          [Page 6]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+References
+
+   [1] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT and
+       RSA Data Security, Inc., April 1992.
+
+   [2] Rivest, R., "The MD4 message digest algorithm", in A.J.  Menezes
+       and S.A. Vanstone, editors, Advances in Cryptology - CRYPTO '90
+       Proceedings, pages 303-311, Springer-Verlag, 1991.
+
+   [3] CCITT Recommendation X.509 (1988), "The Directory -
+       Authentication Framework."
+
+APPENDIX A - Reference Implementation
+
+   This appendix contains the following files taken from RSAREF: A
+   Cryptographic Toolkit for Privacy-Enhanced Mail:
+
+     global.h -- global header file
+
+     md5.h -- header file for MD5
+
+     md5c.c -- source code for MD5
+
+   For more information on RSAREF, send email to <rsaref@rsa.com>.
+
+   The appendix also includes the following file:
+
+     mddriver.c -- test driver for MD2, MD4 and MD5
+
+   The driver compiles for MD5 by default but can compile for MD2 or MD4
+   if the symbol MD is defined on the C compiler command line as 2 or 4.
+
+   The implementation is portable and should work on many different
+   plaforms. However, it is not difficult to optimize the implementation
+   on particular platforms, an exercise left to the reader. For example,
+   on "little-endian" platforms where the lowest-addressed byte in a 32-
+   bit word is the least significant and there are no alignment
+   restrictions, the call to Decode in MD5Transform can be replaced with
+   a typecast.
+
+A.1 global.h
+
+/* GLOBAL.H - RSAREF types and constants
+ */
+
+/* PROTOTYPES should be set to one if and only if the compiler supports
+  function argument prototyping.
+The following makes PROTOTYPES default to 0 if it has not already
+
+
+
+Rivest                                                          [Page 7]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+  been defined with C compiler flags.
+ */
+#ifndef PROTOTYPES
+#define PROTOTYPES 0
+#endif
+
+/* POINTER defines a generic pointer type */
+typedef unsigned char *POINTER;
+
+/* UINT2 defines a two byte word */
+typedef unsigned short int UINT2;
+
+/* UINT4 defines a four byte word */
+typedef unsigned long int UINT4;
+
+/* PROTO_LIST is defined depending on how PROTOTYPES is defined above.
+If using PROTOTYPES, then PROTO_LIST returns the list, otherwise it
+  returns an empty list.
+ */
+#if PROTOTYPES
+#define PROTO_LIST(list) list
+#else
+#define PROTO_LIST(list) ()
+#endif
+
+A.2 md5.h
+
+/* MD5.H - header file for MD5C.C
+ */
+
+/* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
+rights reserved.
+
+License to copy and use this software is granted provided that it
+is identified as the "RSA Data Security, Inc. MD5 Message-Digest
+Algorithm" in all material mentioning or referencing this software
+or this function.
+
+License is also granted to make and use derivative works provided
+that such works are identified as "derived from the RSA Data
+Security, Inc. MD5 Message-Digest Algorithm" in all material
+mentioning or referencing the derived work.
+
+RSA Data Security, Inc. makes no representations concerning either
+the merchantability of this software or the suitability of this
+software for any particular purpose. It is provided "as is"
+without express or implied warranty of any kind.
+
+
+
+
+Rivest                                                          [Page 8]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+These notices must be retained in any copies of any part of this
+documentation and/or software.
+ */
+
+/* MD5 context. */
+typedef struct {
+  UINT4 state[4];                                   /* state (ABCD) */
+  UINT4 count[2];        /* number of bits, modulo 2^64 (lsb first) */
+  unsigned char buffer[64];                         /* input buffer */
+} MD5_CTX;
+
+void MD5Init PROTO_LIST ((MD5_CTX *));
+void MD5Update PROTO_LIST
+  ((MD5_CTX *, unsigned char *, unsigned int));
+void MD5Final PROTO_LIST ((unsigned char [16], MD5_CTX *));
+
+A.3 md5c.c
+
+/* MD5C.C - RSA Data Security, Inc., MD5 message-digest algorithm
+ */
+
+/* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
+rights reserved.
+
+License to copy and use this software is granted provided that it
+is identified as the "RSA Data Security, Inc. MD5 Message-Digest
+Algorithm" in all material mentioning or referencing this software
+or this function.
+
+License is also granted to make and use derivative works provided
+that such works are identified as "derived from the RSA Data
+Security, Inc. MD5 Message-Digest Algorithm" in all material
+mentioning or referencing the derived work.
+
+RSA Data Security, Inc. makes no representations concerning either
+the merchantability of this software or the suitability of this
+software for any particular purpose. It is provided "as is"
+without express or implied warranty of any kind.
+
+These notices must be retained in any copies of any part of this
+documentation and/or software.
+ */
+
+#include "global.h"
+#include "md5.h"
+
+/* Constants for MD5Transform routine.
+ */
+
+
+
+Rivest                                                          [Page 9]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+#define S11 7
+#define S12 12
+#define S13 17
+#define S14 22
+#define S21 5
+#define S22 9
+#define S23 14
+#define S24 20
+#define S31 4
+#define S32 11
+#define S33 16
+#define S34 23
+#define S41 6
+#define S42 10
+#define S43 15
+#define S44 21
+
+static void MD5Transform PROTO_LIST ((UINT4 [4], unsigned char [64]));
+static void Encode PROTO_LIST
+  ((unsigned char *, UINT4 *, unsigned int));
+static void Decode PROTO_LIST
+  ((UINT4 *, unsigned char *, unsigned int));
+static void MD5_memcpy PROTO_LIST ((POINTER, POINTER, unsigned int));
+static void MD5_memset PROTO_LIST ((POINTER, int, unsigned int));
+
+static unsigned char PADDING[64] = {
+  0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+};
+
+/* F, G, H and I are basic MD5 functions.
+ */
+#define F(x, y, z) (((x) & (y)) | ((~x) & (z)))
+#define G(x, y, z) (((x) & (z)) | ((y) & (~z)))
+#define H(x, y, z) ((x) ^ (y) ^ (z))
+#define I(x, y, z) ((y) ^ ((x) | (~z)))
+
+/* ROTATE_LEFT rotates x left n bits.
+ */
+#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32-(n))))
+
+/* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4.
+Rotation is separate from addition to prevent recomputation.
+ */
+#define FF(a, b, c, d, x, s, ac) { \
+ (a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \
+ (a) = ROTATE_LEFT ((a), (s)); \
+
+
+
+Rivest                                                         [Page 10]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+ (a) += (b); \
+  }
+#define GG(a, b, c, d, x, s, ac) { \
+ (a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \
+ (a) = ROTATE_LEFT ((a), (s)); \
+ (a) += (b); \
+  }
+#define HH(a, b, c, d, x, s, ac) { \
+ (a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \
+ (a) = ROTATE_LEFT ((a), (s)); \
+ (a) += (b); \
+  }
+#define II(a, b, c, d, x, s, ac) { \
+ (a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \
+ (a) = ROTATE_LEFT ((a), (s)); \
+ (a) += (b); \
+  }
+
+/* MD5 initialization. Begins an MD5 operation, writing a new context.
+ */
+void MD5Init (context)
+MD5_CTX *context;                                        /* context */
+{
+  context->count[0] = context->count[1] = 0;
+  /* Load magic initialization constants.
+*/
+  context->state[0] = 0x67452301;
+  context->state[1] = 0xefcdab89;
+  context->state[2] = 0x98badcfe;
+  context->state[3] = 0x10325476;
+}
+
+/* MD5 block update operation. Continues an MD5 message-digest
+  operation, processing another message block, and updating the
+  context.
+ */
+void MD5Update (context, input, inputLen)
+MD5_CTX *context;                                        /* context */
+unsigned char *input;                                /* input block */
+unsigned int inputLen;                     /* length of input block */
+{
+  unsigned int i, index, partLen;
+
+  /* Compute number of bytes mod 64 */
+  index = (unsigned int)((context->count[0] >> 3) & 0x3F);
+
+  /* Update number of bits */
+  if ((context->count[0] += ((UINT4)inputLen << 3))
+
+
+
+Rivest                                                         [Page 11]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+   < ((UINT4)inputLen << 3))
+ context->count[1]++;
+  context->count[1] += ((UINT4)inputLen >> 29);
+
+  partLen = 64 - index;
+
+  /* Transform as many times as possible.
+*/
+  if (inputLen >= partLen) {
+ MD5_memcpy
+   ((POINTER)&context->buffer[index], (POINTER)input, partLen);
+ MD5Transform (context->state, context->buffer);
+
+ for (i = partLen; i + 63 < inputLen; i += 64)
+   MD5Transform (context->state, &input[i]);
+
+ index = 0;
+  }
+  else
+ i = 0;
+
+  /* Buffer remaining input */
+  MD5_memcpy
+ ((POINTER)&context->buffer[index], (POINTER)&input[i],
+  inputLen-i);
+}
+
+/* MD5 finalization. Ends an MD5 message-digest operation, writing the
+  the message digest and zeroizing the context.
+ */
+void MD5Final (digest, context)
+unsigned char digest[16];                         /* message digest */
+MD5_CTX *context;                                       /* context */
+{
+  unsigned char bits[8];
+  unsigned int index, padLen;
+
+  /* Save number of bits */
+  Encode (bits, context->count, 8);
+
+  /* Pad out to 56 mod 64.
+*/
+  index = (unsigned int)((context->count[0] >> 3) & 0x3f);
+  padLen = (index < 56) ? (56 - index) : (120 - index);
+  MD5Update (context, PADDING, padLen);
+
+  /* Append length (before padding) */
+  MD5Update (context, bits, 8);
+
+
+
+Rivest                                                         [Page 12]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+  /* Store state in digest */
+  Encode (digest, context->state, 16);
+
+  /* Zeroize sensitive information.
+*/
+  MD5_memset ((POINTER)context, 0, sizeof (*context));
+}
+
+/* MD5 basic transformation. Transforms state based on block.
+ */
+static void MD5Transform (state, block)
+UINT4 state[4];
+unsigned char block[64];
+{
+  UINT4 a = state[0], b = state[1], c = state[2], d = state[3], x[16];
+
+  Decode (x, block, 64);
+
+  /* Round 1 */
+  FF (a, b, c, d, x[ 0], S11, 0xd76aa478); /* 1 */
+  FF (d, a, b, c, x[ 1], S12, 0xe8c7b756); /* 2 */
+  FF (c, d, a, b, x[ 2], S13, 0x242070db); /* 3 */
+  FF (b, c, d, a, x[ 3], S14, 0xc1bdceee); /* 4 */
+  FF (a, b, c, d, x[ 4], S11, 0xf57c0faf); /* 5 */
+  FF (d, a, b, c, x[ 5], S12, 0x4787c62a); /* 6 */
+  FF (c, d, a, b, x[ 6], S13, 0xa8304613); /* 7 */
+  FF (b, c, d, a, x[ 7], S14, 0xfd469501); /* 8 */
+  FF (a, b, c, d, x[ 8], S11, 0x698098d8); /* 9 */
+  FF (d, a, b, c, x[ 9], S12, 0x8b44f7af); /* 10 */
+  FF (c, d, a, b, x[10], S13, 0xffff5bb1); /* 11 */
+  FF (b, c, d, a, x[11], S14, 0x895cd7be); /* 12 */
+  FF (a, b, c, d, x[12], S11, 0x6b901122); /* 13 */
+  FF (d, a, b, c, x[13], S12, 0xfd987193); /* 14 */
+  FF (c, d, a, b, x[14], S13, 0xa679438e); /* 15 */
+  FF (b, c, d, a, x[15], S14, 0x49b40821); /* 16 */
+
+ /* Round 2 */
+  GG (a, b, c, d, x[ 1], S21, 0xf61e2562); /* 17 */
+  GG (d, a, b, c, x[ 6], S22, 0xc040b340); /* 18 */
+  GG (c, d, a, b, x[11], S23, 0x265e5a51); /* 19 */
+  GG (b, c, d, a, x[ 0], S24, 0xe9b6c7aa); /* 20 */
+  GG (a, b, c, d, x[ 5], S21, 0xd62f105d); /* 21 */
+  GG (d, a, b, c, x[10], S22,  0x2441453); /* 22 */
+  GG (c, d, a, b, x[15], S23, 0xd8a1e681); /* 23 */
+  GG (b, c, d, a, x[ 4], S24, 0xe7d3fbc8); /* 24 */
+  GG (a, b, c, d, x[ 9], S21, 0x21e1cde6); /* 25 */
+  GG (d, a, b, c, x[14], S22, 0xc33707d6); /* 26 */
+  GG (c, d, a, b, x[ 3], S23, 0xf4d50d87); /* 27 */
+
+
+
+Rivest                                                         [Page 13]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+  GG (b, c, d, a, x[ 8], S24, 0x455a14ed); /* 28 */
+  GG (a, b, c, d, x[13], S21, 0xa9e3e905); /* 29 */
+  GG (d, a, b, c, x[ 2], S22, 0xfcefa3f8); /* 30 */
+  GG (c, d, a, b, x[ 7], S23, 0x676f02d9); /* 31 */
+  GG (b, c, d, a, x[12], S24, 0x8d2a4c8a); /* 32 */
+
+  /* Round 3 */
+  HH (a, b, c, d, x[ 5], S31, 0xfffa3942); /* 33 */
+  HH (d, a, b, c, x[ 8], S32, 0x8771f681); /* 34 */
+  HH (c, d, a, b, x[11], S33, 0x6d9d6122); /* 35 */
+  HH (b, c, d, a, x[14], S34, 0xfde5380c); /* 36 */
+  HH (a, b, c, d, x[ 1], S31, 0xa4beea44); /* 37 */
+  HH (d, a, b, c, x[ 4], S32, 0x4bdecfa9); /* 38 */
+  HH (c, d, a, b, x[ 7], S33, 0xf6bb4b60); /* 39 */
+  HH (b, c, d, a, x[10], S34, 0xbebfbc70); /* 40 */
+  HH (a, b, c, d, x[13], S31, 0x289b7ec6); /* 41 */
+  HH (d, a, b, c, x[ 0], S32, 0xeaa127fa); /* 42 */
+  HH (c, d, a, b, x[ 3], S33, 0xd4ef3085); /* 43 */
+  HH (b, c, d, a, x[ 6], S34,  0x4881d05); /* 44 */
+  HH (a, b, c, d, x[ 9], S31, 0xd9d4d039); /* 45 */
+  HH (d, a, b, c, x[12], S32, 0xe6db99e5); /* 46 */
+  HH (c, d, a, b, x[15], S33, 0x1fa27cf8); /* 47 */
+  HH (b, c, d, a, x[ 2], S34, 0xc4ac5665); /* 48 */
+
+  /* Round 4 */
+  II (a, b, c, d, x[ 0], S41, 0xf4292244); /* 49 */
+  II (d, a, b, c, x[ 7], S42, 0x432aff97); /* 50 */
+  II (c, d, a, b, x[14], S43, 0xab9423a7); /* 51 */
+  II (b, c, d, a, x[ 5], S44, 0xfc93a039); /* 52 */
+  II (a, b, c, d, x[12], S41, 0x655b59c3); /* 53 */
+  II (d, a, b, c, x[ 3], S42, 0x8f0ccc92); /* 54 */
+  II (c, d, a, b, x[10], S43, 0xffeff47d); /* 55 */
+  II (b, c, d, a, x[ 1], S44, 0x85845dd1); /* 56 */
+  II (a, b, c, d, x[ 8], S41, 0x6fa87e4f); /* 57 */
+  II (d, a, b, c, x[15], S42, 0xfe2ce6e0); /* 58 */
+  II (c, d, a, b, x[ 6], S43, 0xa3014314); /* 59 */
+  II (b, c, d, a, x[13], S44, 0x4e0811a1); /* 60 */
+  II (a, b, c, d, x[ 4], S41, 0xf7537e82); /* 61 */
+  II (d, a, b, c, x[11], S42, 0xbd3af235); /* 62 */
+  II (c, d, a, b, x[ 2], S43, 0x2ad7d2bb); /* 63 */
+  II (b, c, d, a, x[ 9], S44, 0xeb86d391); /* 64 */
+
+  state[0] += a;
+  state[1] += b;
+  state[2] += c;
+  state[3] += d;
+
+  /* Zeroize sensitive information.
+
+
+
+Rivest                                                         [Page 14]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+*/
+  MD5_memset ((POINTER)x, 0, sizeof (x));
+}
+
+/* Encodes input (UINT4) into output (unsigned char). Assumes len is
+  a multiple of 4.
+ */
+static void Encode (output, input, len)
+unsigned char *output;
+UINT4 *input;
+unsigned int len;
+{
+  unsigned int i, j;
+
+  for (i = 0, j = 0; j < len; i++, j += 4) {
+ output[j] = (unsigned char)(input[i] & 0xff);
+ output[j+1] = (unsigned char)((input[i] >> 8) & 0xff);
+ output[j+2] = (unsigned char)((input[i] >> 16) & 0xff);
+ output[j+3] = (unsigned char)((input[i] >> 24) & 0xff);
+  }
+}
+
+/* Decodes input (unsigned char) into output (UINT4). Assumes len is
+  a multiple of 4.
+ */
+static void Decode (output, input, len)
+UINT4 *output;
+unsigned char *input;
+unsigned int len;
+{
+  unsigned int i, j;
+
+  for (i = 0, j = 0; j < len; i++, j += 4)
+ output[i] = ((UINT4)input[j]) | (((UINT4)input[j+1]) << 8) |
+   (((UINT4)input[j+2]) << 16) | (((UINT4)input[j+3]) << 24);
+}
+
+/* Note: Replace "for loop" with standard memcpy if possible.
+ */
+
+static void MD5_memcpy (output, input, len)
+POINTER output;
+POINTER input;
+unsigned int len;
+{
+  unsigned int i;
+
+  for (i = 0; i < len; i++)
+
+
+
+Rivest                                                         [Page 15]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+ output[i] = input[i];
+}
+
+/* Note: Replace "for loop" with standard memset if possible.
+ */
+static void MD5_memset (output, value, len)
+POINTER output;
+int value;
+unsigned int len;
+{
+  unsigned int i;
+
+  for (i = 0; i < len; i++)
+ ((char *)output)[i] = (char)value;
+}
+
+A.4 mddriver.c
+
+/* MDDRIVER.C - test driver for MD2, MD4 and MD5
+ */
+
+/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All
+rights reserved.
+
+RSA Data Security, Inc. makes no representations concerning either
+the merchantability of this software or the suitability of this
+software for any particular purpose. It is provided "as is"
+without express or implied warranty of any kind.
+
+These notices must be retained in any copies of any part of this
+documentation and/or software.
+ */
+
+/* The following makes MD default to MD5 if it has not already been
+  defined with C compiler flags.
+ */
+#ifndef MD
+#define MD MD5
+#endif
+
+#include <stdio.h>
+#include <time.h>
+#include <string.h>
+#include "global.h"
+#if MD == 2
+#include "md2.h"
+#endif
+#if MD == 4
+
+
+
+Rivest                                                         [Page 16]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+#include "md4.h"
+#endif
+#if MD == 5
+#include "md5.h"
+#endif
+
+/* Length of test block, number of test blocks.
+ */
+#define TEST_BLOCK_LEN 1000
+#define TEST_BLOCK_COUNT 1000
+
+static void MDString PROTO_LIST ((char *));
+static void MDTimeTrial PROTO_LIST ((void));
+static void MDTestSuite PROTO_LIST ((void));
+static void MDFile PROTO_LIST ((char *));
+static void MDFilter PROTO_LIST ((void));
+static void MDPrint PROTO_LIST ((unsigned char [16]));
+
+#if MD == 2
+#define MD_CTX MD2_CTX
+#define MDInit MD2Init
+#define MDUpdate MD2Update
+#define MDFinal MD2Final
+#endif
+#if MD == 4
+#define MD_CTX MD4_CTX
+#define MDInit MD4Init
+#define MDUpdate MD4Update
+#define MDFinal MD4Final
+#endif
+#if MD == 5
+#define MD_CTX MD5_CTX
+#define MDInit MD5Init
+#define MDUpdate MD5Update
+#define MDFinal MD5Final
+#endif
+
+/* Main driver.
+
+Arguments (may be any combination):
+  -sstring - digests string
+  -t       - runs time trial
+  -x       - runs test script
+  filename - digests file
+  (none)   - digests standard input
+ */
+int main (argc, argv)
+int argc;
+
+
+
+Rivest                                                         [Page 17]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+char *argv[];
+{
+  int i;
+
+  if (argc > 1)
+ for (i = 1; i < argc; i++)
+   if (argv[i][0] == '-' && argv[i][1] == 's')
+     MDString (argv[i] + 2);
+   else if (strcmp (argv[i], "-t") == 0)
+     MDTimeTrial ();
+   else if (strcmp (argv[i], "-x") == 0)
+     MDTestSuite ();
+   else
+     MDFile (argv[i]);
+  else
+ MDFilter ();
+
+  return (0);
+}
+
+/* Digests a string and prints the result.
+ */
+static void MDString (string)
+char *string;
+{
+  MD_CTX context;
+  unsigned char digest[16];
+  unsigned int len = strlen (string);
+
+  MDInit (&context);
+  MDUpdate (&context, string, len);
+  MDFinal (digest, &context);
+
+  printf ("MD%d (\"%s\") = ", MD, string);
+  MDPrint (digest);
+  printf ("\n");
+}
+
+/* Measures the time to digest TEST_BLOCK_COUNT TEST_BLOCK_LEN-byte
+  blocks.
+ */
+static void MDTimeTrial ()
+{
+  MD_CTX context;
+  time_t endTime, startTime;
+  unsigned char block[TEST_BLOCK_LEN], digest[16];
+  unsigned int i;
+
+
+
+
+Rivest                                                         [Page 18]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+  printf
+ ("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
+  TEST_BLOCK_LEN, TEST_BLOCK_COUNT);
+
+  /* Initialize block */
+  for (i = 0; i < TEST_BLOCK_LEN; i++)
+ block[i] = (unsigned char)(i & 0xff);
+
+  /* Start timer */
+  time (&startTime);
+
+  /* Digest blocks */
+  MDInit (&context);
+  for (i = 0; i < TEST_BLOCK_COUNT; i++)
+ MDUpdate (&context, block, TEST_BLOCK_LEN);
+  MDFinal (digest, &context);
+
+  /* Stop timer */
+  time (&endTime);
+
+  printf (" done\n");
+  printf ("Digest = ");
+  MDPrint (digest);
+  printf ("\nTime = %ld seconds\n", (long)(endTime-startTime));
+  printf
+ ("Speed = %ld bytes/second\n",
+  (long)TEST_BLOCK_LEN * (long)TEST_BLOCK_COUNT/(endTime-startTime));
+}
+
+/* Digests a reference suite of strings and prints the results.
+ */
+static void MDTestSuite ()
+{
+  printf ("MD%d test suite:\n", MD);
+
+  MDString ("");
+  MDString ("a");
+  MDString ("abc");
+  MDString ("message digest");
+  MDString ("abcdefghijklmnopqrstuvwxyz");
+  MDString
+ ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789");
+  MDString
+ ("1234567890123456789012345678901234567890\
+1234567890123456789012345678901234567890");
+}
+
+/* Digests a file and prints the result.
+
+
+
+Rivest                                                         [Page 19]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+ */
+static void MDFile (filename)
+char *filename;
+{
+  FILE *file;
+  MD_CTX context;
+  int len;
+  unsigned char buffer[1024], digest[16];
+
+  if ((file = fopen (filename, "rb")) == NULL)
+ printf ("%s can't be opened\n", filename);
+
+  else {
+ MDInit (&context);
+ while (len = fread (buffer, 1, 1024, file))
+   MDUpdate (&context, buffer, len);
+ MDFinal (digest, &context);
+
+ fclose (file);
+
+ printf ("MD%d (%s) = ", MD, filename);
+ MDPrint (digest);
+ printf ("\n");
+  }
+}
+
+/* Digests the standard input and prints the result.
+ */
+static void MDFilter ()
+{
+  MD_CTX context;
+  int len;
+  unsigned char buffer[16], digest[16];
+
+  MDInit (&context);
+  while (len = fread (buffer, 1, 16, stdin))
+ MDUpdate (&context, buffer, len);
+  MDFinal (digest, &context);
+
+  MDPrint (digest);
+  printf ("\n");
+}
+
+/* Prints a message digest in hexadecimal.
+ */
+static void MDPrint (digest)
+unsigned char digest[16];
+{
+
+
+
+Rivest                                                         [Page 20]
+
+RFC 1321              MD5 Message-Digest Algorithm            April 1992
+
+
+  unsigned int i;
+
+  for (i = 0; i < 16; i++)
+ printf ("%02x", digest[i]);
+}
+
+A.5 Test suite
+
+   The MD5 test suite (driver option "-x") should print the following
+   results:
+
+MD5 test suite:
+MD5 ("") = d41d8cd98f00b204e9800998ecf8427e
+MD5 ("a") = 0cc175b9c0f1b6a831c399e269772661
+MD5 ("abc") = 900150983cd24fb0d6963f7d28e17f72
+MD5 ("message digest") = f96b697d7cb7938d525a2f31aaf161d0
+MD5 ("abcdefghijklmnopqrstuvwxyz") = c3fcd3d76192e4007dfb496cca67e13b
+MD5 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =
+d174ab98d277d9f5a5611c2c9f419d9f
+MD5 ("123456789012345678901234567890123456789012345678901234567890123456
+78901234567890") = 57edf4a22be3c955ac49da2e2107b67a
+
+Security Considerations
+
+   The level of security discussed in this memo is considered to be
+   sufficient for implementing very high security hybrid digital-
+   signature schemes based on MD5 and a public-key cryptosystem.
+
+Author's Address
+
+   Ronald L. Rivest
+   Massachusetts Institute of Technology
+   Laboratory for Computer Science
+   NE43-324
+   545 Technology Square
+   Cambridge, MA  02139-1986
+
+   Phone: (617) 253-5880
+   EMail: rivest@theory.lcs.mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Rivest                                                         [Page 21]
+
\ No newline at end of file
diff --git a/standards/rfc2222.txt b/standards/rfc2222.txt
new file mode 100644
index 000000000..2b0a2abc1
--- /dev/null
+++ b/standards/rfc2222.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2222                       Netscape Communications
+Category: Standards Track                                   October 1997
+
+
+            Simple Authentication and Security Layer (SASL)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+Table of Contents
+
+   1.    Abstract ..............................................    2
+   2.    Organization of this Document .........................    2
+   2.1.  How to Read This Document .............................    2
+   2.2.  Conventions Used in this Document .....................    2
+   2.3.  Examples ..............................................    3
+   3.    Introduction and Overview .............................    3
+   4.    Profiling requirements ................................    4
+   5.    Specific issues .......................................    5
+   5.1.  Client sends data first ...............................    5
+   5.2.  Server returns success with additional data ...........    5
+   5.3.  Multiple authentications ..............................    5
+   6.    Registration procedures ...............................    6
+   6.1.  Comments on SASL mechanism registrations ..............    6
+   6.2.  Location of Registered SASL Mechanism List ............    6
+   6.3.  Change Control ........................................    7
+   6.4.  Registration Template .................................    7
+   7.    Mechanism definitions .................................    8
+   7.1.  Kerberos version 4 mechanism ..........................    8
+   7.2.  GSSAPI mechanism ......................................    9
+   7.2.1 Client side of authentication protocol exchange .......    9
+   7.2.2 Server side of authentication protocol exchange .......   10
+   7.2.3 Security layer ........................................   11
+   7.3.  S/Key mechanism .......................................   11
+   7.4.  External mechanism ....................................   12
+   8.    References ............................................   13
+   9.    Security Considerations ...............................   13
+   10.   Author's Address ......................................   14
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2222                          SASL                      October 1997
+
+
+   Appendix A. Relation of SASL to Transport Security ..........   15
+   Full Copyright Statement ....................................   16
+
+1.    Abstract
+
+   This document describes a method for adding authentication support to
+   connection-based protocols.  To use this specification, a protocol
+   includes a command for identifying and authenticating a user to a
+   server and for optionally negotiating protection of subsequent
+   protocol interactions.  If its use is negotiated, a security layer is
+   inserted between the protocol and the connection.  This document
+   describes how a protocol specifies such a command, defines several
+   mechanisms for use by the command, and defines the protocol used for
+   carrying a negotiated security layer over the connection.
+
+2.    Organization of this Document
+
+2.1.  How to Read This Document
+
+   This document is written to serve two different audiences, protocol
+   designers using this specification to support authentication in their
+   protocol, and implementors of clients or servers for those protocols
+   using this specification.
+
+   The sections "Introduction and Overview", "Profiling requirements",
+   and "Security Considerations" cover issues that protocol designers
+   need to understand and address in profiling this specification for
+   use in a specific protocol.
+
+   Implementors of a protocol using this specification need the
+   protocol-specific profiling information in addition to the
+   information in this document.
+
+2.2.  Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2222                          SASL                      October 1997
+
+
+2.3.  Examples
+
+   Examples in this document are for the IMAP profile [RFC 2060] of this
+   specification.  The base64 encoding of challenges and responses, as
+   well as the "+ " preceding the responses are part of the IMAP4
+   profile, not part of the SASL specification itself.
+
+3.    Introduction and Overview
+
+   The Simple Authentication and Security Layer (SASL) is a method for
+   adding authentication support to connection-based protocols.  To use
+   this specification, a protocol includes a command for identifying and
+   authenticating a user to a server and for optionally negotiating a
+   security layer for subsequent protocol interactions.
+
+   The command has a required argument identifying a SASL mechanism.
+   SASL mechanisms are named by strings, from 1 to 20 characters in
+   length, consisting of upper-case letters, digits, hyphens, and/or
+   underscores.  SASL mechanism names must be registered with the IANA.
+   Procedures for registering new SASL mechanisms are given in the
+   section "Registration procedures"
+
+   If a server supports the requested mechanism, it initiates an
+   authentication protocol exchange.  This consists of a series of
+   server challenges and client responses that are specific to the
+   requested mechanism.  The challenges and responses are defined by the
+   mechanisms as binary tokens of arbitrary length.  The protocol's
+   profile then specifies how these binary tokens are then encoded for
+   transfer over the connection.
+
+   After receiving the authentication command or any client response, a
+   server may issue a challenge, indicate failure, or indicate
+   completion.  The protocol's profile specifies how the server
+   indicates which of the above it is doing.
+
+   After receiving a challenge, a client may issue a response or abort
+   the exchange.  The protocol's profile specifies how the client
+   indicates which of the above it is doing.
+
+   During the authentication protocol exchange, the mechanism performs
+   authentication, transmits an authorization identity (frequently known
+   as a userid) from the client to server, and negotiates the use of a
+   mechanism-specific security layer.  If the use of a security layer is
+   agreed upon, then the mechanism must also define or negotiate the
+   maximum cipher-text buffer size that each side is able to receive.
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2222                          SASL                      October 1997
+
+
+   The transmitted authorization identity may be different than the
+   identity in the client's authentication credentials.  This permits
+   agents such as proxy servers to authenticate using their own
+   credentials, yet request the access privileges of the identity for
+   which they are proxying.  With any mechanism, transmitting an
+   authorization identity of the empty string directs the server to
+   derive an authorization identity from the client's authentication
+   credentials.
+
+   If use of a security layer is negotiated, it is applied to all
+   subsequent data sent over the connection.  The security layer takes
+   effect immediately following the last response of the authentication
+   exchange for data sent by the client and the completion indication
+   for data sent by the server.  Once the security layer is in effect,
+   the protocol stream is processed by the security layer into buffers
+   of cipher-text.  Each buffer is transferred over the connection as a
+   stream of octets prepended with a four octet field in network byte
+   order that represents the length of the following buffer.  The length
+   of the cipher-text buffer must be no larger than the maximum size
+   that was defined or negotiated by the other side.
+
+4.    Profiling requirements
+
+   In order to use this specification, a protocol definition must supply
+   the following information:
+
+   1. A service name, to be selected from the IANA registry of "service"
+      elements for the GSSAPI host-based service name form [RFC 2078].
+
+   2. A definition of the command to initiate the authentication
+      protocol exchange.  This command must have as a parameter the
+      mechanism name being selected by the client.
+
+      The command SHOULD have an optional parameter giving an initial
+      response.  This optional parameter allows the client to avoid a
+      round trip when using a mechanism which is defined to have the
+      client send data first.  When this initial response is sent by the
+      client and the selected mechanism is defined to have the server
+      start with an initial challenge, the command fails.  See section
+      5.1 of this document for further information.
+
+   3. A definition of the method by which the authentication protocol
+      exchange is carried out, including how the challenges and
+      responses are encoded, how the server indicates completion or
+      failure of the exchange, how the client aborts an exchange, and
+      how the exchange method interacts with any line length limits in
+      the protocol.
+
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2222                          SASL                      October 1997
+
+
+   4. Identification of the octet where any negotiated security layer
+      starts to take effect, in both directions.
+
+   5. A specification of how the authorization identity passed from the
+      client to the server is to be interpreted.
+
+5.    Specific issues
+
+5.1.  Client sends data first
+
+   Some mechanisms specify that the first data sent in the
+   authentication protocol exchange is from the client to the server.
+
+   If a protocol's profile permits the command which initiates an
+   authentication protocol exchange to contain an initial client
+   response, this parameter SHOULD be used with such mechanisms.
+
+   If the initial client response parameter is not given, or if a
+   protocol's profile does not permit the command which initiates an
+   authentication protocol exchange to contain an initial client
+   response, then the server issues a challenge with no data.  The
+   client's response to this challenge is then used as the initial
+   client response.  (The server then proceeds to send the next
+   challenge, indicates completion, or indicates failure.)
+
+5.2.  Server returns success with additional data
+
+   Some mechanisms may specify that server challenge data be sent to the
+   client along with an indication of successful completion of the
+   exchange.  This data would, for example, authenticate the server to
+   the client.
+
+   If a protocol's profile does not permit this server challenge to be
+   returned with a success indication, then the server issues the server
+   challenge without an indication of successful completion.  The client
+   then responds with no data.  After receiving this empty response, the
+   server then indicates successful completion.
+
+5.3.  Multiple authentications
+
+   Unless otherwise stated by the protocol's profile, only one
+   successful SASL negotiation may occur in a protocol session.  In this
+   case, once an authentication protocol exchange has successfully
+   completed, further attempts to initiate an authentication protocol
+   exchange fail.
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
+RFC 2222                          SASL                      October 1997
+
+
+   In the case that a profile explicitly permits multiple successful
+   SASL negotiations to occur, then in no case may multiple security
+   layers be simultaneously in effect.  If a security layer is in effect
+   and a subsequent SASL negotiation selects no security layer, the
+   original security layer remains in effect.  If a security layer is in
+   effect and a subsequent SASL negotiation selects a second security
+   layer, then the second security layer replaces the first.
+
+6.    Registration procedures
+
+   Registration of a SASL mechanism is done by filling in the template
+   in section 6.4 and sending it in to iana@isi.edu.  IANA has the right
+   to reject obviously bogus registrations, but will perform no review
+   of clams made in the registration form.
+
+   There is no naming convention for SASL mechanisms; any name that
+   conforms to the syntax of a SASL mechanism name can be registered.
+
+   While the registration procedures do not require it, authors of SASL
+   mechanisms are encouraged to seek community review and comment
+   whenever that is feasible.  Authors may seek community review by
+   posting a specification of their proposed mechanism as an internet-
+   draft.  SASL mechanisms intended for widespread use should be
+   standardized through the normal IETF process, when appropriate.
+
+6.1.  Comments on SASL mechanism registrations
+
+   Comments on registered SASL mechanisms should first be sent to the
+   "owner" of the mechanism.  Submitters of comments may, after a
+   reasonable attempt to contact the owner, request IANA to attach their
+   comment to the SASL mechanism registration itself.  If IANA approves
+   of this the comment will be made accessible in conjunction with the
+   SASL mechanism registration itself.
+
+6.2.  Location of Registered SASL Mechanism List
+
+   SASL mechanism registrations will be posted in the anonymous FTP
+   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-
+   mechanisms/" and all registered SASL mechanisms will be listed in the
+   periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
+   1700].  The SASL mechanism description and other supporting material
+   may also be published as an Informational RFC by sending it to "rfc-
+   editor@isi.edu" (please follow the instructions to RFC authors [RFC
+   2223]).
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 6]
+
+RFC 2222                          SASL                      October 1997
+
+
+6.3.  Change Control
+
+   Once a SASL mechanism registration has been published by IANA, the
+   author may request a change to its definition.  The change request
+   follows the same procedure as the registration request.
+
+   The owner of a SASL mechanism may pass responsibility for the SASL
+   mechanism to another person or agency by informing IANA; this can be
+   done without discussion or review.
+
+   The IESG may reassign responsibility for a SASL mechanism. The most
+   common case of this will be to enable changes to be made to
+   mechanisms where the author of the registration has died, moved out
+   of contact or is otherwise unable to make changes that are important
+   to the community.
+
+   SASL mechanism registrations may not be deleted; mechanisms which are
+   no longer believed appropriate for use can be declared OBSOLETE by a
+   change to their "intended use" field; such SASL mechanisms will be
+   clearly marked in the lists published by IANA.
+
+   The IESG is considered to be the owner of all SASL mechanisms which
+   are on the IETF standards track.
+
+6.4.  Registration Template
+
+   To: iana@iana.org
+   Subject: Registration of SASL mechanism X
+
+   SASL mechanism name:
+
+   Security considerations:
+
+   Published specification (optional, recommended):
+
+   Person & email address to contact for further information:
+
+   Intended usage:
+
+   (One of COMMON, LIMITED USE or OBSOLETE)
+
+   Author/Change controller:
+
+   (Any other information that the author deems interesting may be
+   added below this line.)
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 7]
+
+RFC 2222                          SASL                      October 1997
+
+
+7.    Mechanism definitions
+
+   The following mechanisms are hereby defined.
+
+7.1.  Kerberos version 4 mechanism
+
+   The mechanism name associated with Kerberos version 4 is
+   "KERBEROS_V4".
+
+   The first challenge consists of a random 32-bit number in network
+   byte order.  The client responds with a Kerberos ticket and an
+   authenticator for the principal "service.hostname@realm", where
+   "service" is the service name specified in the protocol's profile,
+   "hostname" is the first component of the host name of the server with
+   all letters in lower case, and where "realm" is the Kerberos realm of
+   the server.  The encrypted checksum field included within the
+   Kerberos authenticator contains the server provided challenge in
+   network byte order.
+
+   Upon decrypting and verifying the ticket and authenticator, the
+   server verifies that the contained checksum field equals the original
+   server provided random 32-bit number.  Should the verification be
+   successful, the server must add one to the checksum and construct 8
+   octets of data, with the first four octets containing the incremented
+   checksum in network byte order, the fifth octet containing a bit-mask
+   specifying the security layers supported by the server, and the sixth
+   through eighth octets containing, in network byte order, the maximum
+   cipher-text buffer size the server is able to receive.  The server
+   must encrypt using DES ECB mode the 8 octets of data in the session
+   key and issue that encrypted data in a second challenge.  The client
+   considers the server authenticated if the first four octets of the
+   un-encrypted data is equal to one plus the checksum it previously
+   sent.
+
+   The client must construct data with the first four octets containing
+   the original server-issued checksum in network byte order, the fifth
+   octet containing the bit-mask specifying the selected security layer,
+   the sixth through eighth octets containing in network byte order the
+   maximum cipher-text buffer size the client is able to receive, and
+   the following octets containing the authorization identity.  The
+   client must then append from one to eight zero-valued octets so that
+   the length of the data is a multiple of eight octets. The client must
+   then encrypt using DES PCBC mode the data with the session key and
+   respond with the encrypted data.  The server decrypts the data and
+   verifies the contained checksum.  The server must verify that the
+   principal identified in the Kerberos ticket is authorized to connect
+   as that authorization identity.  After this verification, the
+   authentication process is complete.
+
+
+
+Myers                       Standards Track                     [Page 8]
+
+RFC 2222                          SASL                      October 1997
+
+
+   The security layers and their corresponding bit-masks are as follows:
+
+      1 No security layer
+      2 Integrity (krb_mk_safe) protection
+      4 Privacy (krb_mk_priv) protection
+
+   Other bit-masks may be defined in the future; bits which are not
+   understood must be negotiated off.
+
+   EXAMPLE: The following are two Kerberos version 4 login scenarios to
+   the IMAP4 protocol (note that the line breaks in the sample
+   authenticators are for editorial clarity and are not in real
+   authenticators)
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE KERBEROS_V4
+     S: + AmFYig==
+     C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+        +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+        WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+     S: + or//EoAADZI=
+     C: DiAF5A4gA+oOIALuBkAAmw==
+     S: A001 OK Kerberos V4 authentication successful
+
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE KERBEROS_V4
+     S: + gcfgCA==
+     C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+        +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+        WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+     S: A001 NO Kerberos V4 authentication failed
+
+7.2.  GSSAPI mechanism
+
+   The mechanism name associated with all mechanisms employing the
+   GSSAPI [RFC 2078] is "GSSAPI".
+
+7.2.1 Client side of authentication protocol exchange
+
+   The client calls GSS_Init_sec_context, passing in 0 for
+   input_context_handle (initially) and a targ_name equal to output_name
+   from GSS_Import_Name called with input_name_type of
+   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
+   "service@hostname" where "service" is the service name specified in
+   the protocol's profile, and "hostname" is the fully qualified host
+   name of the server.  The client then responds with the resulting
+   output_token.  If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
+
+
+
+Myers                       Standards Track                     [Page 9]
+
+RFC 2222                          SASL                      October 1997
+
+
+   then the client should expect the server to issue a token in a
+   subsequent challenge.  The client must pass the token to another call
+   to GSS_Init_sec_context, repeating the actions in this paragraph.
+
+   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
+   the following actions: If the last call to GSS_Init_sec_context
+   returned an output_token, then the client responds with the
+   output_token, otherwise the client responds with no data.  The client
+   should then expect the server to issue a token in a subsequent
+   challenge.  The client passes this token to GSS_Unwrap and interprets
+   the first octet of resulting cleartext as a bit-mask specifying the
+   security layers supported by the server and the second through fourth
+   octets as the maximum size output_message to send to the server.  The
+   client then constructs data, with the first octet containing the
+   bit-mask specifying the selected security layer, the second through
+   fourth octets containing in network byte order the maximum size
+   output_message the client is able to receive, and the remaining
+   octets containing the authorization identity.  The client passes the
+   data to GSS_Wrap with conf_flag set to FALSE, and responds with the
+   generated output_message.  The client can then consider the server
+   authenticated.
+
+7.2.2 Server side of authentication protocol exchange
+
+   The server passes the initial client response to
+   GSS_Accept_sec_context as input_token, setting input_context_handle
+   to 0 (initially).  If GSS_Accept_sec_context returns
+   GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
+   to the client in challenge and passes the resulting response to
+   another call to GSS_Accept_sec_context, repeating the actions in this
+   paragraph.
+
+   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
+   the following actions: If the last call to GSS_Accept_sec_context
+   returned an output_token, the server returns it to the client in a
+   challenge and expects a reply from the client with no data.  Whether
+   or not an output_token was returned (and after receipt of any
+   response from the client to such an output_token), the server then
+   constructs 4 octets of data, with the first octet containing a bit-
+   mask specifying the security layers supported by the server and the
+   second through fourth octets containing in network byte order the
+   maximum size output_token the server is able to receive.  The server
+   must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
+   and issue the generated output_message to the client in a challenge.
+   The server must then pass the resulting response to GSS_Unwrap and
+   interpret the first octet of resulting cleartext as the bit-mask for
+   the selected security layer, the second through fourth octets as the
+   maximum size output_message to send to the client, and the remaining
+
+
+
+Myers                       Standards Track                    [Page 10]
+
+RFC 2222                          SASL                      October 1997
+
+
+   octets as the authorization identity.  The server must verify that
+   the src_name is authorized to authenticate as the authorization
+   identity.  After these verifications, the authentication process is
+   complete.
+
+7.2.3 Security layer
+
+   The security layers and their corresponding bit-masks are as follows:
+
+     1 No security layer
+     2 Integrity protection.
+       Sender calls GSS_Wrap with conf_flag set to FALSE
+     4 Privacy protection.
+       Sender calls GSS_Wrap with conf_flag set to TRUE
+
+   Other bit-masks may be defined in the future; bits which are not
+   understood must be negotiated off.
+
+7.3.  S/Key mechanism
+
+   The mechanism name associated with S/Key [RFC 1760] using the MD4
+   digest algorithm is "SKEY".
+
+   The client sends an initial response with the authorization identity.
+
+   The server then issues a challenge which contains the decimal
+   sequence number followed by a single space and the seed string for
+   the indicated authorization identity.  The client responds with the
+   one-time-password, as either a 64-bit value in network byte order or
+   encoded in the "six English words" format.
+
+   The server must verify the one-time-password.  After this
+   verification, the authentication process is complete.
+
+   S/Key authentication does not provide for any security layers.
+
+   EXAMPLE: The following are two S/Key login scenarios in the IMAP4
+   protocol.
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE SKEY
+     S: +
+     C: bW9yZ2Fu
+     S: + OTUgUWE1ODMwOA==
+     C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
+     S: A001 OK S/Key authentication successful
+
+
+
+
+
+Myers                       Standards Track                    [Page 11]
+
+RFC 2222                          SASL                      October 1997
+
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE SKEY
+     S: +
+     C: c21pdGg=
+     S: + OTUgUWE1ODMwOA==
+     C: BsAY3g4gBNo=
+     S: A001 NO S/Key authentication failed
+
+   The following is an S/Key login scenario in an IMAP4-like protocol
+   which has an optional "initial response" argument to the AUTHENTICATE
+   command.
+
+     S: * OK IMAP4-Like Server
+     C: A001 AUTHENTICATE SKEY bW9yZ2Fu
+     S: + OTUgUWE1ODMwOA==
+     C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
+     S: A001 OK S/Key authentication successful
+
+7.4.  External mechanism
+
+   The mechanism name associated with external authentication is
+   "EXTERNAL".
+
+   The client sends an initial response with the authorization identity.
+
+   The server uses information, external to SASL, to determine whether
+   the client is authorized to authenticate as the authorization
+   identity.  If the client is so authorized, the server indicates
+   successful completion of the authentication exchange; otherwise the
+   server indicates failure.
+
+   The system providing this external information may be, for example,
+   IPsec or TLS.
+
+   If the client sends the empty string as the authorization identity
+   (thus requesting the authorization identity be derived from the
+   client's authentication credentials), the authorization identity is
+   to be derived from authentication credentials which exist in the
+   system which is providing the external authentication.
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 12]
+
+RFC 2222                          SASL                      October 1997
+
+
+8.    References
+
+   [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 2060, December 1996.
+
+   [RFC 2078] Linn, J., "Generic Security Service Application Program
+              Interface, Version 2", RFC 2078, January 1997.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC
+              Authors", RFC 2223, October 1997.
+
+   [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
+              1760, February 1995.
+
+   [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+              RFC 1700, October 1994.
+
+9.    Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+   The mechanisms that support integrity protection are designed such
+   that the negotiation of the security layer and authorization identity
+   is integrity protected.  When the client selects a security layer
+   with at least integrity protection, this protects against an active
+   attacker hijacking the connection and modifying the authentication
+   exchange to negotiate a plaintext connection.
+
+   When a server or client supports multiple authentication mechanisms,
+   each of which has a different security strength, it is possible for
+   an active attacker to cause a party to use the least secure mechanism
+   supported.  To protect against this sort of attack, a client or
+   server which supports mechanisms of different strengths should have a
+   configurable minimum strength that it will use.  It is not sufficient
+   for this minimum strength check to only be on the server, since an
+   active attacker can change which mechanisms the client sees as being
+   supported, causing the client to send authentication credentials for
+   its weakest supported mechanism.
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 13]
+
+RFC 2222                          SASL                      October 1997
+
+
+   The client's selection of a SASL mechanism is done in the clear and
+   may be modified by an active attacker.  It is important for any new
+   SASL mechanisms to be designed such that an active attacker cannot
+   obtain an authentication with weaker security properties by modifying
+   the SASL mechanism name and/or the challenges and responses.
+
+   Any protocol interactions prior to authentication are performed in
+   the clear and may be modified by an active attacker.  In the case
+   where a client selects integrity protection, it is important that any
+   security-sensitive protocol negotiations be performed after
+   authentication is complete.  Protocols should be designed such that
+   negotiations performed prior to authentication should be either
+   ignored or revalidated once authentication is complete.
+
+10.   Author's Address
+
+   John G. Myers
+   Netscape Communications
+   501 E. Middlefield Road
+   Mail Stop MV-029
+   Mountain View, CA 94043-4042
+
+   EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 14]
+
+RFC 2222                          SASL                      October 1997
+
+
+Appendix A. Relation of SASL to Transport Security
+
+   Questions have been raised about the relationship between SASL and
+   various services (such as IPsec and TLS) which provide a secured
+   connection.
+
+   Two of the key features of SASL are:
+
+   1. The separation of the authorization identity from the identity in
+      the client's credentials.  This permits agents such as proxy
+      servers to authenticate using their own credentials, yet request
+      the access privileges of the identity for which they are proxying.
+
+   2. Upon successful completion of an authentication exchange, the
+      server knows the authorization identity the client wishes to use.
+      This allows servers to move to a "user is authenticated" state in
+      the protocol.
+
+   These features are extremely important to some application protocols,
+   yet Transport Security services do not always provide them.  To
+   define SASL mechanisms based on these services would be a very messy
+   task, as the framing of these services would be redundant with the
+   framing of SASL and some method of providing these important SASL
+   features would have to be devised.
+
+   Sometimes it is desired to enable within an existing connection the
+   use of a security service which does not fit the SASL model.  (TLS is
+   an example of such a service.)  This can be done by adding a command,
+   for example "STARTTLS", to the protocol.  Such a command is outside
+   the scope of SASL, and should be different from the command which
+   starts a SASL authentication protocol exchange.
+
+   In certain situations, it is reasonable to use SASL underneath one of
+   these Transport Security services.  The transport service would
+   secure the connection, either service would authenticate the client,
+   and SASL would negotiate the authorization identity.  The SASL
+   negotiation would be what moves the protocol from "unauthenticated"
+   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
+   explicitly intended to handle the case where the transport service
+   secures the connection and authenticates the client and SASL
+   negotiates the authorization identity.
+
+   When using SASL underneath a sufficiently strong Transport Security
+   service, a SASL security layer would most likely be redundant.  The
+   client and server would thus probably want to negotiate off the use
+   of a SASL security layer.
+
+
+
+
+
+Myers                       Standards Track                    [Page 15]
+
+RFC 2222                          SASL                      October 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published
+   andand distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 16]
+
diff --git a/standards/rfc2246.txt b/standards/rfc2246.txt
new file mode 100644
index 000000000..2e838cf5d
--- /dev/null
+++ b/standards/rfc2246.txt
@@ -0,0 +1,4483 @@
+
+
+
+
+
+
+Network Working Group                                         T. Dierks
+Request for Comments: 2246                                     Certicom
+Category: Standards Track                                      C. Allen
+                                                               Certicom
+                                                           January 1999
+
+
+                            The TLS Protocol
+                              Version 1.0
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document specifies Version 1.0 of the Transport Layer Security
+   (TLS) protocol. The TLS protocol provides communications privacy over
+   the Internet. The protocol allows client/server applications to
+   communicate in a way that is designed to prevent eavesdropping,
+   tampering, or message forgery.
+
+Table of Contents
+
+   1.       Introduction                                              3
+   2.       Goals                                                     4
+   3.       Goals of this document                                    5
+   4.       Presentation language                                     5
+   4.1.     Basic block size                                          6
+   4.2.     Miscellaneous                                             6
+   4.3.     Vectors                                                   6
+   4.4.     Numbers                                                   7
+   4.5.     Enumerateds                                               7
+   4.6.     Constructed types                                         8
+   4.6.1.   Variants                                                  9
+   4.7.     Cryptographic attributes                                 10
+   4.8.     Constants                                                11
+   5.       HMAC and the pseudorandom function                       11
+   6.       The TLS Record Protocol                                  13
+   6.1.     Connection states                                        14
+
+
+
+Dierks & Allen              Standards Track                     [Page 1]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   6.2.     Record layer                                             16
+   6.2.1.   Fragmentation                                            16
+   6.2.2.   Record compression and decompression                     17
+   6.2.3.   Record payload protection                                18
+   6.2.3.1. Null or standard stream cipher                           19
+   6.2.3.2. CBC block cipher                                         19
+   6.3.     Key calculation                                          21
+   6.3.1.   Export key generation example                            22
+   7.       The TLS Handshake Protocol                               23
+   7.1.     Change cipher spec protocol                              24
+   7.2.     Alert protocol                                           24
+   7.2.1.   Closure alerts                                           25
+   7.2.2.   Error alerts                                             26
+   7.3.     Handshake Protocol overview                              29
+   7.4.     Handshake protocol                                       32
+   7.4.1.   Hello messages                                           33
+   7.4.1.1. Hello request                                            33
+   7.4.1.2. Client hello                                             34
+   7.4.1.3. Server hello                                             36
+   7.4.2.   Server certificate                                       37
+   7.4.3.   Server key exchange message                              39
+   7.4.4.   Certificate request                                      41
+   7.4.5.   Server hello done                                        42
+   7.4.6.   Client certificate                                       43
+   7.4.7.   Client key exchange message                              43
+   7.4.7.1. RSA encrypted premaster secret message                   44
+   7.4.7.2. Client Diffie-Hellman public value                       45
+   7.4.8.   Certificate verify                                       45
+   7.4.9.   Finished                                                 46
+   8.       Cryptographic computations                               47
+   8.1.     Computing the master secret                              47
+   8.1.1.   RSA                                                      48
+   8.1.2.   Diffie-Hellman                                           48
+   9.       Mandatory Cipher Suites                                  48
+   10.      Application data protocol                                48
+   A.       Protocol constant values                                 49
+   A.1.     Record layer                                             49
+   A.2.     Change cipher specs message                              50
+   A.3.     Alert messages                                           50
+   A.4.     Handshake protocol                                       51
+   A.4.1.   Hello messages                                           51
+   A.4.2.   Server authentication and key exchange messages          52
+   A.4.3.   Client authentication and key exchange messages          53
+   A.4.4.   Handshake finalization message                           54
+   A.5.     The CipherSuite                                          54
+   A.6.     The Security Parameters                                  56
+   B.       Glossary                                                 57
+   C.       CipherSuite definitions                                  61
+
+
+
+Dierks & Allen              Standards Track                     [Page 2]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   D.       Implementation Notes                                     64
+   D.1.     Temporary RSA keys                                       64
+   D.2.     Random Number Generation and Seeding                     64
+   D.3.     Certificates and authentication                          65
+   D.4.     CipherSuites                                             65
+   E.       Backward Compatibility With SSL                          66
+   E.1.     Version 2 client hello                                   67
+   E.2.     Avoiding man-in-the-middle version rollback              68
+   F.       Security analysis                                        69
+   F.1.     Handshake protocol                                       69
+   F.1.1.   Authentication and key exchange                          69
+   F.1.1.1. Anonymous key exchange                                   69
+   F.1.1.2. RSA key exchange and authentication                      70
+   F.1.1.3. Diffie-Hellman key exchange with authentication          71
+   F.1.2.   Version rollback attacks                                 71
+   F.1.3.   Detecting attacks against the handshake protocol         72
+   F.1.4.   Resuming sessions                                        72
+   F.1.5.   MD5 and SHA                                              72
+   F.2.     Protecting application data                              72
+   F.3.     Final notes                                              73
+   G.       Patent Statement                                         74
+            Security Considerations                                  75
+            References                                               75
+            Credits                                                  77
+            Comments                                                 78
+            Full Copyright Statement                                 80
+
+1. Introduction
+
+   The primary goal of the TLS Protocol is to provide privacy and data
+   integrity between two communicating applications. The protocol is
+   composed of two layers: the TLS Record Protocol and the TLS Handshake
+   Protocol. At the lowest level, layered on top of some reliable
+   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
+   TLS Record Protocol provides connection security that has two basic
+   properties:
+
+     - The connection is private. Symmetric cryptography is used for
+       data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
+       this symmetric encryption are generated uniquely for each
+       connection and are based on a secret negotiated by another
+       protocol (such as the TLS Handshake Protocol). The Record
+       Protocol can also be used without encryption.
+
+     - The connection is reliable. Message transport includes a message
+       integrity check using a keyed MAC. Secure hash functions (e.g.,
+       SHA, MD5, etc.) are used for MAC computations. The Record
+       Protocol can operate without a MAC, but is generally only used in
+
+
+
+Dierks & Allen              Standards Track                     [Page 3]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       this mode while another protocol is using the Record Protocol as
+       a transport for negotiating security parameters.
+
+   The TLS Record Protocol is used for encapsulation of various higher
+   level protocols. One such encapsulated protocol, the TLS Handshake
+   Protocol, allows the server and client to authenticate each other and
+   to negotiate an encryption algorithm and cryptographic keys before
+   the application protocol transmits or receives its first byte of
+   data. The TLS Handshake Protocol provides connection security that
+   has three basic properties:
+
+     - The peer's identity can be authenticated using asymmetric, or
+       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
+       authentication can be made optional, but is generally required
+       for at least one of the peers.
+
+     - The negotiation of a shared secret is secure: the negotiated
+       secret is unavailable to eavesdroppers, and for any authenticated
+       connection the secret cannot be obtained, even by an attacker who
+       can place himself in the middle of the connection.
+
+     - The negotiation is reliable: no attacker can modify the
+       negotiation communication without being detected by the parties
+       to the communication.
+
+   One advantage of TLS is that it is application protocol independent.
+   Higher level protocols can layer on top of the TLS Protocol
+   transparently. The TLS standard, however, does not specify how
+   protocols add security with TLS; the decisions on how to initiate TLS
+   handshaking and how to interpret the authentication certificates
+   exchanged are left up to the judgment of the designers and
+   implementors of protocols which run on top of TLS.
+
+2. Goals
+
+   The goals of TLS Protocol, in order of their priority, are:
+
+    1. Cryptographic security: TLS should be used to establish a secure
+       connection between two parties.
+
+    2. Interoperability: Independent programmers should be able to
+       develop applications utilizing TLS that will then be able to
+       successfully exchange cryptographic parameters without knowledge
+       of one another's code.
+
+    3. Extensibility: TLS seeks to provide a framework into which new
+       public key and bulk encryption methods can be incorporated as
+       necessary. This will also accomplish two sub-goals: to prevent
+
+
+
+Dierks & Allen              Standards Track                     [Page 4]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       the need to create a new protocol (and risking the introduction
+       of possible new weaknesses) and to avoid the need to implement an
+       entire new security library.
+
+    4. Relative efficiency: Cryptographic operations tend to be highly
+       CPU intensive, particularly public key operations. For this
+       reason, the TLS protocol has incorporated an optional session
+       caching scheme to reduce the number of connections that need to
+       be established from scratch. Additionally, care has been taken to
+       reduce network activity.
+
+3. Goals of this document
+
+   This document and the TLS protocol itself are based on the SSL 3.0
+   Protocol Specification as published by Netscape. The differences
+   between this protocol and SSL 3.0 are not dramatic, but they are
+   significant enough that TLS 1.0 and SSL 3.0 do not interoperate
+   (although TLS 1.0 does incorporate a mechanism by which a TLS
+   implementation can back down to SSL 3.0). This document is intended
+   primarily for readers who will be implementing the protocol and those
+   doing cryptographic analysis of it. The specification has been
+   written with this in mind, and it is intended to reflect the needs of
+   those two groups. For that reason, many of the algorithm-dependent
+   data structures and rules are included in the body of the text (as
+   opposed to in an appendix), providing easier access to them.
+
+   This document is not intended to supply any details of service
+   definition nor interface definition, although it does cover select
+   areas of policy as they are required for the maintenance of solid
+   security.
+
+4. Presentation language
+
+   This document deals with the formatting of data in an external
+   representation. The following very basic and somewhat casually
+   defined presentation syntax will be used. The syntax draws from
+   several sources in its structure. Although it resembles the
+   programming language "C" in its syntax and XDR [XDR] in both its
+   syntax and intent, it would be risky to draw too many parallels. The
+   purpose of this presentation language is to document TLS only, not to
+   have general application beyond that particular goal.
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 5]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+4.1. Basic block size
+
+   The representation of all data items is explicitly specified. The
+   basic data block size is one byte (i.e. 8 bits). Multiple byte data
+   items are concatenations of bytes, from left to right, from top to
+   bottom. From the bytestream a multi-byte item (a numeric in the
+   example) is formed (using C notation) by:
+
+       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
+               ... | byte[n-1];
+
+   This byte ordering for multi-byte values is the commonplace network
+   byte order or big endian format.
+
+4.2. Miscellaneous
+
+   Comments begin with "/*" and end with "*/".
+
+   Optional components are denoted by enclosing them in "[[ ]]" double
+   brackets.
+
+   Single byte entities containing uninterpreted data are of type
+   opaque.
+
+4.3. Vectors
+
+   A vector (single dimensioned array) is a stream of homogeneous data
+   elements. The size of the vector may be specified at documentation
+   time or left unspecified until runtime. In either case the length
+   declares the number of bytes, not the number of elements, in the
+   vector. The syntax for specifying a new type T' that is a fixed
+   length vector of type T is
+
+       T T'[n];
+
+   Here T' occupies n bytes in the data stream, where n is a multiple of
+   the size of T. The length of the vector is not included in the
+   encoded stream.
+
+   In the following example, Datum is defined to be three consecutive
+   bytes that the protocol does not interpret, while Data is three
+   consecutive Datum, consuming a total of nine bytes.
+
+       opaque Datum[3];      /* three uninterpreted bytes */
+       Datum Data[9];        /* 3 consecutive 3 byte vectors */
+
+
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 6]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Variable length vectors are defined by specifying a subrange of legal
+   lengths, inclusively, using the notation <floor..ceiling>.  When
+   encoded, the actual length precedes the vector's contents in the byte
+   stream. The length will be in the form of a number consuming as many
+   bytes as required to hold the vector's specified maximum (ceiling)
+   length. A variable length vector with an actual length field of zero
+   is referred to as an empty vector.
+
+       T T'<floor..ceiling>;
+
+   In the following example, mandatory is a vector that must contain
+   between 300 and 400 bytes of type opaque. It can never be empty. The
+   actual length field consumes two bytes, a uint16, sufficient to
+   represent the value 400 (see Section 4.4). On the other hand, longer
+   can represent up to 800 bytes of data, or 400 uint16 elements, and it
+   may be empty. Its encoding will include a two byte actual length
+   field prepended to the vector. The length of an encoded vector must
+   be an even multiple of the length of a single element (for example, a
+   17 byte vector of uint16 would be illegal).
+
+       opaque mandatory<300..400>;
+             /* length field is 2 bytes, cannot be empty */
+       uint16 longer<0..800>;
+             /* zero to 400 16-bit unsigned integers */
+
+4.4. Numbers
+
+   The basic numeric data type is an unsigned byte (uint8). All larger
+   numeric data types are formed from fixed length series of bytes
+   concatenated as described in Section 4.1 and are also unsigned. The
+   following numeric types are predefined.
+
+       uint8 uint16[2];
+       uint8 uint24[3];
+       uint8 uint32[4];
+       uint8 uint64[8];
+
+   All values, here and elsewhere in the specification, are stored in
+   "network" or "big-endian" order; the uint32 represented by the hex
+   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
+
+4.5. Enumerateds
+
+   An additional sparse data type is available called enum. A field of
+   type enum can only assume the values declared in the definition.
+   Each definition is a different type. Only enumerateds of the same
+   type may be assigned or compared. Every element of an enumerated must
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 7]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   be assigned a value, as demonstrated in the following example.  Since
+   the elements of the enumerated are not ordered, they can be assigned
+   any unique value, in any order.
+
+       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
+
+   Enumerateds occupy as much space in the byte stream as would its
+   maximal defined ordinal value. The following definition would cause
+   one byte to be used to carry fields of type Color.
+
+       enum { red(3), blue(5), white(7) } Color;
+
+   One may optionally specify a value without its associated tag to
+   force the width definition without defining a superfluous element.
+   In the following example, Taste will consume two bytes in the data
+   stream but can only assume the values 1, 2 or 4.
+
+       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
+
+   The names of the elements of an enumeration are scoped within the
+   defined type. In the first example, a fully qualified reference to
+   the second element of the enumeration would be Color.blue. Such
+   qualification is not required if the target of the assignment is well
+   specified.
+
+       Color color = Color.blue;     /* overspecified, legal */
+       Color color = blue;           /* correct, type implicit */
+
+   For enumerateds that are never converted to external representation,
+   the numerical information may be omitted.
+
+       enum { low, medium, high } Amount;
+
+4.6. Constructed types
+
+   Structure types may be constructed from primitive types for
+   convenience. Each specification declares a new, unique type. The
+   syntax for definition is much like that of C.
+
+       struct {
+         T1 f1;
+         T2 f2;
+         ...
+         Tn fn;
+       } [[T]];
+
+
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 8]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   The fields within a structure may be qualified using the type's name
+   using a syntax much like that available for enumerateds. For example,
+   T.f2 refers to the second field of the previous declaration.
+   Structure definitions may be embedded.
+
+4.6.1. Variants
+
+   Defined structures may have variants based on some knowledge that is
+   available within the environment. The selector must be an enumerated
+   type that defines the possible variants the structure defines. There
+   must be a case arm for every element of the enumeration declared in
+   the select. The body of the variant structure may be given a label
+   for reference. The mechanism by which the variant is selected at
+   runtime is not prescribed by the presentation language.
+
+       struct {
+           T1 f1;
+           T2 f2;
+           ....
+           Tn fn;
+           select (E) {
+               case e1: Te1;
+               case e2: Te2;
+               ....
+               case en: Ten;
+           } [[fv]];
+       } [[Tv]];
+
+   For example:
+
+       enum { apple, orange } VariantTag;
+       struct {
+           uint16 number;
+           opaque string<0..10>; /* variable length */
+       } V1;
+       struct {
+           uint32 number;
+           opaque string[10];    /* fixed length */
+       } V2;
+       struct {
+           select (VariantTag) { /* value of selector is implicit */
+               case apple: V1;   /* VariantBody, tag = apple */
+               case orange: V2;  /* VariantBody, tag = orange */
+           } variant_body;       /* optional label on variant */
+       } VariantRecord;
+
+   Variant structures may be qualified (narrowed) by specifying a value
+   for the selector prior to the type. For example, a
+
+
+
+Dierks & Allen              Standards Track                     [Page 9]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       orange VariantRecord
+
+   is a narrowed type of a VariantRecord containing a variant_body of
+   type V2.
+
+4.7. Cryptographic attributes
+
+   The four cryptographic operations digital signing, stream cipher
+   encryption, block cipher encryption, and public key encryption are
+   designated digitally-signed, stream-ciphered, block-ciphered, and
+   public-key-encrypted, respectively. A field's cryptographic
+   processing is specified by prepending an appropriate key word
+   designation before the field's type specification. Cryptographic keys
+   are implied by the current session state (see Section 6.1).
+
+   In digital signing, one-way hash functions are used as input for a
+   signing algorithm. A digitally-signed element is encoded as an opaque
+   vector <0..2^16-1>, where the length is specified by the signing
+   algorithm and key.
+
+   In RSA signing, a 36-byte structure of two hashes (one SHA and one
+   MD5) is signed (encrypted with the private key). It is encoded with
+   PKCS #1 block type 0 or type 1 as described in [PKCS1].
+
+   In DSS, the 20 bytes of the SHA hash are run directly through the
+   Digital Signing Algorithm with no additional hashing. This produces
+   two values, r and s. The DSS signature is an opaque vector, as above,
+   the contents of which are the DER encoding of:
+
+       Dss-Sig-Value  ::=  SEQUENCE  {
+            r       INTEGER,
+            s       INTEGER
+       }
+
+   In stream cipher encryption, the plaintext is exclusive-ORed with an
+   identical amount of output generated from a cryptographically-secure
+   keyed pseudorandom number generator.
+
+   In block cipher encryption, every block of plaintext encrypts to a
+   block of ciphertext. All block cipher encryption is done in CBC
+   (Cipher Block Chaining) mode, and all items which are block-ciphered
+   will be an exact multiple of the cipher block length.
+
+   In public key encryption, a public key algorithm is used to encrypt
+   data in such a way that it can be decrypted only with the matching
+   private key. A public-key-encrypted element is encoded as an opaque
+   vector <0..2^16-1>, where the length is specified by the signing
+   algorithm and key.
+
+
+
+Dierks & Allen              Standards Track                    [Page 10]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   An RSA encrypted value is encoded with PKCS #1 block type 2 as
+   described in [PKCS1].
+
+   In the following example:
+
+       stream-ciphered struct {
+           uint8 field1;
+           uint8 field2;
+           digitally-signed opaque hash[20];
+       } UserType;
+
+   The contents of hash are used as input for the signing algorithm,
+   then the entire structure is encrypted with a stream cipher. The
+   length of this structure, in bytes would be equal to 2 bytes for
+   field1 and field2, plus two bytes for the length of the signature,
+   plus the length of the output of the signing algorithm. This is known
+   due to the fact that the algorithm and key used for the signing are
+   known prior to encoding or decoding this structure.
+
+4.8. Constants
+
+   Typed constants can be defined for purposes of specification by
+   declaring a symbol of the desired type and assigning values to it.
+   Under-specified types (opaque, variable length vectors, and
+   structures that contain opaque) cannot be assigned values. No fields
+   of a multi-element structure or vector may be elided.
+
+   For example,
+
+       struct {
+           uint8 f1;
+           uint8 f2;
+       } Example1;
+
+       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
+
+5. HMAC and the pseudorandom function
+
+   A number of operations in the TLS record and handshake layer required
+   a keyed MAC; this is a secure digest of some data protected by a
+   secret. Forging the MAC is infeasible without knowledge of the MAC
+   secret. The construction we use for this operation is known as HMAC,
+   described in [HMAC].
+
+   HMAC can be used with a variety of different hash algorithms. TLS
+   uses it in the handshake with two different algorithms: MD5 and SHA-
+   1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 11]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   data). Additional hash algorithms can be defined by cipher suites and
+   used to protect record data, but MD5 and SHA-1 are hard coded into
+   the description of the handshaking for this version of the protocol.
+
+   In addition, a construction is required to do expansion of secrets
+   into blocks of data for the purposes of key generation or validation.
+   This pseudo-random function (PRF) takes as input a secret, a seed,
+   and an identifying label and produces an output of arbitrary length.
+
+   In order to make the PRF as secure as possible, it uses two hash
+   algorithms in a way which should guarantee its security if either
+   algorithm remains secure.
+
+   First, we define a data expansion function, P_hash(secret, data)
+   which uses a single hash function to expand a secret and seed into an
+   arbitrary quantity of output:
+
+       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
+                              HMAC_hash(secret, A(2) + seed) +
+                              HMAC_hash(secret, A(3) + seed) + ...
+
+   Where + indicates concatenation.
+
+   A() is defined as:
+       A(0) = seed
+       A(i) = HMAC_hash(secret, A(i-1))
+
+   P_hash can be iterated as many times as is necessary to produce the
+   required quantity of data. For example, if P_SHA-1 was being used to
+   create 64 bytes of data, it would have to be iterated 4 times
+   (through A(4)), creating 80 bytes of output data; the last 16 bytes
+   of the final iteration would then be discarded, leaving 64 bytes of
+   output data.
+
+   TLS's PRF is created by splitting the secret into two halves and
+   using one half to generate data with P_MD5 and the other half to
+   generate data with P_SHA-1, then exclusive-or'ing the outputs of
+   these two expansion functions together.
+
+   S1 and S2 are the two halves of the secret and each is the same
+   length. S1 is taken from the first half of the secret, S2 from the
+   second half. Their length is created by rounding up the length of the
+   overall secret divided by two; thus, if the original secret is an odd
+   number of bytes long, the last byte of S1 will be the same as the
+   first byte of S2.
+
+       L_S = length in bytes of secret;
+       L_S1 = L_S2 = ceil(L_S / 2);
+
+
+
+Dierks & Allen              Standards Track                    [Page 12]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   The secret is partitioned into two halves (with the possibility of
+   one shared byte) as described above, S1 taking the first L_S1 bytes
+   and S2 the last L_S2 bytes.
+
+   The PRF is then defined as the result of mixing the two pseudorandom
+   streams by exclusive-or'ing them together.
+
+       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
+                                  P_SHA-1(S2, label + seed);
+
+   The label is an ASCII string. It should be included in the exact form
+   it is given without a length byte or trailing null character.  For
+   example, the label "slithy toves" would be processed by hashing the
+   following bytes:
+
+       73 6C 69 74 68 79 20 74 6F 76 65 73
+
+   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
+   byte outputs, the boundaries of their internal iterations will not be
+   aligned; to generate a 80 byte output will involve P_MD5 being
+   iterated through A(5), while P_SHA-1 will only iterate through A(4).
+
+6. The TLS Record Protocol
+
+   The TLS Record Protocol is a layered protocol. At each layer,
+   messages may include fields for length, description, and content.
+   The Record Protocol takes messages to be transmitted, fragments the
+   data into manageable blocks, optionally compresses the data, applies
+   a MAC, encrypts, and transmits the result. Received data is
+   decrypted, verified, decompressed, and reassembled, then delivered to
+   higher level clients.
+
+   Four record protocol clients are described in this document: the
+   handshake protocol, the alert protocol, the change cipher spec
+   protocol, and the application data protocol. In order to allow
+   extension of the TLS protocol, additional record types can be
+   supported by the record protocol. Any new record types should
+   allocate type values immediately beyond the ContentType values for
+   the four record types described here (see Appendix A.2). If a TLS
+   implementation receives a record type it does not understand, it
+   should just ignore it. Any protocol designed for use over TLS must be
+   carefully designed to deal with all possible attacks against it.
+   Note that because the type and length of a record are not protected
+   by encryption, care should be take to minimize the value of traffic
+   analysis of these values.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 13]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+6.1. Connection states
+
+   A TLS connection state is the operating environment of the TLS Record
+   Protocol. It specifies a compression algorithm, encryption algorithm,
+   and MAC algorithm. In addition, the parameters for these algorithms
+   are known: the MAC secret and the bulk encryption keys and IVs for
+   the connection in both the read and the write directions. Logically,
+   there are always four connection states outstanding: the current read
+   and write states, and the pending read and write states. All records
+   are processed under the current read and write states. The security
+   parameters for the pending states can be set by the TLS Handshake
+   Protocol, and the Handshake Protocol can selectively make either of
+   the pending states current, in which case the appropriate current
+   state is disposed of and replaced with the pending state; the pending
+   state is then reinitialized to an empty state. It is illegal to make
+   a state which has not been initialized with security parameters a
+   current state. The initial current state always specifies that no
+   encryption, compression, or MAC will be used.
+
+   The security parameters for a TLS Connection read and write state are
+   set by providing the following values:
+
+   connection end
+       Whether this entity is considered the "client" or the "server" in
+       this connection.
+
+   bulk encryption algorithm
+       An algorithm to be used for bulk encryption. This specification
+       includes the key size of this algorithm, how much of that key is
+       secret, whether it is a block or stream cipher, the block size of
+       the cipher (if appropriate), and whether it is considered an
+       "export" cipher.
+
+   MAC algorithm
+       An algorithm to be used for message authentication. This
+       specification includes the size of the hash which is returned by
+       the MAC algorithm.
+
+   compression algorithm
+       An algorithm to be used for data compression. This specification
+       must include all information the algorithm requires to do
+       compression.
+
+   master secret
+       A 48 byte secret shared between the two peers in the connection.
+
+   client random
+       A 32 byte value provided by the client.
+
+
+
+Dierks & Allen              Standards Track                    [Page 14]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   server random
+       A 32 byte value provided by the server.
+
+   These parameters are defined in the presentation language as:
+
+       enum { server, client } ConnectionEnd;
+
+       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
+
+       enum { stream, block } CipherType;
+
+       enum { true, false } IsExportable;
+
+       enum { null, md5, sha } MACAlgorithm;
+
+       enum { null(0), (255) } CompressionMethod;
+
+       /* The algorithms specified in CompressionMethod,
+          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
+
+       struct {
+           ConnectionEnd          entity;
+           BulkCipherAlgorithm    bulk_cipher_algorithm;
+           CipherType             cipher_type;
+           uint8                  key_size;
+           uint8                  key_material_length;
+           IsExportable           is_exportable;
+           MACAlgorithm           mac_algorithm;
+           uint8                  hash_size;
+           CompressionMethod      compression_algorithm;
+           opaque                 master_secret[48];
+           opaque                 client_random[32];
+           opaque                 server_random[32];
+       } SecurityParameters;
+
+   The record layer will use the security parameters to generate the
+   following six items:
+
+       client write MAC secret
+       server write MAC secret
+       client write key
+       server write key
+       client write IV (for block ciphers only)
+       server write IV (for block ciphers only)
+
+   The client write parameters are used by the server when receiving and
+   processing records and vice-versa. The algorithm used for generating
+   these items from the security parameters is described in section 6.3.
+
+
+
+Dierks & Allen              Standards Track                    [Page 15]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Once the security parameters have been set and the keys have been
+   generated, the connection states can be instantiated by making them
+   the current states. These current states must be updated for each
+   record processed. Each connection state includes the following
+   elements:
+
+   compression state
+       The current state of the compression algorithm.
+
+   cipher state
+       The current state of the encryption algorithm. This will consist
+       of the scheduled key for that connection. In addition, for block
+       ciphers running in CBC mode (the only mode specified for TLS),
+       this will initially contain the IV for that connection state and
+       be updated to contain the ciphertext of the last block encrypted
+       or decrypted as records are processed. For stream ciphers, this
+       will contain whatever the necessary state information is to allow
+       the stream to continue to encrypt or decrypt data.
+
+   MAC secret
+       The MAC secret for this connection as generated above.
+
+   sequence number
+       Each connection state contains a sequence number, which is
+       maintained separately for read and write states. The sequence
+       number must be set to zero whenever a connection state is made
+       the active state. Sequence numbers are of type uint64 and may not
+       exceed 2^64-1. A sequence number is incremented after each
+       record: specifically, the first record which is transmitted under
+       a particular connection state should use sequence number 0.
+
+6.2. Record layer
+
+   The TLS Record Layer receives uninterpreted data from higher layers
+   in non-empty blocks of arbitrary size.
+
+6.2.1. Fragmentation
+
+   The record layer fragments information blocks into TLSPlaintext
+   records carrying data in chunks of 2^14 bytes or less. Client message
+   boundaries are not preserved in the record layer (i.e., multiple
+   client messages of the same ContentType may be coalesced into a
+   single TLSPlaintext record, or a single message may be fragmented
+   across several records).
+
+       struct {
+           uint8 major, minor;
+       } ProtocolVersion;
+
+
+
+Dierks & Allen              Standards Track                    [Page 16]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       enum {
+           change_cipher_spec(20), alert(21), handshake(22),
+           application_data(23), (255)
+       } ContentType;
+
+       struct {
+           ContentType type;
+           ProtocolVersion version;
+           uint16 length;
+           opaque fragment[TLSPlaintext.length];
+       } TLSPlaintext;
+
+   type
+       The higher level protocol used to process the enclosed fragment.
+
+   version
+       The version of the protocol being employed. This document
+       describes TLS Version 1.0, which uses the version { 3, 1 }. The
+       version value 3.1 is historical: TLS version 1.0 is a minor
+       modification to the SSL 3.0 protocol, which bears the version
+       value 3.0. (See Appendix A.1).
+
+   length
+       The length (in bytes) of the following TLSPlaintext.fragment.
+       The length should not exceed 2^14.
+
+   fragment
+       The application data. This data is transparent and treated as an
+       independent block to be dealt with by the higher level protocol
+       specified by the type field.
+
+ Note: Data of different TLS Record layer content types may be
+       interleaved. Application data is generally of lower precedence
+       for transmission than other content types.
+
+6.2.2. Record compression and decompression
+
+   All records are compressed using the compression algorithm defined in
+   the current session state. There is always an active compression
+   algorithm; however, initially it is defined as
+   CompressionMethod.null. The compression algorithm translates a
+   TLSPlaintext structure into a TLSCompressed structure. Compression
+   functions are initialized with default state information whenever a
+   connection state is made active.
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 17]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Compression must be lossless and may not increase the content length
+   by more than 1024 bytes. If the decompression function encounters a
+   TLSCompressed.fragment that would decompress to a length in excess of
+   2^14 bytes, it should report a fatal decompression failure error.
+
+       struct {
+           ContentType type;       /* same as TLSPlaintext.type */
+           ProtocolVersion version;/* same as TLSPlaintext.version */
+           uint16 length;
+           opaque fragment[TLSCompressed.length];
+       } TLSCompressed;
+
+   length
+       The length (in bytes) of the following TLSCompressed.fragment.
+       The length should not exceed 2^14 + 1024.
+
+   fragment
+       The compressed form of TLSPlaintext.fragment.
+
+ Note: A CompressionMethod.null operation is an identity operation; no
+       fields are altered.
+
+   Implementation note:
+       Decompression functions are responsible for ensuring that
+       messages cannot cause internal buffer overflows.
+
+6.2.3. Record payload protection
+
+   The encryption and MAC functions translate a TLSCompressed structure
+   into a TLSCiphertext. The decryption functions reverse the process.
+   The MAC of the record also includes a sequence number so that
+   missing, extra or repeated messages are detectable.
+
+       struct {
+           ContentType type;
+           ProtocolVersion version;
+           uint16 length;
+           select (CipherSpec.cipher_type) {
+               case stream: GenericStreamCipher;
+               case block: GenericBlockCipher;
+           } fragment;
+       } TLSCiphertext;
+
+   type
+       The type field is identical to TLSCompressed.type.
+
+   version
+       The version field is identical to TLSCompressed.version.
+
+
+
+Dierks & Allen              Standards Track                    [Page 18]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   length
+       The length (in bytes) of the following TLSCiphertext.fragment.
+       The length may not exceed 2^14 + 2048.
+
+   fragment
+       The encrypted form of TLSCompressed.fragment, with the MAC.
+
+6.2.3.1. Null or standard stream cipher
+
+   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
+   A.6) convert TLSCompressed.fragment structures to and from stream
+   TLSCiphertext.fragment structures.
+
+       stream-ciphered struct {
+           opaque content[TLSCompressed.length];
+           opaque MAC[CipherSpec.hash_size];
+       } GenericStreamCipher;
+
+   The MAC is generated as:
+
+       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
+                     TLSCompressed.version + TLSCompressed.length +
+                     TLSCompressed.fragment));
+
+   where "+" denotes concatenation.
+
+   seq_num
+       The sequence number for this record.
+
+   hash
+       The hashing algorithm specified by
+       SecurityParameters.mac_algorithm.
+
+   Note that the MAC is computed before encryption. The stream cipher
+   encrypts the entire block, including the MAC. For stream ciphers that
+   do not use a synchronization vector (such as RC4), the stream cipher
+   state from the end of one record is simply used on the subsequent
+   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
+   consists of the identity operation (i.e., the data is not encrypted
+   and the MAC size is zero implying that no MAC is used).
+   TLSCiphertext.length is TLSCompressed.length plus
+   CipherSpec.hash_size.
+
+6.2.3.2. CBC block cipher
+
+   For block ciphers (such as RC2 or DES), the encryption and MAC
+   functions convert TLSCompressed.fragment structures to and from block
+   TLSCiphertext.fragment structures.
+
+
+
+Dierks & Allen              Standards Track                    [Page 19]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       block-ciphered struct {
+           opaque content[TLSCompressed.length];
+           opaque MAC[CipherSpec.hash_size];
+           uint8 padding[GenericBlockCipher.padding_length];
+           uint8 padding_length;
+       } GenericBlockCipher;
+
+   The MAC is generated as described in Section 6.2.3.1.
+
+   padding
+       Padding that is added to force the length of the plaintext to be
+       an integral multiple of the block cipher's block length. The
+       padding may be any length up to 255 bytes long, as long as it
+       results in the TLSCiphertext.length being an integral multiple of
+       the block length. Lengths longer than necessary might be
+       desirable to frustrate attacks on a protocol based on analysis of
+       the lengths of exchanged messages. Each uint8 in the padding data
+       vector must be filled with the padding length value.
+
+   padding_length
+       The padding length should be such that the total size of the
+       GenericBlockCipher structure is a multiple of the cipher's block
+       length. Legal values range from zero to 255, inclusive. This
+       length specifies the length of the padding field exclusive of the
+       padding_length field itself.
+
+   The encrypted data length (TLSCiphertext.length) is one more than the
+   sum of TLSCompressed.length, CipherSpec.hash_size, and
+   padding_length.
+
+ Example: If the block length is 8 bytes, the content length
+          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
+          bytes, the length before padding is 82 bytes. Thus, the
+          padding length modulo 8 must be equal to 6 in order to make
+          the total length an even multiple of 8 bytes (the block
+          length). The padding length can be 6, 14, 22, and so on,
+          through 254. If the padding length were the minimum necessary,
+          6, the padding would be 6 bytes, each containing the value 6.
+          Thus, the last 8 octets of the GenericBlockCipher before block
+          encryption would be xx 06 06 06 06 06 06 06, where xx is the
+          last octet of the MAC.
+
+ Note: With block ciphers in CBC mode (Cipher Block Chaining) the
+       initialization vector (IV) for the first record is generated with
+       the other keys and secrets when the security parameters are set.
+       The IV for subsequent records is the last ciphertext block from
+       the previous record.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 20]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+6.3. Key calculation
+
+   The Record Protocol requires an algorithm to generate keys, IVs, and
+   MAC secrets from the security parameters provided by the handshake
+   protocol.
+
+   The master secret is hashed into a sequence of secure bytes, which
+   are assigned to the MAC secrets, keys, and non-export IVs required by
+   the current connection state (see Appendix A.6). CipherSpecs require
+   a client write MAC secret, a server write MAC secret, a client write
+   key, a server write key, a client write IV, and a server write IV,
+   which are generated from the master secret in that order. Unused
+   values are empty.
+
+   When generating keys and MAC secrets, the master secret is used as an
+   entropy source, and the random values provide unencrypted salt
+   material and IVs for exportable ciphers.
+
+   To generate the key material, compute
+
+       key_block = PRF(SecurityParameters.master_secret,
+                          "key expansion",
+                          SecurityParameters.server_random +
+                          SecurityParameters.client_random);
+
+   until enough output has been generated. Then the key_block is
+   partitioned as follows:
+
+       client_write_MAC_secret[SecurityParameters.hash_size]
+       server_write_MAC_secret[SecurityParameters.hash_size]
+       client_write_key[SecurityParameters.key_material_length]
+       server_write_key[SecurityParameters.key_material_length]
+       client_write_IV[SecurityParameters.IV_size]
+       server_write_IV[SecurityParameters.IV_size]
+
+   The client_write_IV and server_write_IV are only generated for non-
+   export block ciphers. For exportable block ciphers, the
+   initialization vectors are generated later, as described below. Any
+   extra key_block material is discarded.
+
+   Implementation note:
+       The cipher spec which is defined in this document which requires
+       the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
+       keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
+       104 bytes of key material.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 21]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Exportable encryption algorithms (for which CipherSpec.is_exportable
+   is true) require additional processing as follows to derive their
+   final write keys:
+
+       final_client_write_key =
+       PRF(SecurityParameters.client_write_key,
+                                  "client write key",
+                                  SecurityParameters.client_random +
+                                  SecurityParameters.server_random);
+       final_server_write_key =
+       PRF(SecurityParameters.server_write_key,
+                                  "server write key",
+                                  SecurityParameters.client_random +
+                                  SecurityParameters.server_random);
+
+   Exportable encryption algorithms derive their IVs solely from the
+   random values from the hello messages:
+
+       iv_block = PRF("", "IV block", SecurityParameters.client_random +
+                      SecurityParameters.server_random);
+
+   The iv_block is partitioned into two initialization vectors as the
+   key_block was above:
+
+       client_write_IV[SecurityParameters.IV_size]
+       server_write_IV[SecurityParameters.IV_size]
+
+   Note that the PRF is used without a secret in this case: this just
+   means that the secret has a length of zero bytes and contributes
+   nothing to the hashing in the PRF.
+
+6.3.1. Export key generation example
+
+   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
+   each of the two encryption keys and 16 bytes for each of the MAC
+   keys, for a total of 42 bytes of key material. The PRF output is
+   stored in the key_block. The key_block is partitioned, and the write
+   keys are salted because this is an exportable encryption algorithm.
+
+       key_block               = PRF(master_secret,
+                                     "key expansion",
+                                     server_random +
+                                     client_random)[0..41]
+       client_write_MAC_secret = key_block[0..15]
+       server_write_MAC_secret = key_block[16..31]
+       client_write_key        = key_block[32..36]
+       server_write_key        = key_block[37..41]
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 22]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       final_client_write_key  = PRF(client_write_key,
+                                     "client write key",
+                                     client_random +
+                                     server_random)[0..15]
+       final_server_write_key  = PRF(server_write_key,
+                                     "server write key",
+                                     client_random +
+                                     server_random)[0..15]
+
+       iv_block                = PRF("", "IV block", client_random +
+                                     server_random)[0..15]
+       client_write_IV = iv_block[0..7]
+       server_write_IV = iv_block[8..15]
+
+7. The TLS Handshake Protocol
+
+   The TLS Handshake Protocol consists of a suite of three sub-protocols
+   which are used to allow peers to agree upon security parameters for
+   the record layer, authenticate themselves, instantiate negotiated
+   security parameters, and report error conditions to each other.
+
+   The Handshake Protocol is responsible for negotiating a session,
+   which consists of the following items:
+
+   session identifier
+       An arbitrary byte sequence chosen by the server to identify an
+       active or resumable session state.
+
+   peer certificate
+       X509v3 [X509] certificate of the peer. This element of the state
+       may be null.
+
+   compression method
+       The algorithm used to compress data prior to encryption.
+
+   cipher spec
+       Specifies the bulk data encryption algorithm (such as null, DES,
+       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
+       cryptographic attributes such as the hash_size. (See Appendix A.6
+       for formal definition)
+
+   master secret
+       48-byte secret shared between the client and server.
+
+   is resumable
+       A flag indicating whether the session can be used to initiate new
+       connections.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 23]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   These items are then used to create security parameters for use by
+   the Record Layer when protecting application data. Many connections
+   can be instantiated using the same session through the resumption
+   feature of the TLS Handshake Protocol.
+
+7.1. Change cipher spec protocol
+
+   The change cipher spec protocol exists to signal transitions in
+   ciphering strategies. The protocol consists of a single message,
+   which is encrypted and compressed under the current (not the pending)
+   connection state. The message consists of a single byte of value 1.
+
+       struct {
+           enum { change_cipher_spec(1), (255) } type;
+       } ChangeCipherSpec;
+
+   The change cipher spec message is sent by both the client and server
+   to notify the receiving party that subsequent records will be
+   protected under the newly negotiated CipherSpec and keys. Reception
+   of this message causes the receiver to instruct the Record Layer to
+   immediately copy the read pending state into the read current state.
+   Immediately after sending this message, the sender should instruct
+   the record layer to make the write pending state the write active
+   state. (See section 6.1.) The change cipher spec message is sent
+   during the handshake after the security parameters have been agreed
+   upon, but before the verifying finished message is sent (see section
+   7.4.9).
+
+7.2. Alert protocol
+
+   One of the content types supported by the TLS Record layer is the
+   alert type. Alert messages convey the severity of the message and a
+   description of the alert. Alert messages with a level of fatal result
+   in the immediate termination of the connection. In this case, other
+   connections corresponding to the session may continue, but the
+   session identifier must be invalidated, preventing the failed session
+   from being used to establish new connections. Like other messages,
+   alert messages are encrypted and compressed, as specified by the
+   current connection state.
+
+       enum { warning(1), fatal(2), (255) } AlertLevel;
+
+       enum {
+           close_notify(0),
+           unexpected_message(10),
+           bad_record_mac(20),
+           decryption_failed(21),
+           record_overflow(22),
+
+
+
+Dierks & Allen              Standards Track                    [Page 24]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+           decompression_failure(30),
+           handshake_failure(40),
+           bad_certificate(42),
+           unsupported_certificate(43),
+           certificate_revoked(44),
+           certificate_expired(45),
+           certificate_unknown(46),
+           illegal_parameter(47),
+           unknown_ca(48),
+           access_denied(49),
+           decode_error(50),
+           decrypt_error(51),
+           export_restriction(60),
+           protocol_version(70),
+           insufficient_security(71),
+           internal_error(80),
+           user_canceled(90),
+           no_renegotiation(100),
+           (255)
+       } AlertDescription;
+
+       struct {
+           AlertLevel level;
+           AlertDescription description;
+       } Alert;
+
+7.2.1. Closure alerts
+
+   The client and the server must share knowledge that the connection is
+   ending in order to avoid a truncation attack. Either party may
+   initiate the exchange of closing messages.
+
+   close_notify
+       This message notifies the recipient that the sender will not send
+       any more messages on this connection. The session becomes
+       unresumable if any connection is terminated without proper
+       close_notify messages with level equal to warning.
+
+   Either party may initiate a close by sending a close_notify alert.
+   Any data received after a closure alert is ignored.
+
+   Each party is required to send a close_notify alert before closing
+   the write side of the connection. It is required that the other party
+   respond with a close_notify alert of its own and close down the
+   connection immediately, discarding any pending writes. It is not
+   required for the initiator of the close to wait for the responding
+   close_notify alert before closing the read side of the connection.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 25]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   If the application protocol using TLS provides that any data may be
+   carried over the underlying transport after the TLS connection is
+   closed, the TLS implementation must receive the responding
+   close_notify alert before indicating to the application layer that
+   the TLS connection has ended. If the application protocol will not
+   transfer any additional data, but will only close the underlying
+   transport connection, then the implementation may choose to close the
+   transport without waiting for the responding close_notify. No part of
+   this standard should be taken to dictate the manner in which a usage
+   profile for TLS manages its data transport, including when
+   connections are opened or closed.
+
+   NB: It is assumed that closing a connection reliably delivers
+       pending data before destroying the transport.
+
+7.2.2. Error alerts
+
+   Error handling in the TLS Handshake protocol is very simple. When an
+   error is detected, the detecting party sends a message to the other
+   party. Upon transmission or receipt of an fatal alert message, both
+   parties immediately close the connection. Servers and clients are
+   required to forget any session-identifiers, keys, and secrets
+   associated with a failed connection. The following error alerts are
+   defined:
+
+   unexpected_message
+       An inappropriate message was received. This alert is always fatal
+       and should never be observed in communication between proper
+       implementations.
+
+   bad_record_mac
+       This alert is returned if a record is received with an incorrect
+       MAC. This message is always fatal.
+
+   decryption_failed
+       A TLSCiphertext decrypted in an invalid way: either it wasn`t an
+       even multiple of the block length or its padding values, when
+       checked, weren`t correct. This message is always fatal.
+
+   record_overflow
+       A TLSCiphertext record was received which had a length more than
+       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
+       with more than 2^14+1024 bytes. This message is always fatal.
+
+   decompression_failure
+       The decompression function received improper input (e.g. data
+       that would expand to excessive length). This message is always
+       fatal.
+
+
+
+Dierks & Allen              Standards Track                    [Page 26]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   handshake_failure
+       Reception of a handshake_failure alert message indicates that the
+       sender was unable to negotiate an acceptable set of security
+       parameters given the options available. This is a fatal error.
+
+   bad_certificate
+       A certificate was corrupt, contained signatures that did not
+       verify correctly, etc.
+
+   unsupported_certificate
+       A certificate was of an unsupported type.
+
+   certificate_revoked
+       A certificate was revoked by its signer.
+
+   certificate_expired
+       A certificate has expired or is not currently valid.
+
+   certificate_unknown
+       Some other (unspecified) issue arose in processing the
+       certificate, rendering it unacceptable.
+
+   illegal_parameter
+       A field in the handshake was out of range or inconsistent with
+       other fields. This is always fatal.
+
+   unknown_ca
+       A valid certificate chain or partial chain was received, but the
+       certificate was not accepted because the CA certificate could not
+       be located or couldn`t be matched with a known, trusted CA.  This
+       message is always fatal.
+
+   access_denied
+       A valid certificate was received, but when access control was
+       applied, the sender decided not to proceed with negotiation.
+       This message is always fatal.
+
+   decode_error
+       A message could not be decoded because some field was out of the
+       specified range or the length of the message was incorrect. This
+       message is always fatal.
+
+   decrypt_error
+       A handshake cryptographic operation failed, including being
+       unable to correctly verify a signature, decrypt a key exchange,
+       or validate a finished message.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 27]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   export_restriction
+       A negotiation not in compliance with export restrictions was
+       detected; for example, attempting to transfer a 1024 bit
+       ephemeral RSA key for the RSA_EXPORT handshake method. This
+       message is always fatal.
+
+   protocol_version
+       The protocol version the client has attempted to negotiate is
+       recognized, but not supported. (For example, old protocol
+       versions might be avoided for security reasons). This message is
+       always fatal.
+
+   insufficient_security
+       Returned instead of handshake_failure when a negotiation has
+       failed specifically because the server requires ciphers more
+       secure than those supported by the client. This message is always
+       fatal.
+
+   internal_error
+       An internal error unrelated to the peer or the correctness of the
+       protocol makes it impossible to continue (such as a memory
+       allocation failure). This message is always fatal.
+
+   user_canceled
+       This handshake is being canceled for some reason unrelated to a
+       protocol failure. If the user cancels an operation after the
+       handshake is complete, just closing the connection by sending a
+       close_notify is more appropriate. This alert should be followed
+       by a close_notify. This message is generally a warning.
+
+   no_renegotiation
+       Sent by the client in response to a hello request or by the
+       server in response to a client hello after initial handshaking.
+       Either of these would normally lead to renegotiation; when that
+       is not appropriate, the recipient should respond with this alert;
+       at that point, the original requester can decide whether to
+       proceed with the connection. One case where this would be
+       appropriate would be where a server has spawned a process to
+       satisfy a request; the process might receive security parameters
+       (key length, authentication, etc.) at startup and it might be
+       difficult to communicate changes to these parameters after that
+       point. This message is always a warning.
+
+   For all errors where an alert level is not explicitly specified, the
+   sending party may determine at its discretion whether this is a fatal
+   error or not; if an alert with a level of warning is received, the
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 28]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   receiving party may decide at its discretion whether to treat this as
+   a fatal error or not. However, all messages which are transmitted
+   with a level of fatal must be treated as fatal messages.
+
+7.3. Handshake Protocol overview
+
+   The cryptographic parameters of the session state are produced by the
+   TLS Handshake Protocol, which operates on top of the TLS Record
+   Layer. When a TLS client and server first start communicating, they
+   agree on a protocol version, select cryptographic algorithms,
+   optionally authenticate each other, and use public-key encryption
+   techniques to generate shared secrets.
+
+   The TLS Handshake Protocol involves the following steps:
+
+     - Exchange hello messages to agree on algorithms, exchange random
+       values, and check for session resumption.
+
+     - Exchange the necessary cryptographic parameters to allow the
+       client and server to agree on a premaster secret.
+
+     - Exchange certificates and cryptographic information to allow the
+       client and server to authenticate themselves.
+
+     - Generate a master secret from the premaster secret and exchanged
+       random values.
+
+     - Provide security parameters to the record layer.
+
+     - Allow the client and server to verify that their peer has
+       calculated the same security parameters and that the handshake
+       occurred without tampering by an attacker.
+
+   Note that higher layers should not be overly reliant on TLS always
+   negotiating the strongest possible connection between two peers:
+   there are a number of ways a man in the middle attacker can attempt
+   to make two entities drop down to the least secure method they
+   support. The protocol has been designed to minimize this risk, but
+   there are still attacks available: for example, an attacker could
+   block access to the port a secure service runs on, or attempt to get
+   the peers to negotiate an unauthenticated connection. The fundamental
+   rule is that higher levels must be cognizant of what their security
+   requirements are and never transmit information over a channel less
+   secure than what they require. The TLS protocol is secure, in that
+   any cipher suite offers its promised level of security: if you
+   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
+   certificate you have verified, you can expect to be that secure.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 29]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   However, you should never send data over a link encrypted with 40 bit
+   security unless you feel that data is worth no more than the effort
+   required to break that encryption.
+
+   These goals are achieved by the handshake protocol, which can be
+   summarized as follows: The client sends a client hello message to
+   which the server must respond with a server hello message, or else a
+   fatal error will occur and the connection will fail. The client hello
+   and server hello are used to establish security enhancement
+   capabilities between client and server. The client hello and server
+   hello establish the following attributes: Protocol Version, Session
+   ID, Cipher Suite, and Compression Method. Additionally, two random
+   values are generated and exchanged: ClientHello.random and
+   ServerHello.random.
+
+   The actual key exchange uses up to four messages: the server
+   certificate, the server key exchange, the client certificate, and the
+   client key exchange. New key exchange methods can be created by
+   specifying a format for these messages and defining the use of the
+   messages to allow the client and server to agree upon a shared
+   secret. This secret should be quite long; currently defined key
+   exchange methods exchange secrets which range from 48 to 128 bytes in
+   length.
+
+   Following the hello messages, the server will send its certificate,
+   if it is to be authenticated. Additionally, a server key exchange
+   message may be sent, if it is required (e.g. if their server has no
+   certificate, or if its certificate is for signing only). If the
+   server is authenticated, it may request a certificate from the
+   client, if that is appropriate to the cipher suite selected. Now the
+   server will send the server hello done message, indicating that the
+   hello-message phase of the handshake is complete. The server will
+   then wait for a client response. If the server has sent a certificate
+   request message, the client must send the certificate message. The
+   client key exchange message is now sent, and the content of that
+   message will depend on the public key algorithm selected between the
+   client hello and the server hello. If the client has sent a
+   certificate with signing ability, a digitally-signed certificate
+   verify message is sent to explicitly verify the certificate.
+
+   At this point, a change cipher spec message is sent by the client,
+   and the client copies the pending Cipher Spec into the current Cipher
+   Spec. The client then immediately sends the finished message under
+   the new algorithms, keys, and secrets. In response, the server will
+   send its own change cipher spec message, transfer the pending to the
+   current Cipher Spec, and send its finished message under the new
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 30]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Cipher Spec. At this point, the handshake is complete and the client
+   and server may begin to exchange application layer data. (See flow
+   chart below.)
+
+      Client                                               Server
+
+      ClientHello                  -------->
+                                                      ServerHello
+                                                     Certificate*
+                                               ServerKeyExchange*
+                                              CertificateRequest*
+                                   <--------      ServerHelloDone
+      Certificate*
+      ClientKeyExchange
+      CertificateVerify*
+      [ChangeCipherSpec]
+      Finished                     -------->
+                                               [ChangeCipherSpec]
+                                   <--------             Finished
+      Application Data             <------->     Application Data
+
+             Fig. 1 - Message flow for a full handshake
+
+   * Indicates optional or situation-dependent messages that are not
+   always sent.
+
+  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
+       independent TLS Protocol content type, and is not actually a TLS
+       handshake message.
+
+   When the client and server decide to resume a previous session or
+   duplicate an existing session (instead of negotiating new security
+   parameters) the message flow is as follows:
+
+   The client sends a ClientHello using the Session ID of the session to
+   be resumed. The server then checks its session cache for a match.  If
+   a match is found, and the server is willing to re-establish the
+   connection under the specified session state, it will send a
+   ServerHello with the same Session ID value. At this point, both
+   client and server must send change cipher spec messages and proceed
+   directly to finished messages. Once the re-establishment is complete,
+   the client and server may begin to exchange application layer data.
+   (See flow chart below.) If a Session ID match is not found, the
+   server generates a new session ID and the TLS client and server
+   perform a full handshake.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 31]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+      Client                                                Server
+
+      ClientHello                   -------->
+                                                       ServerHello
+                                                [ChangeCipherSpec]
+                                    <--------             Finished
+      [ChangeCipherSpec]
+      Finished                      -------->
+      Application Data              <------->     Application Data
+
+          Fig. 2 - Message flow for an abbreviated handshake
+
+   The contents and significance of each message will be presented in
+   detail in the following sections.
+
+7.4. Handshake protocol
+
+   The TLS Handshake Protocol is one of the defined higher level clients
+   of the TLS Record Protocol. This protocol is used to negotiate the
+   secure attributes of a session. Handshake messages are supplied to
+   the TLS Record Layer, where they are encapsulated within one or more
+   TLSPlaintext structures, which are processed and transmitted as
+   specified by the current active session state.
+
+       enum {
+           hello_request(0), client_hello(1), server_hello(2),
+           certificate(11), server_key_exchange (12),
+           certificate_request(13), server_hello_done(14),
+           certificate_verify(15), client_key_exchange(16),
+           finished(20), (255)
+       } HandshakeType;
+
+       struct {
+           HandshakeType msg_type;    /* handshake type */
+           uint24 length;             /* bytes in message */
+           select (HandshakeType) {
+               case hello_request:       HelloRequest;
+               case client_hello:        ClientHello;
+               case server_hello:        ServerHello;
+               case certificate:         Certificate;
+               case server_key_exchange: ServerKeyExchange;
+               case certificate_request: CertificateRequest;
+               case server_hello_done:   ServerHelloDone;
+               case certificate_verify:  CertificateVerify;
+               case client_key_exchange: ClientKeyExchange;
+               case finished:            Finished;
+           } body;
+       } Handshake;
+
+
+
+Dierks & Allen              Standards Track                    [Page 32]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   The handshake protocol messages are presented below in the order they
+   must be sent; sending handshake messages in an unexpected order
+   results in a fatal error. Unneeded handshake messages can be omitted,
+   however. Note one exception to the ordering: the Certificate message
+   is used twice in the handshake (from server to client, then from
+   client to server), but described only in its first position. The one
+   message which is not bound by these ordering rules in the Hello
+   Request message, which can be sent at any time, but which should be
+   ignored by the client if it arrives in the middle of a handshake.
+
+7.4.1. Hello messages
+
+   The hello phase messages are used to exchange security enhancement
+   capabilities between the client and server. When a new session
+   begins, the Record Layer's connection state encryption, hash, and
+   compression algorithms are initialized to null. The current
+   connection state is used for renegotiation messages.
+
+7.4.1.1. Hello request
+
+   When this message will be sent:
+       The hello request message may be sent by the server at any time.
+
+   Meaning of this message:
+       Hello request is a simple notification that the client should
+       begin the negotiation process anew by sending a client hello
+       message when convenient. This message will be ignored by the
+       client if the client is currently negotiating a session. This
+       message may be ignored by the client if it does not wish to
+       renegotiate a session, or the client may, if it wishes, respond
+       with a no_renegotiation alert. Since handshake messages are
+       intended to have transmission precedence over application data,
+       it is expected that the negotiation will begin before no more
+       than a few records are received from the client. If the server
+       sends a hello request but does not receive a client hello in
+       response, it may close the connection with a fatal alert.
+
+   After sending a hello request, servers should not repeat the request
+   until the subsequent handshake negotiation is complete.
+
+   Structure of this message:
+       struct { } HelloRequest;
+
+ Note: This message should never be included in the message hashes which
+       are maintained throughout the handshake and used in the finished
+       messages and the certificate verify message.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 33]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+7.4.1.2. Client hello
+
+   When this message will be sent:
+       When a client first connects to a server it is required to send
+       the client hello as its first message. The client can also send a
+       client hello in response to a hello request or on its own
+       initiative in order to renegotiate the security parameters in an
+       existing connection.
+
+       Structure of this message:
+           The client hello message includes a random structure, which is
+           used later in the protocol.
+
+           struct {
+              uint32 gmt_unix_time;
+              opaque random_bytes[28];
+           } Random;
+
+       gmt_unix_time
+       The current time and date in standard UNIX 32-bit format (seconds
+       since the midnight starting Jan 1, 1970, GMT) according to the
+       sender's internal clock. Clocks are not required to be set
+       correctly by the basic TLS Protocol; higher level or application
+       protocols may define additional requirements.
+
+   random_bytes
+       28 bytes generated by a secure random number generator.
+
+   The client hello message includes a variable length session
+   identifier. If not empty, the value identifies a session between the
+   same client and server whose security parameters the client wishes to
+   reuse. The session identifier may be from an earlier connection, this
+   connection, or another currently active connection. The second option
+   is useful if the client only wishes to update the random structures
+   and derived values of a connection, while the third option makes it
+   possible to establish several independent secure connections without
+   repeating the full handshake protocol. These independent connections
+   may occur sequentially or simultaneously; a SessionID becomes valid
+   when the handshake negotiating it completes with the exchange of
+   Finished messages and persists until removed due to aging or because
+   a fatal error was encountered on a connection associated with the
+   session. The actual contents of the SessionID are defined by the
+   server.
+
+       opaque SessionID<0..32>;
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 34]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Warning:
+       Because the SessionID is transmitted without encryption or
+       immediate MAC protection, servers must not place confidential
+       information in session identifiers or let the contents of fake
+       session identifiers cause any breach of security. (Note that the
+       content of the handshake as a whole, including the SessionID, is
+       protected by the Finished messages exchanged at the end of the
+       handshake.)
+
+   The CipherSuite list, passed from the client to the server in the
+   client hello message, contains the combinations of cryptographic
+   algorithms supported by the client in order of the client's
+   preference (favorite choice first). Each CipherSuite defines a key
+   exchange algorithm, a bulk encryption algorithm (including secret key
+   length) and a MAC algorithm. The server will select a cipher suite
+   or, if no acceptable choices are presented, return a handshake
+   failure alert and close the connection.
+
+       uint8 CipherSuite[2];    /* Cryptographic suite selector */
+
+   The client hello includes a list of compression algorithms supported
+   by the client, ordered according to the client's preference.
+
+       enum { null(0), (255) } CompressionMethod;
+
+       struct {
+           ProtocolVersion client_version;
+           Random random;
+           SessionID session_id;
+           CipherSuite cipher_suites<2..2^16-1>;
+           CompressionMethod compression_methods<1..2^8-1>;
+       } ClientHello;
+
+   client_version
+       The version of the TLS protocol by which the client wishes to
+       communicate during this session. This should be the latest
+       (highest valued) version supported by the client. For this
+       version of the specification, the version will be 3.1 (See
+       Appendix E for details about backward compatibility).
+
+   random
+       A client-generated random structure.
+
+   session_id
+       The ID of a session the client wishes to use for this connection.
+       This field should be empty if no session_id is available or the
+       client wishes to generate new security parameters.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 35]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   cipher_suites
+       This is a list of the cryptographic options supported by the
+       client, with the client's first preference first. If the
+       session_id field is not empty (implying a session resumption
+       request) this vector must include at least the cipher_suite from
+       that session. Values are defined in Appendix A.5.
+
+   compression_methods
+       This is a list of the compression methods supported by the
+       client, sorted by client preference. If the session_id field is
+       not empty (implying a session resumption request) it must include
+       the compression_method from that session. This vector must
+       contain, and all implementations must support,
+       CompressionMethod.null. Thus, a client and server will always be
+       able to agree on a compression method.
+
+   After sending the client hello message, the client waits for a server
+   hello message. Any other handshake message returned by the server
+   except for a hello request is treated as a fatal error.
+
+   Forward compatibility note:
+       In the interests of forward compatibility, it is permitted for a
+       client hello message to include extra data after the compression
+       methods. This data must be included in the handshake hashes, but
+       must otherwise be ignored. This is the only handshake message for
+       which this is legal; for all other messages, the amount of data
+       in the message must match the description of the message
+       precisely.
+
+7.4.1.3. Server hello
+
+   When this message will be sent:
+       The server will send this message in response to a client hello
+       message when it was able to find an acceptable set of algorithms.
+       If it cannot find such a match, it will respond with a handshake
+       failure alert.
+
+   Structure of this message:
+       struct {
+           ProtocolVersion server_version;
+           Random random;
+           SessionID session_id;
+           CipherSuite cipher_suite;
+           CompressionMethod compression_method;
+       } ServerHello;
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 36]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   server_version
+       This field will contain the lower of that suggested by the client
+       in the client hello and the highest supported by the server. For
+       this version of the specification, the version is 3.1 (See
+       Appendix E for details about backward compatibility).
+
+   random
+       This structure is generated by the server and must be different
+       from (and independent of) ClientHello.random.
+
+   session_id
+       This is the identity of the session corresponding to this
+       connection. If the ClientHello.session_id was non-empty, the
+       server will look in its session cache for a match. If a match is
+       found and the server is willing to establish the new connection
+       using the specified session state, the server will respond with
+       the same value as was supplied by the client. This indicates a
+       resumed session and dictates that the parties must proceed
+       directly to the finished messages. Otherwise this field will
+       contain a different value identifying the new session. The server
+       may return an empty session_id to indicate that the session will
+       not be cached and therefore cannot be resumed. If a session is
+       resumed, it must be resumed using the same cipher suite it was
+       originally negotiated with.
+
+   cipher_suite
+       The single cipher suite selected by the server from the list in
+       ClientHello.cipher_suites. For resumed sessions this field is the
+       value from the state of the session being resumed.
+
+   compression_method
+       The single compression algorithm selected by the server from the
+       list in ClientHello.compression_methods. For resumed sessions
+       this field is the value from the resumed session state.
+
+7.4.2. Server certificate
+
+   When this message will be sent:
+       The server must send a certificate whenever the agreed-upon key
+       exchange method is not an anonymous one. This message will always
+       immediately follow the server hello message.
+
+   Meaning of this message:
+       The certificate type must be appropriate for the selected cipher
+       suite's key exchange algorithm, and is generally an X.509v3
+       certificate. It must contain a key which matches the key exchange
+       method, as follows. Unless otherwise specified, the signing
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 37]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       algorithm for the certificate must be the same as the algorithm
+       for the certificate key. Unless otherwise specified, the public
+       key may be of any length.
+
+       Key Exchange Algorithm  Certificate Key Type
+
+       RSA                     RSA public key; the certificate must
+                               allow the key to be used for encryption.
+
+       RSA_EXPORT              RSA public key of length greater than
+                               512 bits which can be used for signing,
+                               or a key of 512 bits or shorter which
+                               can be used for either encryption or
+                               signing.
+
+       DHE_DSS                 DSS public key.
+
+       DHE_DSS_EXPORT          DSS public key.
+
+       DHE_RSA                 RSA public key which can be used for
+                               signing.
+
+       DHE_RSA_EXPORT          RSA public key which can be used for
+                               signing.
+
+       DH_DSS                  Diffie-Hellman key. The algorithm used
+                               to sign the certificate should be DSS.
+
+       DH_RSA                  Diffie-Hellman key. The algorithm used
+                               to sign the certificate should be RSA.
+
+   All certificate profiles, key and cryptographic formats are defined
+   by the IETF PKIX working group [PKIX]. When a key usage extension is
+   present, the digitalSignature bit must be set for the key to be
+   eligible for signing, as described above, and the keyEncipherment bit
+   must be present to allow encryption, as described above. The
+   keyAgreement bit must be set on Diffie-Hellman certificates.
+
+   As CipherSuites which specify new key exchange methods are specified
+   for the TLS Protocol, they will imply certificate format and the
+   required encoded keying information.
+
+   Structure of this message:
+       opaque ASN.1Cert<1..2^24-1>;
+
+       struct {
+           ASN.1Cert certificate_list<0..2^24-1>;
+       } Certificate;
+
+
+
+Dierks & Allen              Standards Track                    [Page 38]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   certificate_list
+       This is a sequence (chain) of X.509v3 certificates. The sender's
+       certificate must come first in the list. Each following
+       certificate must directly certify the one preceding it. Because
+       certificate validation requires that root keys be distributed
+       independently, the self-signed certificate which specifies the
+       root certificate authority may optionally be omitted from the
+       chain, under the assumption that the remote end must already
+       possess it in order to validate it in any case.
+
+   The same message type and structure will be used for the client's
+   response to a certificate request message. Note that a client may
+   send no certificates if it does not have an appropriate certificate
+   to send in response to the server's authentication request.
+
+ Note: PKCS #7 [PKCS7] is not used as the format for the certificate
+       vector because PKCS #6 [PKCS6] extended certificates are not
+       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
+       the task of parsing the list more difficult.
+
+7.4.3. Server key exchange message
+
+   When this message will be sent:
+       This message will be sent immediately after the server
+       certificate message (or the server hello message, if this is an
+       anonymous negotiation).
+
+       The server key exchange message is sent by the server only when
+       the server certificate message (if sent) does not contain enough
+       data to allow the client to exchange a premaster secret. This is
+       true for the following key exchange methods:
+
+           RSA_EXPORT (if the public key in the server certificate is
+           longer than 512 bits)
+           DHE_DSS
+           DHE_DSS_EXPORT
+           DHE_RSA
+           DHE_RSA_EXPORT
+           DH_anon
+
+       It is not legal to send the server key exchange message for the
+       following key exchange methods:
+
+           RSA
+           RSA_EXPORT (when the public key in the server certificate is
+           less than or equal to 512 bits in length)
+           DH_DSS
+           DH_RSA
+
+
+
+Dierks & Allen              Standards Track                    [Page 39]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Meaning of this message:
+       This message conveys cryptographic information to allow the
+       client to communicate the premaster secret: either an RSA public
+       key to encrypt the premaster secret with, or a Diffie-Hellman
+       public key with which the client can complete a key exchange
+       (with the result being the premaster secret.)
+
+   As additional CipherSuites are defined for TLS which include new key
+   exchange algorithms, the server key exchange message will be sent if
+   and only if the certificate type associated with the key exchange
+   algorithm does not provide enough information for the client to
+   exchange a premaster secret.
+
+ Note: According to current US export law, RSA moduli larger than 512
+       bits may not be used for key exchange in software exported from
+       the US. With this message, the larger RSA keys encoded in
+       certificates may be used to sign temporary shorter RSA keys for
+       the RSA_EXPORT key exchange method.
+
+   Structure of this message:
+       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
+
+       struct {
+           opaque rsa_modulus<1..2^16-1>;
+           opaque rsa_exponent<1..2^16-1>;
+       } ServerRSAParams;
+
+       rsa_modulus
+           The modulus of the server's temporary RSA key.
+
+       rsa_exponent
+           The public exponent of the server's temporary RSA key.
+
+       struct {
+           opaque dh_p<1..2^16-1>;
+           opaque dh_g<1..2^16-1>;
+           opaque dh_Ys<1..2^16-1>;
+       } ServerDHParams;     /* Ephemeral DH parameters */
+
+       dh_p
+           The prime modulus used for the Diffie-Hellman operation.
+
+       dh_g
+           The generator used for the Diffie-Hellman operation.
+
+       dh_Ys
+           The server's Diffie-Hellman public value (g^X mod p).
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 40]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       struct {
+           select (KeyExchangeAlgorithm) {
+               case diffie_hellman:
+                   ServerDHParams params;
+                   Signature signed_params;
+               case rsa:
+                   ServerRSAParams params;
+                   Signature signed_params;
+           };
+       } ServerKeyExchange;
+
+       params
+           The server's key exchange parameters.
+
+       signed_params
+           For non-anonymous key exchanges, a hash of the corresponding
+           params value, with the signature appropriate to that hash
+           applied.
+
+       md5_hash
+           MD5(ClientHello.random + ServerHello.random + ServerParams);
+
+       sha_hash
+           SHA(ClientHello.random + ServerHello.random + ServerParams);
+
+       enum { anonymous, rsa, dsa } SignatureAlgorithm;
+
+       select (SignatureAlgorithm)
+       {   case anonymous: struct { };
+           case rsa:
+               digitally-signed struct {
+                   opaque md5_hash[16];
+                   opaque sha_hash[20];
+               };
+           case dsa:
+               digitally-signed struct {
+                   opaque sha_hash[20];
+               };
+       } Signature;
+
+7.4.4. Certificate request
+
+   When this message will be sent:
+       A non-anonymous server can optionally request a certificate from
+       the client, if appropriate for the selected cipher suite. This
+       message, if sent, will immediately follow the Server Key Exchange
+       message (if it is sent; otherwise, the Server Certificate
+       message).
+
+
+
+Dierks & Allen              Standards Track                    [Page 41]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Structure of this message:
+       enum {
+           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
+           (255)
+       } ClientCertificateType;
+
+       opaque DistinguishedName<1..2^16-1>;
+
+       struct {
+           ClientCertificateType certificate_types<1..2^8-1>;
+           DistinguishedName certificate_authorities<3..2^16-1>;
+       } CertificateRequest;
+
+       certificate_types
+              This field is a list of the types of certificates requested,
+              sorted in order of the server's preference.
+
+       certificate_authorities
+           A list of the distinguished names of acceptable certificate
+           authorities. These distinguished names may specify a desired
+           distinguished name for a root CA or for a subordinate CA;
+           thus, this message can be used both to describe known roots
+           and a desired authorization space.
+
+ Note: DistinguishedName is derived from [X509].
+
+ Note: It is a fatal handshake_failure alert for an anonymous server to
+       request client identification.
+
+7.4.5. Server hello done
+
+   When this message will be sent:
+       The server hello done message is sent by the server to indicate
+       the end of the server hello and associated messages. After
+       sending this message the server will wait for a client response.
+
+   Meaning of this message:
+       This message means that the server is done sending messages to
+       support the key exchange, and the client can proceed with its
+       phase of the key exchange.
+
+       Upon receipt of the server hello done message the client should
+       verify that the server provided a valid certificate if required
+       and check that the server hello parameters are acceptable.
+
+   Structure of this message:
+       struct { } ServerHelloDone;
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 42]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+7.4.6. Client certificate
+
+   When this message will be sent:
+       This is the first message the client can send after receiving a
+       server hello done message. This message is only sent if the
+       server requests a certificate. If no suitable certificate is
+       available, the client should send a certificate message
+       containing no certificates. If client authentication is required
+       by the server for the handshake to continue, it may respond with
+       a fatal handshake failure alert. Client certificates are sent
+       using the Certificate structure defined in Section 7.4.2.
+
+ Note: When using a static Diffie-Hellman based key exchange method
+       (DH_DSS or DH_RSA), if client authentication is requested, the
+       Diffie-Hellman group and generator encoded in the client's
+       certificate must match the server specified Diffie-Hellman
+       parameters if the client's parameters are to be used for the key
+       exchange.
+
+7.4.7. Client key exchange message
+
+   When this message will be sent:
+       This message is always sent by the client. It will immediately
+       follow the client certificate message, if it is sent. Otherwise
+       it will be the first message sent by the client after it receives
+       the server hello done message.
+
+   Meaning of this message:
+       With this message, the premaster secret is set, either though
+       direct transmission of the RSA-encrypted secret, or by the
+       transmission of Diffie-Hellman parameters which will allow each
+       side to agree upon the same premaster secret. When the key
+       exchange method is DH_RSA or DH_DSS, client certification has
+       been requested, and the client was able to respond with a
+       certificate which contained a Diffie-Hellman public key whose
+       parameters (group and generator) matched those specified by the
+       server in its certificate, this message will not contain any
+       data.
+
+   Structure of this message:
+       The choice of messages depends on which key exchange method has
+       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
+       definition.
+
+       struct {
+           select (KeyExchangeAlgorithm) {
+               case rsa: EncryptedPreMasterSecret;
+               case diffie_hellman: ClientDiffieHellmanPublic;
+
+
+
+Dierks & Allen              Standards Track                    [Page 43]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+           } exchange_keys;
+       } ClientKeyExchange;
+
+7.4.7.1. RSA encrypted premaster secret message
+
+   Meaning of this message:
+       If RSA is being used for key agreement and authentication, the
+       client generates a 48-byte premaster secret, encrypts it using
+       the public key from the server's certificate or the temporary RSA
+       key provided in a server key exchange message, and sends the
+       result in an encrypted premaster secret message. This structure
+       is a variant of the client key exchange message, not a message in
+       itself.
+
+   Structure of this message:
+       struct {
+           ProtocolVersion client_version;
+           opaque random[46];
+       } PreMasterSecret;
+
+       client_version
+           The latest (newest) version supported by the client. This is
+           used to detect version roll-back attacks. Upon receiving the
+           premaster secret, the server should check that this value
+           matches the value transmitted by the client in the client
+           hello message.
+
+       random
+           46 securely-generated random bytes.
+
+       struct {
+           public-key-encrypted PreMasterSecret pre_master_secret;
+       } EncryptedPreMasterSecret;
+
+ Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
+       to attack a TLS server which is using PKCS#1 encoded RSA. The
+       attack takes advantage of the fact that by failing in different
+       ways, a TLS server can be coerced into revealing whether a
+       particular message, when decrypted, is properly PKCS#1 formatted
+       or not.
+
+       The best way to avoid vulnerability to this attack is to treat
+       incorrectly formatted messages in a manner indistinguishable from
+       correctly formatted RSA blocks. Thus, when it receives an
+       incorrectly formatted RSA block, a server should generate a
+       random 48-byte value and proceed using it as the premaster
+       secret. Thus, the server will act identically whether the
+       received RSA block is correctly encoded or not.
+
+
+
+Dierks & Allen              Standards Track                    [Page 44]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       pre_master_secret
+           This random value is generated by the client and is used to
+           generate the master secret, as specified in Section 8.1.
+
+7.4.7.2. Client Diffie-Hellman public value
+
+   Meaning of this message:
+       This structure conveys the client's Diffie-Hellman public value
+       (Yc) if it was not already included in the client's certificate.
+       The encoding used for Yc is determined by the enumerated
+       PublicValueEncoding. This structure is a variant of the client
+       key exchange message, not a message in itself.
+
+   Structure of this message:
+       enum { implicit, explicit } PublicValueEncoding;
+
+       implicit
+           If the client certificate already contains a suitable
+           Diffie-Hellman key, then Yc is implicit and does not need to
+           be sent again. In this case, the Client Key Exchange message
+           will be sent, but will be empty.
+
+       explicit
+           Yc needs to be sent.
+
+       struct {
+           select (PublicValueEncoding) {
+               case implicit: struct { };
+               case explicit: opaque dh_Yc<1..2^16-1>;
+           } dh_public;
+       } ClientDiffieHellmanPublic;
+
+       dh_Yc
+           The client's Diffie-Hellman public value (Yc).
+
+7.4.8. Certificate verify
+
+   When this message will be sent:
+       This message is used to provide explicit verification of a client
+       certificate. This message is only sent following a client
+       certificate that has signing capability (i.e. all certificates
+       except those containing fixed Diffie-Hellman parameters). When
+       sent, it will immediately follow the client key exchange message.
+
+   Structure of this message:
+       struct {
+            Signature signature;
+       } CertificateVerify;
+
+
+
+Dierks & Allen              Standards Track                    [Page 45]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       The Signature type is defined in 7.4.3.
+
+       CertificateVerify.signature.md5_hash
+           MD5(handshake_messages);
+
+       Certificate.signature.sha_hash
+           SHA(handshake_messages);
+
+   Here handshake_messages refers to all handshake messages sent or
+   received starting at client hello up to but not including this
+   message, including the type and length fields of the handshake
+   messages. This is the concatenation of all the Handshake structures
+   as defined in 7.4 exchanged thus far.
+
+7.4.9. Finished
+
+   When this message will be sent:
+       A finished message is always sent immediately after a change
+       cipher spec message to verify that the key exchange and
+       authentication processes were successful. It is essential that a
+       change cipher spec message be received between the other
+       handshake messages and the Finished message.
+
+   Meaning of this message:
+       The finished message is the first protected with the just-
+       negotiated algorithms, keys, and secrets. Recipients of finished
+       messages must verify that the contents are correct.  Once a side
+       has sent its Finished message and received and validated the
+       Finished message from its peer, it may begin to send and receive
+       application data over the connection.
+
+       struct {
+           opaque verify_data[12];
+       } Finished;
+
+       verify_data
+           PRF(master_secret, finished_label, MD5(handshake_messages) +
+           SHA-1(handshake_messages)) [0..11];
+
+       finished_label
+           For Finished messages sent by the client, the string "client
+           finished". For Finished messages sent by the server, the
+           string "server finished".
+
+       handshake_messages
+           All of the data from all handshake messages up to but not
+           including this message. This is only data visible at the
+           handshake layer and does not include record layer headers.
+
+
+
+Dierks & Allen              Standards Track                    [Page 46]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+           This is the concatenation of all the Handshake structures as
+           defined in 7.4 exchanged thus far.
+
+   It is a fatal error if a finished message is not preceded by a change
+   cipher spec message at the appropriate point in the handshake.
+
+   The hash contained in finished messages sent by the server
+   incorporate Sender.server; those sent by the client incorporate
+   Sender.client. The value handshake_messages includes all handshake
+   messages starting at client hello up to, but not including, this
+   finished message. This may be different from handshake_messages in
+   Section 7.4.8 because it would include the certificate verify message
+   (if sent). Also, the handshake_messages for the finished message sent
+   by the client will be different from that for the finished message
+   sent by the server, because the one which is sent second will include
+   the prior one.
+
+ Note: Change cipher spec messages, alerts and any other record types
+       are not handshake messages and are not included in the hash
+       computations. Also, Hello Request messages are omitted from
+       handshake hashes.
+
+8. Cryptographic computations
+
+   In order to begin connection protection, the TLS Record Protocol
+   requires specification of a suite of algorithms, a master secret, and
+   the client and server random values. The authentication, encryption,
+   and MAC algorithms are determined by the cipher_suite selected by the
+   server and revealed in the server hello message. The compression
+   algorithm is negotiated in the hello messages, and the random values
+   are exchanged in the hello messages. All that remains is to calculate
+   the master secret.
+
+8.1. Computing the master secret
+
+   For all key exchange methods, the same algorithm is used to convert
+   the pre_master_secret into the master_secret. The pre_master_secret
+   should be deleted from memory once the master_secret has been
+   computed.
+
+       master_secret = PRF(pre_master_secret, "master secret",
+                           ClientHello.random + ServerHello.random)
+       [0..47];
+
+   The master secret is always exactly 48 bytes in length. The length of
+   the premaster secret will vary depending on key exchange method.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 47]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+8.1.1. RSA
+
+   When RSA is used for server authentication and key exchange, a 48-
+   byte pre_master_secret is generated by the client, encrypted under
+   the server's public key, and sent to the server. The server uses its
+   private key to decrypt the pre_master_secret. Both parties then
+   convert the pre_master_secret into the master_secret, as specified
+   above.
+
+   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
+   1. RSA public key encryption is performed using PKCS #1 block type 2.
+
+8.1.2. Diffie-Hellman
+
+   A conventional Diffie-Hellman computation is performed. The
+   negotiated key (Z) is used as the pre_master_secret, and is converted
+   into the master_secret, as specified above.
+
+ Note: Diffie-Hellman parameters are specified by the server, and may
+       be either ephemeral or contained within the server's certificate.
+
+9. Mandatory Cipher Suites
+
+   In the absence of an application profile standard specifying
+   otherwise, a TLS compliant application MUST implement the cipher
+   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
+
+10. Application data protocol
+
+   Application data messages are carried by the Record Layer and are
+   fragmented, compressed and encrypted based on the current connection
+   state. The messages are treated as transparent data to the record
+   layer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 48]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+A. Protocol constant values
+
+   This section describes protocol types and constants.
+
+A.1. Record layer
+
+    struct {
+        uint8 major, minor;
+    } ProtocolVersion;
+
+    ProtocolVersion version = { 3, 1 };     /* TLS v1.0 */
+
+    enum {
+        change_cipher_spec(20), alert(21), handshake(22),
+        application_data(23), (255)
+    } ContentType;
+
+    struct {
+        ContentType type;
+        ProtocolVersion version;
+        uint16 length;
+        opaque fragment[TLSPlaintext.length];
+    } TLSPlaintext;
+
+    struct {
+        ContentType type;
+        ProtocolVersion version;
+        uint16 length;
+        opaque fragment[TLSCompressed.length];
+    } TLSCompressed;
+
+    struct {
+        ContentType type;
+        ProtocolVersion version;
+        uint16 length;
+        select (CipherSpec.cipher_type) {
+            case stream: GenericStreamCipher;
+            case block:  GenericBlockCipher;
+        } fragment;
+    } TLSCiphertext;
+
+    stream-ciphered struct {
+        opaque content[TLSCompressed.length];
+        opaque MAC[CipherSpec.hash_size];
+    } GenericStreamCipher;
+
+    block-ciphered struct {
+        opaque content[TLSCompressed.length];
+
+
+
+Dierks & Allen              Standards Track                    [Page 49]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+        opaque MAC[CipherSpec.hash_size];
+        uint8 padding[GenericBlockCipher.padding_length];
+        uint8 padding_length;
+    } GenericBlockCipher;
+
+A.2. Change cipher specs message
+
+    struct {
+        enum { change_cipher_spec(1), (255) } type;
+    } ChangeCipherSpec;
+
+A.3. Alert messages
+
+    enum { warning(1), fatal(2), (255) } AlertLevel;
+
+        enum {
+            close_notify(0),
+            unexpected_message(10),
+            bad_record_mac(20),
+            decryption_failed(21),
+            record_overflow(22),
+            decompression_failure(30),
+            handshake_failure(40),
+            bad_certificate(42),
+            unsupported_certificate(43),
+            certificate_revoked(44),
+            certificate_expired(45),
+            certificate_unknown(46),
+            illegal_parameter(47),
+            unknown_ca(48),
+            access_denied(49),
+            decode_error(50),
+            decrypt_error(51),
+            export_restriction(60),
+            protocol_version(70),
+            insufficient_security(71),
+            internal_error(80),
+            user_canceled(90),
+            no_renegotiation(100),
+            (255)
+        } AlertDescription;
+
+    struct {
+        AlertLevel level;
+        AlertDescription description;
+    } Alert;
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 50]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+A.4. Handshake protocol
+
+    enum {
+        hello_request(0), client_hello(1), server_hello(2),
+        certificate(11), server_key_exchange (12),
+        certificate_request(13), server_hello_done(14),
+        certificate_verify(15), client_key_exchange(16),
+        finished(20), (255)
+    } HandshakeType;
+
+    struct {
+        HandshakeType msg_type;
+        uint24 length;
+        select (HandshakeType) {
+            case hello_request:       HelloRequest;
+            case client_hello:        ClientHello;
+            case server_hello:        ServerHello;
+            case certificate:         Certificate;
+            case server_key_exchange: ServerKeyExchange;
+            case certificate_request: CertificateRequest;
+            case server_hello_done:   ServerHelloDone;
+            case certificate_verify:  CertificateVerify;
+            case client_key_exchange: ClientKeyExchange;
+            case finished:            Finished;
+        } body;
+    } Handshake;
+
+A.4.1. Hello messages
+
+    struct { } HelloRequest;
+
+    struct {
+        uint32 gmt_unix_time;
+        opaque random_bytes[28];
+    } Random;
+
+    opaque SessionID<0..32>;
+
+    uint8 CipherSuite[2];
+
+    enum { null(0), (255) } CompressionMethod;
+
+    struct {
+        ProtocolVersion client_version;
+        Random random;
+        SessionID session_id;
+        CipherSuite cipher_suites<2..2^16-1>;
+        CompressionMethod compression_methods<1..2^8-1>;
+
+
+
+Dierks & Allen              Standards Track                    [Page 51]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+    } ClientHello;
+
+    struct {
+        ProtocolVersion server_version;
+        Random random;
+        SessionID session_id;
+        CipherSuite cipher_suite;
+        CompressionMethod compression_method;
+    } ServerHello;
+
+A.4.2. Server authentication and key exchange messages
+
+    opaque ASN.1Cert<2^24-1>;
+
+    struct {
+        ASN.1Cert certificate_list<1..2^24-1>;
+    } Certificate;
+
+    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
+
+    struct {
+        opaque RSA_modulus<1..2^16-1>;
+        opaque RSA_exponent<1..2^16-1>;
+    } ServerRSAParams;
+
+    struct {
+        opaque DH_p<1..2^16-1>;
+        opaque DH_g<1..2^16-1>;
+        opaque DH_Ys<1..2^16-1>;
+    } ServerDHParams;
+
+    struct {
+        select (KeyExchangeAlgorithm) {
+            case diffie_hellman:
+                ServerDHParams params;
+                Signature signed_params;
+            case rsa:
+                ServerRSAParams params;
+                Signature signed_params;
+        };
+    } ServerKeyExchange;
+
+    enum { anonymous, rsa, dsa } SignatureAlgorithm;
+
+    select (SignatureAlgorithm)
+    {   case anonymous: struct { };
+        case rsa:
+            digitally-signed struct {
+
+
+
+Dierks & Allen              Standards Track                    [Page 52]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+                opaque md5_hash[16];
+                opaque sha_hash[20];
+            };
+        case dsa:
+            digitally-signed struct {
+                opaque sha_hash[20];
+            };
+    } Signature;
+
+    enum {
+        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
+        (255)
+    } ClientCertificateType;
+
+    opaque DistinguishedName<1..2^16-1>;
+
+    struct {
+        ClientCertificateType certificate_types<1..2^8-1>;
+        DistinguishedName certificate_authorities<3..2^16-1>;
+    } CertificateRequest;
+
+    struct { } ServerHelloDone;
+
+A.4.3. Client authentication and key exchange messages
+
+    struct {
+        select (KeyExchangeAlgorithm) {
+            case rsa: EncryptedPreMasterSecret;
+            case diffie_hellman: DiffieHellmanClientPublicValue;
+        } exchange_keys;
+    } ClientKeyExchange;
+
+    struct {
+        ProtocolVersion client_version;
+        opaque random[46];
+
+    } PreMasterSecret;
+
+    struct {
+        public-key-encrypted PreMasterSecret pre_master_secret;
+    } EncryptedPreMasterSecret;
+
+    enum { implicit, explicit } PublicValueEncoding;
+
+    struct {
+        select (PublicValueEncoding) {
+            case implicit: struct {};
+            case explicit: opaque DH_Yc<1..2^16-1>;
+
+
+
+Dierks & Allen              Standards Track                    [Page 53]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+        } dh_public;
+    } ClientDiffieHellmanPublic;
+
+    struct {
+        Signature signature;
+    } CertificateVerify;
+
+A.4.4. Handshake finalization message
+
+    struct {
+        opaque verify_data[12];
+    } Finished;
+
+A.5. The CipherSuite
+
+   The following values define the CipherSuite codes used in the client
+   hello and server hello messages.
+
+   A CipherSuite defines a cipher specification supported in TLS Version
+   1.0.
+
+   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
+   TLS connection during the first handshake on that channel, but must
+   not be negotiated, as it provides no more protection than an
+   unsecured connection.
+
+    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
+
+   The following CipherSuite definitions require that the server provide
+   an RSA certificate that can be used for key exchange. The server may
+   request either an RSA or a DSS signature-capable certificate in the
+   certificate request message.
+
+    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
+    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
+    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
+    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
+    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
+    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
+    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
+    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
+    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
+    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
+
+   The following CipherSuite definitions are used for server-
+   authenticated (and optionally client-authenticated) Diffie-Hellman.
+   DH denotes cipher suites in which the server's certificate contains
+   the Diffie-Hellman parameters signed by the certificate authority
+
+
+
+Dierks & Allen              Standards Track                    [Page 54]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
+   parameters are signed by a DSS or RSA certificate, which has been
+   signed by the CA. The signing algorithm used is specified after the
+   DH or DHE parameter. The server can request an RSA or DSS signature-
+   capable certificate from the client for client authentication or it
+   may request a Diffie-Hellman certificate. Any Diffie-Hellman
+   certificate provided by the client must use the parameters (group and
+   generator) described by the server.
+
+    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
+    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
+    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
+    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
+    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
+    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
+    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
+    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
+    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
+    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
+    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
+    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
+
+   The following cipher suites are used for completely anonymous
+   Diffie-Hellman communications in which neither party is
+   authenticated. Note that this mode is vulnerable to man-in-the-middle
+   attacks and is therefore deprecated.
+
+    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
+    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
+    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
+    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
+    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
+
+ Note: All cipher suites whose first byte is 0xFF are considered
+       private and can be used for defining local/experimental
+       algorithms. Interoperability of such types is a local matter.
+
+ Note: Additional cipher suites can be registered by publishing an RFC
+       which specifies the cipher suites, including the necessary TLS
+       protocol information, including message encoding, premaster
+       secret derivation, symmetric encryption and MAC calculation and
+       appropriate reference information for the algorithms involved.
+       The RFC editor's office may, at its discretion, choose to publish
+       specifications for cipher suites which are not completely
+       described (e.g., for classified algorithms) if it finds the
+       specification to be of technical interest and completely
+       specified.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 55]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+ Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
+       reserved to avoid collision with Fortezza-based cipher suites in
+       SSL 3.
+
+A.6. The Security Parameters
+
+   These security parameters are determined by the TLS Handshake
+   Protocol and provided as parameters to the TLS Record Layer in order
+   to initialize a connection state. SecurityParameters includes:
+
+       enum { null(0), (255) } CompressionMethod;
+
+       enum { server, client } ConnectionEnd;
+
+       enum { null, rc4, rc2, des, 3des, des40, idea }
+       BulkCipherAlgorithm;
+
+       enum { stream, block } CipherType;
+
+       enum { true, false } IsExportable;
+
+       enum { null, md5, sha } MACAlgorithm;
+
+   /* The algorithms specified in CompressionMethod,
+   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
+
+       struct {
+           ConnectionEnd entity;
+           BulkCipherAlgorithm bulk_cipher_algorithm;
+           CipherType cipher_type;
+           uint8 key_size;
+           uint8 key_material_length;
+           IsExportable is_exportable;
+           MACAlgorithm mac_algorithm;
+           uint8 hash_size;
+           CompressionMethod compression_algorithm;
+           opaque master_secret[48];
+           opaque client_random[32];
+           opaque server_random[32];
+       } SecurityParameters;
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 56]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+B. Glossary
+
+   application protocol
+       An application protocol is a protocol that normally layers
+       directly on top of the transport layer (e.g., TCP/IP). Examples
+       include HTTP, TELNET, FTP, and SMTP.
+
+   asymmetric cipher
+       See public key cryptography.
+
+   authentication
+       Authentication is the ability of one entity to determine the
+       identity of another entity.
+
+   block cipher
+       A block cipher is an algorithm that operates on plaintext in
+       groups of bits, called blocks. 64 bits is a common block size.
+
+   bulk cipher
+       A symmetric encryption algorithm used to encrypt large quantities
+       of data.
+
+   cipher block chaining (CBC)
+       CBC is a mode in which every plaintext block encrypted with a
+       block cipher is first exclusive-ORed with the previous ciphertext
+       block (or, in the case of the first block, with the
+       initialization vector). For decryption, every block is first
+       decrypted, then exclusive-ORed with the previous ciphertext block
+       (or IV).
+
+   certificate
+       As part of the X.509 protocol (a.k.a. ISO Authentication
+       framework), certificates are assigned by a trusted Certificate
+       Authority and provide a strong binding between a party's identity
+       or some other attributes and its public key.
+
+   client
+       The application entity that initiates a TLS connection to a
+       server. This may or may not imply that the client initiated the
+       underlying transport connection. The primary operational
+       difference between the server and client is that the server is
+       generally authenticated, while the client is only optionally
+       authenticated.
+
+   client write key
+       The key used to encrypt data written by the client.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 57]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   client write MAC secret
+       The secret data used to authenticate data written by the client.
+
+   connection
+       A connection is a transport (in the OSI layering model
+       definition) that provides a suitable type of service. For TLS,
+       such connections are peer to peer relationships. The connections
+       are transient. Every connection is associated with one session.
+
+   Data Encryption Standard
+       DES is a very widely used symmetric encryption algorithm. DES is
+       a block cipher with a 56 bit key and an 8 byte block size. Note
+       that in TLS, for key generation purposes, DES is treated as
+       having an 8 byte key length (64 bits), but it still only provides
+       56 bits of protection. (The low bit of each key byte is presumed
+       to be set to produce odd parity in that key byte.) DES can also
+       be operated in a mode where three independent keys and three
+       encryptions are used for each block of data; this uses 168 bits
+       of key (24 bytes in the TLS key generation method) and provides
+       the equivalent of 112 bits of security. [DES], [3DES]
+
+   Digital Signature Standard (DSS)
+       A standard for digital signing, including the Digital Signing
+       Algorithm, approved by the National Institute of Standards and
+       Technology, defined in NIST FIPS PUB 186, "Digital Signature
+       Standard," published May, 1994 by the U.S. Dept. of Commerce.
+       [DSS]
+
+   digital signatures
+       Digital signatures utilize public key cryptography and one-way
+       hash functions to produce a signature of the data that can be
+       authenticated, and is difficult to forge or repudiate.
+
+   handshake
+       An initial negotiation between client and server that establishes
+       the parameters of their transactions.
+
+   Initialization Vector (IV)
+       When a block cipher is used in CBC mode, the initialization
+       vector is exclusive-ORed with the first plaintext block prior to
+       encryption.
+
+   IDEA
+       A 64-bit block cipher designed by Xuejia Lai and James Massey.
+       [IDEA]
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 58]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Message Authentication Code (MAC)
+       A Message Authentication Code is a one-way hash computed from a
+       message and some secret data. It is difficult to forge without
+       knowing the secret data. Its purpose is to detect if the message
+       has been altered.
+
+   master secret
+       Secure secret data used for generating encryption keys, MAC
+       secrets, and IVs.
+
+   MD5
+       MD5 is a secure hashing function that converts an arbitrarily
+       long data stream into a digest of fixed size (16 bytes). [MD5]
+
+   public key cryptography
+       A class of cryptographic techniques employing two-key ciphers.
+       Messages encrypted with the public key can only be decrypted with
+       the associated private key. Conversely, messages signed with the
+       private key can be verified with the public key.
+
+   one-way hash function
+       A one-way transformation that converts an arbitrary amount of
+       data into a fixed-length hash. It is computationally hard to
+       reverse the transformation or to find collisions. MD5 and SHA are
+       examples of one-way hash functions.
+
+   RC2
+       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
+       [RSADSI] described in [RC2].
+
+   RC4
+       A stream cipher licensed by RSA Data Security [RSADSI]. A
+       compatible cipher is described in [RC4].
+
+   RSA
+       A very widely used public-key algorithm that can be used for
+       either encryption or digital signing. [RSA]
+
+   salt
+       Non-secret random data used to make export encryption keys resist
+       precomputation attacks.
+
+   server
+       The server is the application entity that responds to requests
+       for connections from clients. See also under client.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 59]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   session
+       A TLS session is an association between a client and a server.
+       Sessions are created by the handshake protocol. Sessions define a
+       set of cryptographic security parameters, which can be shared
+       among multiple connections. Sessions are used to avoid the
+       expensive negotiation of new security parameters for each
+       connection.
+
+   session identifier
+       A session identifier is a value generated by a server that
+       identifies a particular session.
+
+   server write key
+       The key used to encrypt data written by the server.
+
+   server write MAC secret
+       The secret data used to authenticate data written by the server.
+
+   SHA
+       The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
+       produces a 20-byte output. Note that all references to SHA
+       actually use the modified SHA-1 algorithm. [SHA]
+
+   SSL
+       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
+       SSL Version 3.0
+
+   stream cipher
+       An encryption algorithm that converts a key into a
+       cryptographically-strong keystream, which is then exclusive-ORed
+       with the plaintext.
+
+   symmetric cipher
+       See bulk cipher.
+
+   Transport Layer Security (TLS)
+       This protocol; also, the Transport Layer Security working group
+       of the Internet Engineering Task Force (IETF). See "Comments" at
+       the end of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 60]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+C. CipherSuite definitions
+
+CipherSuite                      Is       Key          Cipher      Hash
+                             Exportable Exchange
+
+TLS_NULL_WITH_NULL_NULL               * NULL           NULL        NULL
+TLS_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5
+TLS_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA
+TLS_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5
+TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
+TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
+TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5
+TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
+TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA
+TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
+TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
+TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA
+TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
+TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
+TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA
+TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
+TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
+TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA
+TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
+TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA
+TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
+TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5
+TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
+TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA
+TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
+TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
+
+
+   * Indicates IsExportable is True
+
+      Key
+      Exchange
+      Algorithm       Description                        Key size limit
+
+      DHE_DSS         Ephemeral DH with DSS signatures   None
+      DHE_DSS_EXPORT  Ephemeral DH with DSS signatures   DH = 512 bits
+      DHE_RSA         Ephemeral DH with RSA signatures   None
+      DHE_RSA_EXPORT  Ephemeral DH with RSA signatures   DH = 512 bits,
+                                                         RSA = none
+      DH_anon         Anonymous DH, no signatures        None
+      DH_anon_EXPORT  Anonymous DH, no signatures        DH = 512 bits
+
+
+
+Dierks & Allen              Standards Track                    [Page 61]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+      DH_DSS          DH with DSS-based certificates     None
+      DH_DSS_EXPORT   DH with DSS-based certificates     DH = 512 bits
+      DH_RSA          DH with RSA-based certificates     None
+      DH_RSA_EXPORT   DH with RSA-based certificates     DH = 512 bits,
+                                                         RSA = none
+      NULL            No key exchange                    N/A
+      RSA             RSA key exchange                   None
+      RSA_EXPORT      RSA key exchange                   RSA = 512 bits
+
+   Key size limit
+       The key size limit gives the size of the largest public key that
+       can be legally used for encryption in cipher suites that are
+       exportable.
+
+                         Key      Expanded   Effective   IV    Block
+    Cipher       Type  Material Key Material  Key Bits  Size   Size
+
+    NULL       * Stream   0          0           0        0     N/A
+    IDEA_CBC     Block   16         16         128        8      8
+    RC2_CBC_40 * Block    5         16          40        8      8
+    RC4_40     * Stream   5         16          40        0     N/A
+    RC4_128      Stream  16         16         128        0     N/A
+    DES40_CBC  * Block    5          8          40        8      8
+    DES_CBC      Block    8          8          56        8      8
+    3DES_EDE_CBC Block   24         24         168        8      8
+
+   * Indicates IsExportable is true.
+
+   Type
+       Indicates whether this is a stream cipher or a block cipher
+       running in CBC mode.
+
+   Key Material
+       The number of bytes from the key_block that are used for
+       generating the write keys.
+
+   Expanded Key Material
+       The number of bytes actually fed into the encryption algorithm
+
+   Effective Key Bits
+       How much entropy material is in the key material being fed into
+       the encryption routines.
+
+   IV Size
+       How much data needs to be generated for the initialization
+       vector. Zero for stream ciphers; equal to the block size for
+       block ciphers.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 62]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Block Size
+       The amount of data a block cipher enciphers in one chunk; a
+       block cipher running in CBC mode can only encrypt an even
+       multiple of its block size.
+
+      Hash      Hash      Padding
+    function    Size       Size
+      NULL       0          0
+      MD5        16         48
+      SHA        20         40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 63]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+D. Implementation Notes
+
+   The TLS protocol cannot prevent many common security mistakes. This
+   section provides several recommendations to assist implementors.
+
+D.1. Temporary RSA keys
+
+   US Export restrictions limit RSA keys used for encryption to 512
+   bits, but do not place any limit on lengths of RSA keys used for
+   signing operations. Certificates often need to be larger than 512
+   bits, since 512-bit RSA keys are not secure enough for high-value
+   transactions or for applications requiring long-term security. Some
+   certificates are also designated signing-only, in which case they
+   cannot be used for key exchange.
+
+   When the public key in the certificate cannot be used for encryption,
+   the server signs a temporary RSA key, which is then exchanged. In
+   exportable applications, the temporary RSA key should be the maximum
+   allowable length (i.e., 512 bits). Because 512-bit RSA keys are
+   relatively insecure, they should be changed often. For typical
+   electronic commerce applications, it is suggested that keys be
+   changed daily or every 500 transactions, and more often if possible.
+   Note that while it is acceptable to use the same temporary key for
+   multiple transactions, it must be signed each time it is used.
+
+   RSA key generation is a time-consuming process. In many cases, a
+   low-priority process can be assigned the task of key generation.
+
+   Whenever a new key is completed, the existing temporary key can be
+   replaced with the new one.
+
+D.2. Random Number Generation and Seeding
+
+   TLS requires a cryptographically-secure pseudorandom number generator
+   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
+   based on secure hash operations, most notably MD5 and/or SHA, are
+   acceptable, but cannot provide more security than the size of the
+   random number generator state. (For example, MD5-based PRNGs usually
+   provide 128 bits of state.)
+
+   To estimate the amount of seed material being produced, add the
+   number of bits of unpredictable information in each seed byte. For
+   example, keystroke timing values taken from a PC compatible's 18.2 Hz
+   timer provide 1 or 2 secure bits each, even though the total size of
+   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
+   would thus require approximately 100 such timer values.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 64]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+ Warning: The seeding functions in RSAREF and versions of BSAFE prior to
+          3.0 are order-independent. For example, if 1000 seed bits are
+          supplied, one at a time, in 1000 separate calls to the seed
+          function, the PRNG will end up in a state which depends only
+          on the number of 0 or 1 seed bits in the seed data (i.e.,
+          there are 1001 possible final states). Applications using
+          BSAFE or RSAREF must take extra care to ensure proper seeding.
+          This may be accomplished by accumulating seed bits into a
+          buffer and processing them all at once or by processing an
+          incrementing counter with every seed bit; either method will
+          reintroduce order dependence into the seeding process.
+
+D.3. Certificates and authentication
+
+   Implementations are responsible for verifying the integrity of
+   certificates and should generally support certificate revocation
+   messages. Certificates should always be verified to ensure proper
+   signing by a trusted Certificate Authority (CA). The selection and
+   addition of trusted CAs should be done very carefully. Users should
+   be able to view information about the certificate and root CA.
+
+D.4. CipherSuites
+
+   TLS supports a range of key sizes and security levels, including some
+   which provide no or minimal security. A proper implementation will
+   probably not support many cipher suites. For example, 40-bit
+   encryption is easily broken, so implementations requiring strong
+   security should not allow 40-bit keys. Similarly, anonymous Diffie-
+   Hellman is strongly discouraged because it cannot prevent man-in-
+   the-middle attacks. Applications should also enforce minimum and
+   maximum key sizes. For example, certificate chains containing 512-bit
+   RSA keys or signatures are not appropriate for high-security
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 65]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+E. Backward Compatibility With SSL
+
+   For historical reasons and in order to avoid a profligate consumption
+   of reserved port numbers, application protocols which are secured by
+   TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
+   connection port: for example, the https protocol (HTTP secured by SSL
+   or TLS) uses port 443 regardless of which security protocol it is
+   using. Thus, some mechanism must be determined to distinguish and
+   negotiate among the various protocols.
+
+   TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
+   is easy. TLS clients who wish to negotiate with SSL 3.0 servers
+   should send client hello messages using the SSL 3.0 record format and
+   client hello structure, sending {3, 1} for the version field to note
+   that they support TLS 1.0. If the server supports only SSL 3.0, it
+   will respond with an SSL 3.0 server hello; if it supports TLS, with a
+   TLS server hello. The negotiation then proceeds as appropriate for
+   the negotiated protocol.
+
+   Similarly, a TLS server which wishes to interoperate with SSL 3.0
+   clients should accept SSL 3.0 client hello messages and respond with
+   an SSL 3.0 server hello if an SSL 3.0 client hello is received which
+   has a version field of {3, 0}, denoting that this client does not
+   support TLS.
+
+   Whenever a client already knows the highest protocol known to a
+   server (for example, when resuming a session), it should initiate the
+   connection in that native protocol.
+
+   TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
+   Version 2.0 client hello messages [SSL2]. TLS servers should accept
+   either client hello format if they wish to support SSL 2.0 clients on
+   the same connection port. The only deviations from the Version 2.0
+   specification are the ability to specify a version with a value of
+   three and the support for more ciphering types in the CipherSpec.
+
+ Warning: The ability to send Version 2.0 client hello messages will be
+          phased out with all due haste. Implementors should make every
+          effort to move forward as quickly as possible. Version 3.0
+          provides better mechanisms for moving to newer versions.
+
+   The following cipher specifications are carryovers from SSL Version
+   2.0. These are assumed to use RSA for key exchange and
+   authentication.
+
+       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
+       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
+       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
+
+
+
+Dierks & Allen              Standards Track                    [Page 66]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
+                                                  = { 0x04,0x00,0x80 };
+       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
+       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
+       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
+
+   Cipher specifications native to TLS can be included in Version 2.0
+   client hello messages using the syntax below. Any V2CipherSpec
+   element with its first byte equal to zero will be ignored by Version
+   2.0 servers. Clients sending any of the above V2CipherSpecs should
+   also include the TLS equivalent (see Appendix A.5):
+
+       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
+
+E.1. Version 2 client hello
+
+   The Version 2.0 client hello message is presented below using this
+   document's presentation model. The true definition is still assumed
+   to be the SSL Version 2.0 specification.
+
+       uint8 V2CipherSpec[3];
+
+       struct {
+           uint8 msg_type;
+           Version version;
+           uint16 cipher_spec_length;
+           uint16 session_id_length;
+           uint16 challenge_length;
+           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
+           opaque session_id[V2ClientHello.session_id_length];
+           Random challenge;
+       } V2ClientHello;
+
+   msg_type
+       This field, in conjunction with the version field, identifies a
+       version 2 client hello message. The value should be one (1).
+
+   version
+       The highest version of the protocol supported by the client
+       (equals ProtocolVersion.version, see Appendix A.1).
+
+   cipher_spec_length
+       This field is the total length of the field cipher_specs. It
+       cannot be zero and must be a multiple of the V2CipherSpec length
+       (3).
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 67]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   session_id_length
+       This field must have a value of either zero or 16. If zero, the
+       client is creating a new session. If 16, the session_id field
+       will contain the 16 bytes of session identification.
+
+   challenge_length
+       The length in bytes of the client's challenge to the server to
+       authenticate itself. This value must be 32.
+
+   cipher_specs
+       This is a list of all CipherSpecs the client is willing and able
+       to use. There must be at least one CipherSpec acceptable to the
+       server.
+
+   session_id
+       If this field's length is not zero, it will contain the
+       identification for a session that the client wishes to resume.
+
+   challenge
+       The client challenge to the server for the server to identify
+       itself is a (nearly) arbitrary length random. The TLS server will
+       right justify the challenge data to become the ClientHello.random
+       data (padded with leading zeroes, if necessary), as specified in
+       this protocol specification. If the length of the challenge is
+       greater than 32 bytes, only the last 32 bytes are used. It is
+       legitimate (but not necessary) for a V3 server to reject a V2
+       ClientHello that has fewer than 16 bytes of challenge data.
+
+ Note: Requests to resume a TLS session should use a TLS client hello.
+
+E.2. Avoiding man-in-the-middle version rollback
+
+   When TLS clients fall back to Version 2.0 compatibility mode, they
+   should use special PKCS #1 block formatting. This is done so that TLS
+   servers will reject Version 2.0 sessions with TLS-capable clients.
+
+   When TLS clients are in Version 2.0 compatibility mode, they set the
+   right-hand (least-significant) 8 random bytes of the PKCS padding
+   (not including the terminal null of the padding) for the RSA
+   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
+   to 0x03 (the other padding bytes are random). After decrypting the
+   ENCRYPTED-KEY-DATA field, servers that support TLS should issue an
+   error if these eight padding bytes are 0x03. Version 2.0 servers
+   receiving blocks padded in this manner will proceed normally.
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 68]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+F. Security analysis
+
+   The TLS protocol is designed to establish a secure connection between
+   a client and a server communicating over an insecure channel. This
+   document makes several traditional assumptions, including that
+   attackers have substantial computational resources and cannot obtain
+   secret information from sources outside the protocol. Attackers are
+   assumed to have the ability to capture, modify, delete, replay, and
+   otherwise tamper with messages sent over the communication channel.
+   This appendix outlines how TLS has been designed to resist a variety
+   of attacks.
+
+F.1. Handshake protocol
+
+   The handshake protocol is responsible for selecting a CipherSpec and
+   generating a Master Secret, which together comprise the primary
+   cryptographic parameters associated with a secure session. The
+   handshake protocol can also optionally authenticate parties who have
+   certificates signed by a trusted certificate authority.
+
+F.1.1. Authentication and key exchange
+
+   TLS supports three authentication modes: authentication of both
+   parties, server authentication with an unauthenticated client, and
+   total anonymity. Whenever the server is authenticated, the channel is
+   secure against man-in-the-middle attacks, but completely anonymous
+   sessions are inherently vulnerable to such attacks.  Anonymous
+   servers cannot authenticate clients. If the server is authenticated,
+   its certificate message must provide a valid certificate chain
+   leading to an acceptable certificate authority.  Similarly,
+   authenticated clients must supply an acceptable certificate to the
+   server. Each party is responsible for verifying that the other's
+   certificate is valid and has not expired or been revoked.
+
+   The general goal of the key exchange process is to create a
+   pre_master_secret known to the communicating parties and not to
+   attackers. The pre_master_secret will be used to generate the
+   master_secret (see Section 8.1). The master_secret is required to
+   generate the certificate verify and finished messages, encryption
+   keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
+   a correct finished message, parties thus prove that they know the
+   correct pre_master_secret.
+
+F.1.1.1. Anonymous key exchange
+
+   Completely anonymous sessions can be established using RSA or
+   Diffie-Hellman for key exchange. With anonymous RSA, the client
+   encrypts a pre_master_secret with the server's uncertified public key
+
+
+
+Dierks & Allen              Standards Track                    [Page 69]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   extracted from the server key exchange message. The result is sent in
+   a client key exchange message. Since eavesdroppers do not know the
+   server's private key, it will be infeasible for them to decode the
+   pre_master_secret. (Note that no anonymous RSA Cipher Suites are
+   defined in this document).
+
+   With Diffie-Hellman, the server's public parameters are contained in
+   the server key exchange message and the client's are sent in the
+   client key exchange message. Eavesdroppers who do not know the
+   private values should not be able to find the Diffie-Hellman result
+   (i.e. the pre_master_secret).
+
+ Warning: Completely anonymous connections only provide protection
+          against passive eavesdropping. Unless an independent tamper-
+          proof channel is used to verify that the finished messages
+          were not replaced by an attacker, server authentication is
+          required in environments where active man-in-the-middle
+          attacks are a concern.
+
+F.1.1.2. RSA key exchange and authentication
+
+   With RSA, key exchange and server authentication are combined. The
+   public key may be either contained in the server's certificate or may
+   be a temporary RSA key sent in a server key exchange message.  When
+   temporary RSA keys are used, they are signed by the server's RSA or
+   DSS certificate. The signature includes the current
+   ClientHello.random, so old signatures and temporary keys cannot be
+   replayed. Servers may use a single temporary RSA key for multiple
+   negotiation sessions.
+
+ Note: The temporary RSA key option is useful if servers need large
+       certificates but must comply with government-imposed size limits
+       on keys used for key exchange.
+
+   After verifying the server's certificate, the client encrypts a
+   pre_master_secret with the server's public key. By successfully
+   decoding the pre_master_secret and producing a correct finished
+   message, the server demonstrates that it knows the private key
+   corresponding to the server certificate.
+
+   When RSA is used for key exchange, clients are authenticated using
+   the certificate verify message (see Section 7.4.8). The client signs
+   a value derived from the master_secret and all preceding handshake
+   messages. These handshake messages include the server certificate,
+   which binds the signature to the server, and ServerHello.random,
+   which binds the signature to the current handshake process.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 70]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+F.1.1.3. Diffie-Hellman key exchange with authentication
+
+   When Diffie-Hellman key exchange is used, the server can either
+   supply a certificate containing fixed Diffie-Hellman parameters or
+   can use the server key exchange message to send a set of temporary
+   Diffie-Hellman parameters signed with a DSS or RSA certificate.
+   Temporary parameters are hashed with the hello.random values before
+   signing to ensure that attackers do not replay old parameters. In
+   either case, the client can verify the certificate or signature to
+   ensure that the parameters belong to the server.
+
+   If the client has a certificate containing fixed Diffie-Hellman
+   parameters, its certificate contains the information required to
+   complete the key exchange. Note that in this case the client and
+   server will generate the same Diffie-Hellman result (i.e.,
+   pre_master_secret) every time they communicate. To prevent the
+   pre_master_secret from staying in memory any longer than necessary,
+   it should be converted into the master_secret as soon as possible.
+   Client Diffie-Hellman parameters must be compatible with those
+   supplied by the server for the key exchange to work.
+
+   If the client has a standard DSS or RSA certificate or is
+   unauthenticated, it sends a set of temporary parameters to the server
+   in the client key exchange message, then optionally uses a
+   certificate verify message to authenticate itself.
+
+F.1.2. Version rollback attacks
+
+   Because TLS includes substantial improvements over SSL Version 2.0,
+   attackers may try to make TLS-capable clients and servers fall back
+   to Version 2.0. This attack can occur if (and only if) two TLS-
+   capable parties use an SSL 2.0 handshake.
+
+   Although the solution using non-random PKCS #1 block type 2 message
+   padding is inelegant, it provides a reasonably secure way for Version
+   3.0 servers to detect the attack. This solution is not secure against
+   attackers who can brute force the key and substitute a new
+   ENCRYPTED-KEY-DATA message containing the same key (but with normal
+   padding) before the application specified wait threshold has expired.
+   Parties concerned about attacks of this scale should not be using
+   40-bit encryption keys anyway. Altering the padding of the least-
+   significant 8 bytes of the PKCS padding does not impact security for
+   the size of the signed hashes and RSA key lengths used in the
+   protocol, since this is essentially equivalent to increasing the
+   input block size by 8 bytes.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 71]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+F.1.3. Detecting attacks against the handshake protocol
+
+   An attacker might try to influence the handshake exchange to make the
+   parties select different encryption algorithms than they would
+   normally choose. Because many implementations will support 40-bit
+   exportable encryption and some may even support null encryption or
+   MAC algorithms, this attack is of particular concern.
+
+   For this attack, an attacker must actively change one or more
+   handshake messages. If this occurs, the client and server will
+   compute different values for the handshake message hashes. As a
+   result, the parties will not accept each others' finished messages.
+   Without the master_secret, the attacker cannot repair the finished
+   messages, so the attack will be discovered.
+
+F.1.4. Resuming sessions
+
+   When a connection is established by resuming a session, new
+   ClientHello.random and ServerHello.random values are hashed with the
+   session's master_secret. Provided that the master_secret has not been
+   compromised and that the secure hash operations used to produce the
+   encryption keys and MAC secrets are secure, the connection should be
+   secure and effectively independent from previous connections.
+   Attackers cannot use known encryption keys or MAC secrets to
+   compromise the master_secret without breaking the secure hash
+   operations (which use both SHA and MD5).
+
+   Sessions cannot be resumed unless both the client and server agree.
+   If either party suspects that the session may have been compromised,
+   or that certificates may have expired or been revoked, it should
+   force a full handshake. An upper limit of 24 hours is suggested for
+   session ID lifetimes, since an attacker who obtains a master_secret
+   may be able to impersonate the compromised party until the
+   corresponding session ID is retired. Applications that may be run in
+   relatively insecure environments should not write session IDs to
+   stable storage.
+
+F.1.5. MD5 and SHA
+
+   TLS uses hash functions very conservatively. Where possible, both MD5
+   and SHA are used in tandem to ensure that non-catastrophic flaws in
+   one algorithm will not break the overall protocol.
+
+F.2. Protecting application data
+
+   The master_secret is hashed with the ClientHello.random and
+   ServerHello.random to produce unique data encryption keys and MAC
+   secrets for each connection.
+
+
+
+Dierks & Allen              Standards Track                    [Page 72]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Outgoing data is protected with a MAC before transmission. To prevent
+   message replay or modification attacks, the MAC is computed from the
+   MAC secret, the sequence number, the message length, the message
+   contents, and two fixed character strings. The message type field is
+   necessary to ensure that messages intended for one TLS Record Layer
+   client are not redirected to another. The sequence number ensures
+   that attempts to delete or reorder messages will be detected. Since
+   sequence numbers are 64-bits long, they should never overflow.
+   Messages from one party cannot be inserted into the other's output,
+   since they use independent MAC secrets. Similarly, the server-write
+   and client-write keys are independent so stream cipher keys are used
+   only once.
+
+   If an attacker does break an encryption key, all messages encrypted
+   with it can be read. Similarly, compromise of a MAC key can make
+   message modification attacks possible. Because MACs are also
+   encrypted, message-alteration attacks generally require breaking the
+   encryption algorithm as well as the MAC.
+
+ Note: MAC secrets may be larger than encryption keys, so messages can
+       remain tamper resistant even if encryption keys are broken.
+
+F.3. Final notes
+
+   For TLS to be able to provide a secure connection, both the client
+   and server systems, keys, and applications must be secure. In
+   addition, the implementation must be free of security errors.
+
+   The system is only as strong as the weakest key exchange and
+   authentication algorithm supported, and only trustworthy
+   cryptographic functions should be used. Short public keys, 40-bit
+   bulk encryption keys, and anonymous servers should be used with great
+   caution. Implementations and users must be careful when deciding
+   which certificates and certificate authorities are acceptable; a
+   dishonest certificate authority can do tremendous damage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 73]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+G. Patent Statement
+
+   Some of the cryptographic algorithms proposed for use in this
+   protocol have patent claims on them. In addition Netscape
+   Communications Corporation has a patent claim on the Secure Sockets
+   Layer (SSL) work that this standard is based on. The Internet
+   Standards Process as defined in RFC 2026 requests that a statement be
+   obtained from a Patent holder indicating that a license will be made
+   available to applicants under reasonable terms and conditions.
+
+   The Massachusetts Institute of Technology has granted RSA Data
+   Security, Inc., exclusive sub-licensing rights to the following
+   patent issued in the United States:
+
+       Cryptographic Communications System and Method ("RSA"), No.
+       4,405,829
+
+   Netscape Communications Corporation has been issued the following
+   patent in the United States:
+
+       Secure Socket Layer Application Program Apparatus And Method
+       ("SSL"), No. 5,657,390
+
+   Netscape Communications has issued the following statement:
+
+       Intellectual Property Rights
+
+       Secure Sockets Layer
+
+       The United States Patent and Trademark Office ("the PTO")
+       recently issued U.S. Patent No. 5,657,390 ("the SSL Patent")  to
+       Netscape for inventions described as Secure Sockets Layers
+       ("SSL"). The IETF is currently considering adopting SSL as a
+       transport protocol with security features.  Netscape encourages
+       the royalty-free adoption and use of the SSL protocol upon the
+       following terms and conditions:
+
+         * If you already have a valid SSL Ref license today which
+           includes source code from Netscape, an additional patent
+           license under the SSL patent is not required.
+
+         * If you don't have an SSL Ref license, you may have a royalty
+           free license to build implementations covered by the SSL
+           Patent Claims or the IETF TLS specification provided that you
+           do not to assert any patent rights against Netscape or other
+           companies for the implementation of SSL or the IETF TLS
+           recommendation.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 74]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       What are "Patent Claims":
+
+       Patent claims are claims in an issued foreign or domestic patent
+       that:
+
+        1) must be infringed in order to implement methods or build
+           products according to the IETF TLS specification;  or
+
+        2) patent claims which require the elements of the SSL patent
+           claims and/or their equivalents to be infringed.
+
+   The Internet Society, Internet Architecture Board, Internet
+   Engineering Steering Group and the Corporation for National Research
+   Initiatives take no position on the validity or scope of the patents
+   and patent applications, nor on the appropriateness of the terms of
+   the assurance. The Internet Society and other groups mentioned above
+   have not made any determination as to any other intellectual property
+   rights which may apply to the practice of this standard.  Any further
+   consideration of these matters is the user's own responsibility.
+
+Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+References
+
+   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
+            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
+
+   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
+            Protocols Based on RSA Encryption Standard PKCS #1" in
+            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
+            1--12, 1998.
+
+   [DES]    ANSI X3.106, "American National Standard for Information
+            Systems-Data Link Encryption," American National Standards
+            Institute, 1983.
+
+   [DH1]    W. Diffie and M. E. Hellman, "New Directions in
+            Cryptography," IEEE Transactions on Information Theory, V.
+            IT-22, n. 6, Jun 1977, pp. 74-84.
+
+   [DSS]    NIST FIPS PUB 186, "Digital Signature Standard," National
+            Institute of Standards and Technology, U.S. Department of
+            Commerce, May 18, 1994.
+
+   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
+            RFC 959, October 1985.
+
+
+
+Dierks & Allen              Standards Track                    [Page 75]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
+            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
+            Hashing for Message Authentication," RFC 2104, February
+            1997.
+
+   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
+            Series in Information Processing, v. 1, Konstanz: Hartung-
+            Gorre Verlag, 1992.
+
+   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
+            April 1992.
+
+   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
+            April 1992.
+
+   [PKCS1]  RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
+            version 1.5, November 1993.
+
+   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
+            Standard," version 1.5, November 1993.
+
+   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
+            Standard," version 1.5, November 1993.
+
+   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+            Public Key Infrastructure: Part I: X.509 Certificate and CRL
+            Profile", RFC 2459, January 1999.
+
+   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
+            Algorithm", RFC 2268, January 1998.
+
+   [RC4]    Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
+            Algorithm, Work in Progress.
+
+   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
+            Obtaining Digital Signatures and Public-Key Cryptosystems,"
+            Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
+            126.
+
+   [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782
+
+   [SCH]    B. Schneier. Applied Cryptography: Protocols, Algorithms,
+            and Source Code in C, Published by John Wiley & Sons, Inc.
+            1994.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 76]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   [SHA]    NIST FIPS PUB 180-1, "Secure Hash Standard," National
+            Institute of Standards and Technology, U.S. Department of
+            Commerce, Work in Progress, May 31, 1994.
+
+   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
+            Corp., Feb 9, 1995.
+
+   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
+            Netscape Communications Corp., Nov 18, 1996.
+
+   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
+            September 1981.
+
+   [TEL]    Postel J., and J. Reynolds, "Telnet Protocol
+            Specifications", STD 8, RFC 854, May 1993.
+
+   [TEL]    Postel J., and J. Reynolds, "Telnet Option Specifications",
+            STD 8, RFC 855, May 1993.
+
+   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication
+            Framework". 1988.
+
+   [XDR]    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
+            Data Representation Standard, August 1995.
+
+Credits
+
+   Win Treese
+   Open Market
+
+   EMail: treese@openmarket.com
+
+
+   Editors
+
+   Christopher Allen                  Tim Dierks
+   Certicom                           Certicom
+
+   EMail: callen@certicom.com         EMail: tdierks@certicom.com
+
+
+   Authors' Addresses
+
+   Tim Dierks                         Philip L. Karlton
+   Certicom                           Netscape Communications
+
+   EMail: tdierks@certicom.com
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 77]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Alan O. Freier                     Paul C. Kocher
+   Netscape Communications            Independent Consultant
+
+   EMail: freier@netscape.com         EMail: pck@netcom.com
+
+
+   Other contributors
+
+   Martin Abadi                       Robert Relyea
+   Digital Equipment Corporation      Netscape Communications
+
+   EMail: ma@pa.dec.com               EMail: relyea@netscape.com
+
+   Ran Canetti                        Jim Roskind
+   IBM Watson Research Center         Netscape Communications
+
+   EMail: canetti@watson.ibm.com      EMail: jar@netscape.com
+
+
+   Taher Elgamal                      Micheal J. Sabin, Ph. D.
+   Securify                           Consulting Engineer
+
+   EMail: elgamal@securify.com        EMail: msabin@netcom.com
+
+
+   Anil R. Gangolli                   Dan Simon
+   Structured Arts Computing Corp.    Microsoft
+
+   EMail: gangolli@structuredarts.com EMail:  dansimon@microsoft.com
+
+
+   Kipp E.B. Hickman                  Tom Weinstein
+   Netscape Communications            Netscape Communications
+
+   EMail: kipp@netscape.com           EMail: tomw@netscape.com
+
+
+   Hugo Krawczyk
+   IBM Watson Research Center
+
+   EMail: hugo@watson.ibm.com
+
+Comments
+
+   The discussion list for the IETF TLS working group is located at the
+   e-mail address <ietf-tls@lists.consensus.com>. Information on the
+   group and information on how to subscribe to the list is at
+   <http://lists.consensus.com/>.
+
+
+
+Dierks & Allen              Standards Track                    [Page 78]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Archives of the list can be found at:
+       <http://www.imc.org/ietf-tls/mail-archive/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 79]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 80]
+
diff --git a/standards/rfc2487.txt b/standards/rfc2487.txt
new file mode 100644
index 000000000..fb1305f00
--- /dev/null
+++ b/standards/rfc2487.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                     P. Hoffman
+Request for Comments: 2487                  Internet Mail Consortium
+Category: Standards Track                               January 1999
+
+
+            SMTP Service Extension for Secure SMTP over TLS
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1. Abstract
+
+   This document describes an extension to the SMTP service that allows
+   an SMTP server and client to use transport-layer security to provide
+   private, authenticated communication over the Internet. This gives
+   SMTP agents the ability to protect some or all of their
+   communications from eavesdroppers and attackers.
+
+2. Introduction
+
+   SMTP [RFC-821] servers and clients normally communicate in the clear
+   over the Internet. In many cases, this communication goes through one
+   or more router that is not controlled or trusted by either entity.
+   Such an untrusted router might allow a third party to monitor or
+   alter the communications between the server and client.
+
+   Further, there is often a desire for two SMTP agents to be able to
+   authenticate each others' identities. For example, a secure SMTP
+   server might only allow communications from other SMTP agents it
+   knows, or it might act differently for messages received from an
+   agent it knows than from one it doesn't know.
+
+   TLS [TLS], more commonly known as SSL, is a popular mechanism for
+   enhancing TCP communications with privacy and authentication. TLS is
+   in wide use with the HTTP protocol, and is also being used for adding
+   security to many other common protocols that run over TCP.
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 1]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+2.1 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+3. STARTTLS Extension
+
+   The STARTTLS extension to SMTP is laid out as follows:
+
+   (1) the name of the SMTP service defined here is STARTTLS;
+
+   (2) the EHLO keyword value associated with the extension is STARTTLS;
+
+   (3) the STARTTLS keyword has no parameters;
+
+   (4) a new SMTP verb, "STARTTLS", is defined;
+
+   (5) no additional parameters are added to any SMTP command.
+
+4. The STARTTLS Keyword
+
+   The STARTTLS keyword is used to tell the SMTP client that the SMTP
+   server allows use of TLS. It takes no parameters.
+
+5. The STARTTLS Command
+
+   The format for the STARTTLS command is:
+
+   STARTTLS
+
+   with no parameters.
+
+   After the client gives the STARTTLS command, the server responds with
+   one of the following reply codes:
+
+   220 Ready to start TLS
+   501 Syntax error (no parameters allowed)
+   454 TLS not available due to temporary reason
+
+   A publicly-referenced SMTP server MUST NOT require use of the
+   STARTTLS extension in order to deliver mail locally. This rule
+   prevents the STARTTLS extension from damaging the interoperability of
+   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
+   is an SMTP server which runs on port 25 of an Internet host listed in
+   the MX record (or A record if an MX record is not present) for the
+   domain name on the right hand side of an Internet mail address.
+
+
+
+
+Hoffman                     Standards Track                     [Page 2]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+   Any SMTP server may refuse to accept messages for relay based on
+   authentication supplied during the TLS negotiation. An SMTP server
+   that is not publicly referenced may refuse to accept any messages for
+   relay or local delivery based on authentication supplied during the
+   TLS negotiation.
+
+   A SMTP server that is not publicly referenced may choose to require
+   that the client perform a TLS negotiation before accepting any
+   commands. In this case, the server SHOULD return the reply code:
+
+   530 Must issue a STARTTLS command first
+
+   to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
+   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
+   [RFC-2034], the status code to be returned SHOULD be 5.7.0.
+
+   After receiving a 220 response to a STARTTLS command, the client
+   SHOULD start the TLS negotiation before giving any other SMTP
+   commands.
+
+   If the SMTP client is using pipelining as defined in RFC 1854, the
+   STARTTLS command must be the last command in a group.
+
+5.1 Processing After the STARTTLS Command
+
+   After the TLS handshake has been completed, both parties MUST
+   immediately decide whether or not to continue based on the
+   authentication and privacy achieved. The SMTP client and server may
+   decide to move ahead even if the TLS negotiation ended with no
+   authentication and/or no privacy because most SMTP services are
+   performed with no authentication and no privacy, but some SMTP
+   clients or servers may want to continue only if a particular level of
+   authentication and/or privacy was achieved.
+
+   If the SMTP client decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD issue an
+   SMTP QUIT command immediately after the TLS negotiation is complete.
+   If the SMTP server decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD reply to
+   every SMTP command from the client (other than a QUIT command) with
+   the 554 reply code (with a possible text string such as "Command
+   refused due to lack of security").
+
+   The decision of whether or not to believe the authenticity of the
+   other party in a TLS negotiation is a local matter. However, some
+   general rules for the decisions are:
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 3]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+    - A SMTP client would probably only want to authenticate an SMTP
+      server whose server certificate has a domain name that is the
+      domain name that the client thought it was connecting to.
+    - A publicly-referenced  SMTP server would probably want to accept
+      any certificate from an SMTP client, and would possibly want to
+      put distinguishing information about the certificate in the
+      Received header of messages that were relayed or submitted from
+      the client.
+
+5.2 Result of the STARTTLS Command
+
+   Upon completion of the TLS handshake, the SMTP protocol is reset to
+   the initial state (the state in SMTP after a server issues a 220
+   service ready greeting). The server MUST discard any knowledge
+   obtained from the client, such as the argument to the EHLO command,
+   which was not obtained from the TLS negotiation itself. The client
+   MUST discard any knowledge obtained from the server, such as the list
+   of SMTP service extensions, which was not obtained from the TLS
+   negotiation itself. The client SHOULD send an EHLO command as the
+   first command after a successful TLS negotiation.
+
+   The list of SMTP service extensions returned in response to an EHLO
+   command received after the TLS handshake MAY be different than the
+   list returned before the TLS handshake. For example, an SMTP server
+   might not want to advertise support for a particular SASL mechanism
+   [SASL] unless a client has sent an appropriate client certificate
+   during a TLS handshake.
+
+   Both the client and the server MUST know if there is a TLS session
+   active.  A client MUST NOT attempt to start a TLS session if a TLS
+   session is already active. A server MUST NOT return the TLS extension
+   in response to an EHLO command received after a TLS handshake has
+   completed.
+
+6. Usage Example
+
+   The following dialog illustrates how a client and server can start a
+   TLS session:
+
+   S: <waits for connection on TCP port 25>
+   C: <opens connection>
+   S: 220 mail.imc.org SMTP service ready
+   C: EHLO mail.ietf.org
+   S: 250-mail.imc.org offers a warm hug of welcome
+   S: 250 STARTTLS
+   C: STARTTLS
+   S: 220 Go ahead
+   C: <starts TLS negotiation>
+
+
+
+Hoffman                     Standards Track                     [Page 4]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+   C & S: <negotiate a TLS session>
+   C & S: <check result of negotiation>
+   C: <continues by sending an SMTP command>
+   . . .
+
+7. Security Considerations
+
+   It should be noted that SMTP is not an end-to-end mechanism. Thus, if
+   an SMTP client/server pair decide to add TLS privacy, they are not
+   securing the transport from the originating mail user agent to the
+   recipient.  Further, because delivery of a single piece of mail may
+   go between more than two SMTP servers, adding TLS privacy to one pair
+   of servers does not mean that the entire SMTP chain has been made
+   private. Further, just because an SMTP server can authenticate an
+   SMTP client, it does not mean that the mail from the SMTP client was
+   authenticated by the SMTP client when the client received it.
+
+   Both the STMP client and server must check the result of the TLS
+   negotiation to see whether acceptable authentication or privacy was
+   achieved. Ignoring this step completely invalidates using TLS for
+   security.  The decision about whether acceptable authentication or
+   privacy was achieved is made locally, is implementation-dependant,
+   and is beyond the scope of this document.
+
+   The SMTP client and server should note carefully the result of the
+   TLS negotiation. If the negotiation results in no privacy, or if it
+   results in privacy using algorithms or key lengths that are deemed
+   not strong enough, or if the authentication is not good enough for
+   either party, the client may choose to end the SMTP session with an
+   immediate QUIT command, or the server may choose to not accept any
+   more SMTP commands.
+
+   A server announcing in an EHLO response that it uses a particular TLS
+   protocol should not pose any security issues, since any use of TLS
+   will be at least as secure as no use of TLS.
+
+   A man-in-the-middle attack can be launched by deleting the "250
+   STARTTLS" response from the server. This would cause the client not
+   to try to start a TLS session. An SMTP client can protect against
+   this attack by recording the fact that a particular SMTP server
+   offers TLS during one session and generating an alarm if it does not
+   appear in the EHLO response for a later session. The lack of TLS
+   during a session SHOULD NOT result in the bouncing of email, although
+   it could result in delayed processing.
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 5]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+   Before the TLS handshake has begun, any protocol interactions are
+   performed in the clear and may be modified by an active attacker. For
+   this reason, clients and servers MUST discard any knowledge obtained
+   prior to the start of the TLS handshake upon completion of the TLS
+   handshake.
+
+   The STARTTLS extension is not suitable for authenticating the author
+   of an email message unless every hop in the delivery chain, including
+   the submission to the first SMTP server, is authenticated. Another
+   proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
+   security multiparts [MIME-SEC] can be used to authenticate the author
+   of an email message. In addition, the [SMTP-AUTH] proposal offers
+   simpler and more flexible options to authenticate an SMTP client and
+   the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
+   the STARTTLS command to provide an authorization identity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 6]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+A. References
+
+   [RFC-821]   Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+               August 1982.
+
+   [RFC-1869]  Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+               November 1995.
+
+   [RFC-2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
+               Error Codes", RFC 2034, October 1996.
+
+   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in
+               Progress.
+
+   [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+               RFC 2246, January 1999.
+
+B. Author's Address
+
+   Paul Hoffman
+   Internet Mail Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+
+   Phone: (831) 426-9827
+   EMail: phoffman@imc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 7]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+C.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 8]
+
diff --git a/standards/rfc2554.txt b/standards/rfc2554.txt
new file mode 100644
index 000000000..2922deaee
--- /dev/null
+++ b/standards/rfc2554.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2554                       Netscape Communications
+Category: Standards Track                                     March 1999
+
+
+                         SMTP Service Extension
+                           for Authentication
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+
+1. Introduction
+
+   This document defines an SMTP service extension [ESMTP] whereby an
+   SMTP client may indicate an authentication mechanism to the server,
+   perform an authentication protocol exchange, and optionally negotiate
+   a security layer for subsequent protocol interactions.  This
+   extension is a profile of the Simple Authentication and Security
+   Layer [SASL].
+
+
+2. Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+
+3. The Authentication service extension
+
+
+   (1) the name of the SMTP service extension is "Authentication"
+
+   (2) the EHLO keyword value associated with this extension is "AUTH"
+
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   (3) The AUTH EHLO keyword contains as a parameter a space separated
+       list of the names of supported SASL mechanisms.
+
+   (4) a new SMTP verb "AUTH" is defined
+
+   (5) an optional parameter using the keyword "AUTH" is added to the
+       MAIL FROM command, and extends the maximum line length of the
+       MAIL FROM command by 500 characters.
+
+   (6) this extension is appropriate for the submission protocol
+       [SUBMIT].
+
+
+4. The AUTH command
+
+   AUTH mechanism [initial-response]
+
+     Arguments:
+         a string identifying a SASL authentication mechanism.
+         an optional base64-encoded response
+
+     Restrictions:
+         After an AUTH command has successfully completed, no more AUTH
+         commands may be issued in the same session.  After a successful
+         AUTH command completes, a server MUST reject any further AUTH
+         commands with a 503 reply.
+
+         The AUTH command is not permitted during a mail transaction.
+
+     Discussion:
+         The AUTH command indicates an authentication mechanism to the
+         server.  If the server supports the requested authentication
+         mechanism, it performs an authentication protocol exchange to
+         authenticate and identify the user.  Optionally, it also
+         negotiates a security layer for subsequent protocol
+         interactions.  If the requested authentication mechanism is not
+         supported, the server rejects the AUTH command with a 504
+         reply.
+
+         The authentication protocol exchange consists of a series of
+         server challenges and client answers that are specific to the
+         authentication mechanism.  A server challenge, otherwise known
+         as a ready response, is a 334 reply with the text part
+         containing a BASE64 encoded string.  The client answer consists
+         of a line containing a BASE64 encoded string.  If the client
+         wishes to cancel an authentication exchange, it issues a line
+         with a single "*".  If the server receives such an answer, it
+         MUST reject the AUTH command by sending a 501 reply.
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+         The optional initial-response argument to the AUTH command is
+         used to save a round trip when using authentication mechanisms
+         that are defined to send no data in the initial challenge.
+         When the initial-response argument is used with such a
+         mechanism, the initial empty challenge is not sent to the
+         client and the server uses the data in the initial-response
+         argument as if it were sent in response to the empty challenge.
+         Unlike a zero-length client answer to a 334 reply, a zero-
+         length initial response is sent as a single equals sign ("=").
+         If the client uses an initial-response argument to the AUTH
+         command with a mechanism that sends data in the initial
+         challenge, the server rejects the AUTH command with a 535
+         reply.
+
+         If the server cannot BASE64 decode the argument, it rejects the
+         AUTH command with a 501 reply.  If the server rejects the
+         authentication data, it SHOULD reject the AUTH command with a
+         535 reply unless a more specific error code, such as one listed
+         in section 6, is appropriate.  Should the client successfully
+         complete the authentication exchange, the SMTP server issues a
+         235 reply.
+
+         The service name specified by this protocol's profile of SASL
+         is "smtp".
+
+         If a security layer is negotiated through the SASL
+         authentication exchange, it takes effect immediately following
+         the CRLF that concludes the authentication exchange for the
+         client, and the CRLF of the success reply for the server.  Upon
+         a security layer's taking effect, the SMTP protocol is reset to
+         the initial state (the state in SMTP after a server issues a
+         220 service ready greeting).  The server MUST discard any
+         knowledge obtained from the client, such as the argument to the
+         EHLO command, which was not obtained from the SASL negotiation
+         itself.  The client MUST discard any knowledge obtained from
+         the server, such as the list of SMTP service extensions, which
+         was not obtained from the SASL negotiation itself (with the
+         exception that a client MAY compare the list of advertised SASL
+         mechanisms before and after authentication in order to detect
+         an active down-negotiation attack).  The client SHOULD send an
+         EHLO command as the first command after a successful SASL
+         negotiation which results in the enabling of a security layer.
+
+         The server is not required to support any particular
+         authentication mechanism, nor are authentication mechanisms
+         required to support any security layers.  If an AUTH command
+         fails, the client may try another authentication mechanism by
+         issuing another AUTH command.
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+         If an AUTH command fails, the server MUST behave the same as if
+         the client had not issued the AUTH command.
+
+         The BASE64 string may in general be arbitrarily long.  Clients
+         and servers MUST be able to support challenges and responses
+         that are as long as are generated by the authentication
+         mechanisms they support, independent of any line length
+         limitations the client or server may have in other parts of its
+         protocol implementation.
+
+     Examples:
+         S: 220 smtp.example.com ESMTP server ready
+         C: EHLO jgm.example.com
+         S: 250-smtp.example.com
+         S: 250 AUTH CRAM-MD5 DIGEST-MD5
+         C: AUTH FOOBAR
+         S: 504 Unrecognized authentication type.
+         C: AUTH CRAM-MD5
+         S: 334
+         PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
+         C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
+         S: 235 Authentication successful.
+
+
+
+5. The AUTH parameter to the MAIL FROM command
+
+   AUTH=addr-spec
+
+   Arguments:
+       An addr-spec containing the identity which submitted the message
+       to the delivery system, or the two character sequence "<>"
+       indicating such an identity is unknown or insufficiently
+       authenticated.  To comply with the restrictions imposed on ESMTP
+       parameters, the addr-spec is encoded inside an xtext.  The syntax
+       of an xtext is described in section 5 of [ESMTP-DSN].
+
+   Discussion:
+       The optional AUTH parameter to the MAIL FROM command allows
+       cooperating agents in a trusted environment to communicate the
+       authentication of individual messages.
+
+       If the server trusts the authenticated identity of the client to
+       assert that the message was originally submitted by the supplied
+       addr-spec, then the server SHOULD supply the same addr-spec in an
+       AUTH parameter when relaying the message to any server which
+       supports the AUTH extension.
+
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+       A MAIL FROM parameter of AUTH=<> indicates that the original
+       submitter of the message is not known.  The server MUST NOT treat
+       the message as having been originally submitted by the client.
+
+       If the AUTH parameter to the MAIL FROM is not supplied, the
+       client has authenticated, and the server believes the message is
+       an original submission by the client, the server MAY supply the
+       client's identity in the addr-spec in an AUTH parameter when
+       relaying the message to any server which supports the AUTH
+       extension.
+
+       If the server does not sufficiently trust the authenticated
+       identity of the client, or if the client is not authenticated,
+       then the server MUST behave as if the AUTH=<> parameter was
+       supplied.  The server MAY, however, write the value of the AUTH
+       parameter to a log file.
+
+       If an AUTH=<> parameter was supplied, either explicitly or due to
+       the requirement in the previous paragraph, then the server MUST
+       supply the AUTH=<> parameter when relaying the message to any
+       server which it has authenticated to using the AUTH extension.
+
+       A server MAY treat expansion of a mailing list as a new
+       submission, setting the AUTH parameter to the mailing list
+       address or mailing list administration address when relaying the
+       message to list subscribers.
+
+       It is conforming for an implementation to be hard-coded to treat
+       all clients as being insufficiently trusted.  In that case, the
+       implementation does nothing more than parse and discard
+       syntactically valid AUTH parameters to the MAIL FROM command and
+       supply AUTH=<> parameters to any servers to which it
+       authenticates using the AUTH extension.
+
+   Examples:
+       C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
+       S: 250 OK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+6. Error Codes
+
+   The following error codes may be used to indicate various conditions
+   as described.
+
+   432 A password transition is needed
+
+   This response to the AUTH command indicates that the user needs to
+   transition to the selected authentication mechanism.  This typically
+   done by authenticating once using the PLAIN authentication mechanism.
+
+   534 Authentication mechanism is too weak
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism is weaker than server policy permits for
+   that user.
+
+   538 Encryption required for requested authentication mechanism
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism may only be used when the underlying SMTP
+   connection is encrypted.
+
+   454 Temporary authentication failure
+
+   This response to the AUTH command indicates that the authentication
+   failed due to a temporary server failure.
+
+   530 Authentication required
+
+   This response may be returned by any command other than AUTH, EHLO,
+   HELO, NOOP, RSET, or QUIT.  It indicates that server policy requires
+   authentication in order to perform the requested action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 6]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+7. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [ABNF].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   UPALPHA         = %x41-5A            ;; Uppercase: A-Z
+
+   LOALPHA         = %x61-7A            ;; Lowercase: a-z
+
+   ALPHA           = UPALPHA / LOALPHA  ;; case insensitive
+
+   DIGIT           = %x30-39            ;; Digits 0-9
+
+   HEXDIGIT        = %x41-46 / DIGIT    ;; hexidecimal digit (uppercase)
+
+   hexchar         = "+" HEXDIGIT HEXDIGIT
+
+   xchar           = %x21-2A / %x2C-3C / %x3E-7E
+                     ;; US-ASCII except for "+", "=", SPACE and CTL
+
+   xtext           = *(xchar / hexchar)
+
+   AUTH_CHAR       = ALPHA / DIGIT / "-" / "_"
+
+   auth_type       = 1*20AUTH_CHAR
+
+   auth_command    = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
+                     *(CRLF [base64]) CRLF
+
+   auth_param      = "AUTH=" xtext
+                       ;; The decoded form of the xtext MUST be either
+                       ;; an addr-spec or the two characters "<>"
+
+   base64          = base64_terminal /
+                     ( 1*(4base64_CHAR) [base64_terminal] )
+
+   base64_char     = UPALPHA / LOALPHA / DIGIT / "+" / "/"
+                     ;; Case-sensitive
+
+   base64_terminal = (2base64_char "==") / (3base64_char "=")
+
+   continue_req    = "334" SPACE [base64] CRLF
+
+
+
+
+Myers                       Standards Track                     [Page 7]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   CR              = %x0C           ;; ASCII CR, carriage return
+
+   CRLF            = CR LF
+
+   CTL             = %x00-1F / %x7F ;; any ASCII control character and DEL
+
+   LF              = %x0A           ;; ASCII LF, line feed
+
+   SPACE           = %x20           ;; ASCII SP, space
+
+
+
+
+8. References
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [CRAM-MD5]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+               AUTHorize Extension for Simple Challenge/Response", RFC
+               2195, September 1997.
+
+   [ESMTP]     Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", RFC 1869, November
+               1995.
+
+   [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
+               Notifications", RFC 1891, January 1996.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SUBMIT]    Gellens, R. and J. Klensin, "Message Submission", RFC
+               2476, December 1998.
+
+   [RFC821]    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, August 1982.
+
+   [RFC822]    Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, August 1982.
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 8]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+9. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+   If a client uses this extension to get an encrypted tunnel through an
+   insecure network to a cooperating server, it needs to be configured
+   to never send mail to that server when the connection is not mutually
+   authenticated and encrypted.  Otherwise, an attacker could steal the
+   client's mail by hijacking the SMTP connection and either pretending
+   the server does not support the Authentication extension or causing
+   all AUTH commands to fail.
+
+   Before the SASL negotiation has begun, any protocol interactions are
+   performed in the clear and may be modified by an active attacker.
+   For this reason, clients and servers MUST discard any knowledge
+   obtained prior to the start of the SASL negotiation upon completion
+   of a SASL negotiation which results in a security layer.
+
+   This mechanism does not protect the TCP port, so an active attacker
+   may redirect a relay connection attempt to the submission port
+   [SUBMIT].  The AUTH=<> parameter prevents such an attack from causing
+   an relayed message without an envelope authentication to pick up the
+   authentication of the relay client.
+
+   A message submission client may require the user to authenticate
+   whenever a suitable SASL mechanism is advertised.  Therefore, it may
+   not be desirable for a submission server [SUBMIT] to advertise a SASL
+   mechanism when use of that mechanism grants the client no benefits
+   over anonymous submission.
+
+   This extension is not intended to replace or be used instead of end-
+   to-end message signature and encryption systems such as S/MIME or
+   PGP.  This extension addresses a different problem than end-to-end
+   systems; it has the following key differences:
+
+      (1) it is generally useful only within a trusted enclave
+
+      (2) it protects the entire envelope of a message, not just the
+          message's body.
+
+      (3) it authenticates the message submission, not authorship of the
+          message content
+
+      (4) it can give the sender some assurance the message was
+          delivered to the next hop in the case where the sender
+          mutually authenticates with the next hop and negotiates an
+          appropriate security layer.
+
+
+
+
+Myers                       Standards Track                     [Page 9]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   Additional security considerations are mentioned in the SASL
+   specification [SASL].
+
+
+
+10. Author's Address
+
+   John Gardiner Myers
+   Netscape Communications
+   501 East Middlefield Road
+   Mail Stop MV-029
+   Mountain View, CA 94043
+
+   EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 10]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 11]
+
diff --git a/standards/rfc2565.txt b/standards/rfc2565.txt
new file mode 100644
index 000000000..56511d478
--- /dev/null
+++ b/standards/rfc2565.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Network Working Group                                    R. Herriot, Ed.
+Request for Comments: 2565                             Xerox Corporation
+Category: Experimental                                         S. Butler
+                                                         Hewlett-Packard
+                                                                P. Moore
+                                                               Microsoft
+                                                               R. Turner
+                                                              Sharp Labs
+                                                              April 1999
+
+
+         Internet Printing Protocol/1.0: Encoding and Transport
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+IESG Note
+
+   This document defines an Experimental protocol for the Internet
+   community.  The IESG expects that a revised version of this protocol
+   will be published as Proposed Standard protocol.  The Proposed
+   Standard, when published, is expected to change from the protocol
+   defined in this memo.  In particular, it is expected that the
+   standards-track version of the protocol will incorporate strong
+   authentication and privacy features, and that an "ipp:" URL type will
+   be defined which supports those security measures.  Other changes to
+   the protocol are also possible.  Implementors are warned that future
+   versions of this protocol may not interoperate with the version of
+   IPP defined in this document, or if they do interoperate, that some
+   protocol features may not be available.
+
+   The IESG encourages experimentation with this protocol, especially in
+   combination with Transport Layer Security (TLS) [RFC 2246], to help
+   determine how TLS may effectively be used as a security layer for
+   IPP.
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 1]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+Abstract
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP). IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies. This document defines the
+   rules for encoding IPP operations and IPP attributes into a new
+   Internet mime media type called "application/ipp".  This document
+   also defines the rules for transporting over HTTP a message body
+   whose Content-Type is "application/ipp".
+
+   The full set of IPP documents includes:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
+      Internet Printing Protocol/1.0: Encoding and Transport (this
+      document)
+      Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
+      Mapping between LPD and IPP Protocols [RFC2569]
+
+   The document, "Design Goals for an Internet Printing Protocol", takes
+   a broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet. It identifies
+   requirements for three types of users: end users, operators, and
+   administrators. It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0. Operator and administrator requirements are
+   out of scope for version 1.0.
+
+   The document, "Rationale for the Structure and Model and Protocol for
+   the Internet Printing Protocol", describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specifications, and gives background and rationale for the
+   IETF working group's major decisions.
+
+   The document, "Internet Printing Protocol/1.0: Model and Semantics",
+   describes a simplified model with abstract objects, their attributes,
+   and their operations that are independent of encoding and transport.
+   It introduces a Printer and a Job object. The Job object optionally
+   supports multiple documents per Job. It also addresses security,
+   internationalization, and directory issues.
+
+   This document "Internet Printing Protocol/1.0: Implementer's Guide",
+   gives advice to implementers of IPP clients and IPP objects.
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 2]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   The document "Mapping between LPD and IPP Protocols" gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+Table of Contents
+
+   1. Introduction.....................................................4
+   2. Conformance Terminology..........................................4
+   3. Encoding of  the Operation Layer.................................4
+      3.1  Picture of the Encoding.....................................5
+      3.2  Syntax of Encoding..........................................7
+      3.3  Version-number..............................................9
+      3.4  Operation-id................................................9
+      3.5  Status-code.................................................9
+      3.6  Request-id..................................................9
+      3.7  Tags.......................................................10
+         3.7.1 Delimiter Tags.........................................10
+         3.7.2 Value Tags.............................................11
+      3.8  Name-Length................................................13
+      3.9  (Attribute) Name...........................................13
+      3.10 Value Length...............................................16
+      3.11 (Attribute) Value..........................................16
+      3.12 Data.......................................................18
+   4. Encoding of Transport Layer.....................................18
+   5. Security Considerations.........................................19
+      5.1  Using IPP with SSL3........................................19
+   6. References......................................................20
+   7. Authors' Addresses..............................................22
+   8. Other Participants:.............................................24
+   9. Appendix A: Protocol Examples...................................25
+      9.1  Print-Job Request..........................................25
+      9.2  Print-Job Response (successful)............................26
+      9.3  Print-Job Response (failure)...............................27
+      9.4  Print-Job Response (success with attributes ignored).......28
+      9.5  Print-URI Request..........................................30
+      9.6  Create-Job Request.........................................31
+      9.7  Get-Jobs Request...........................................31
+      9.8  Get-Jobs Response..........................................32
+   10. Appendix C: Registration of MIME Media Type Information for
+       "application/ipp"..............................................35
+   11. Full Copyright Statement.......................................37
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 3]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+1. Introduction
+
+   This document contains the rules for encoding IPP operations and
+   describes two layers: the transport layer and the operation layer.
+
+   The transport layer consists of an  HTTP/1.1 request or response. RFC
+   2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP
+   headers that an IPP implementation supports.
+
+   The operation layer consists of  a message body in an HTTP request or
+   response.  The document "Internet Printing Protocol/1.0: Model and
+   Semantics" [RFC2566] defines the semantics of such a message body and
+   the supported values. This document specifies the encoding of an IPP
+   operation. The aforementioned document [RFC2566] is henceforth
+   referred to as the "IPP model document"
+
+2. Conformance Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and  "OPTIONAL" in this document are to be
+   interpreted as described in RFC 2119 [RFC2119].
+
+3. Encoding of  the Operation Layer
+
+   The operation layer MUST contain a single operation request or
+   operation response.  Each request or response consists of a sequence
+   of values and attribute groups. Attribute groups consist of a
+   sequence of attributes each of which is a name and value.  Names and
+   values are ultimately sequences of octets
+
+   The encoding consists of octets as the most primitive type. There are
+   several types built from octets, but three important types are
+   integers, character strings and octet strings, on which most other
+   data types are built. Every character string in this encoding MUST be
+   a sequence of characters where the characters are associated with
+   some charset and some natural language. A character string MUST be in
+   "reading order" with the first character in the value (according to
+   reading order) being the first character in the encoding. A character
+   string whose associated charset is US-ASCII whose associated natural
+   language is US English is henceforth called a US-ASCII-STRING. A
+   character string whose associated charset and natural language are
+   specified in a request or response as described in the model document
+   is henceforth called a LOCALIZED-STRING. An octet string MUST be in
+   "IPP model document order" with the first octet in the value
+   (according to the IPP model document order) being the first octet in
+   the encoding Every integer in this encoding MUST be encoded as a
+   signed integer using two's-complement binary encoding with big-endian
+   format (also known as "network order" and "most significant byte
+
+
+
+Herriot, et al.               Experimental                      [Page 4]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   first"). The number of octets for an integer MUST be 1, 2 or 4,
+   depending on usage in the protocol.  Such one-octet integers,
+   henceforth called SIGNED-BYTE, are used for the version-number and
+   tag fields. Such two-byte integers, henceforth called SIGNED-SHORT
+   are used for the operation-id, status-code and length fields. Four
+   byte integers, henceforth called SIGNED-INTEGER, are used for values
+   fields and the sequence number.
+
+   The following two sections present the operation layer in two ways
+
+      - informally through pictures and description
+      - formally through Augmented Backus-Naur Form (ABNF), as specified
+        by RFC 2234 [RFC2234]
+
+3.1 Picture of the Encoding
+
+   The encoding for an operation request or response consists of:
+
+  -----------------------------------------------
+  |                  version-number             |   2 bytes  - required
+  -----------------------------------------------
+  |               operation-id (request)        |
+  |                      or                     |   2 bytes  - required
+  |               status-code (response)        |
+  -----------------------------------------------
+  |                   request-id                |   4 bytes  - required
+  -----------------------------------------------------------
+  |               xxx-attributes-tag            |   1 byte  |
+  -----------------------------------------------           |-0 or more
+  |             xxx-attribute-sequence          |   n bytes |
+  -----------------------------------------------------------
+  |              end-of-attributes-tag          |   1 byte   - required
+  -----------------------------------------------
+  |                     data                    |   q bytes  - optional
+  -----------------------------------------------
+
+   The xxx-attributes-tag and xxx-attribute-sequence represents four
+   different values of "xxx", namely, operation, job, printer and
+   unsupported. The xxx-attributes-tag and an xxx-attribute-sequence
+   represent attribute groups in the model document. The xxx-
+   attributes-tag identifies the attribute group and the xxx-attribute-
+   sequence contains the attributes.
+
+   The expected sequence of  xxx-attributes-tag and xxx-attribute-
+   sequence is specified in the IPP model document for each operation
+   request and operation response.
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 5]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   A request or response SHOULD contain each xxx-attributes-tag defined
+   for that request or response even if there are no attributes except
+   for the unsupported-attributes-tag which SHOULD be present only if
+   the unsupported-attribute-sequence is non-empty. A receiver of a
+   request MUST be able to process as equivalent empty attribute groups:
+
+     a) an xxx-attributes-tag with an empty xxx-attribute-sequence,
+     b) an expected but missing xxx-attributes-tag.
+
+   The data is omitted from some operations, but the end-of-attributes-
+   tag is present even when the data is omitted. Note, the xxx-
+   attributes-tags and end-of-attributes-tag are called 'delimiter-
+   tags'. Note: the xxx-attribute-sequence, shown above may consist of 0
+   bytes, according to the rule below.
+
+   An xxx-attributes-sequence consists of zero or more compound-
+   attributes.
+
+  -----------------------------------------------
+  |              compound-attribute             |   s bytes - 0 or more
+  -----------------------------------------------
+
+   A compound-attribute consists of an attribute with a single value
+   followed by zero or more additional values.
+
+   Note: a 'compound-attribute' represents a single attribute in the
+   model document.  The 'additional value' syntax is for attributes with
+   2 or more values.
+
+   Each attribute consists of:
+
+  -----------------------------------------------
+  |                   value-tag                 |   1 byte
+  -----------------------------------------------
+  |               name-length  (value is u)     |   2 bytes
+  -----------------------------------------------
+  |                     name                    |   u bytes
+  -----------------------------------------------
+  |              value-length  (value is v)     |   2 bytes
+  -----------------------------------------------
+  |                     value                   |   v bytes
+  -----------------------------------------------
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 6]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   An additional value consists of:
+
+  -----------------------------------------------------------
+  |                   value-tag                 |   1 byte  |
+  -----------------------------------------------           |
+  |            name-length  (value is 0x0000)   |   2 bytes |
+  -----------------------------------------------           |-0 or more
+  |              value-length (value is w)      |   2 bytes |
+  -----------------------------------------------           |
+  |                     value                   |   w bytes |
+  -----------------------------------------------------------
+
+   Note: an additional value is like an attribute whose name-length is 0.
+
+   From the standpoint of a parsing loop, the encoding consists of:
+
+  -----------------------------------------------
+  |                  version-number             |   2 bytes  - required
+  -----------------------------------------------
+  |               operation-id (request)        |
+  |                      or                     |   2 bytes  - required
+  |               status-code (response)        |
+  -----------------------------------------------
+  |                   request-id                |   4 bytes  - required
+  -----------------------------------------------------------
+  |        tag (delimiter-tag or value-tag)     |   1 byte  |
+  -----------------------------------------------           |-0 or more
+  |           empty or rest of attribute        |   x bytes |
+  -----------------------------------------------------------
+  |              end-of-attributes-tag          |   2 bytes  - required
+  -----------------------------------------------
+  |                     data                    |   y bytes  - optional
+  -----------------------------------------------
+
+   The value of the tag determines whether the bytes following the
+   tag are:
+
+      - attributes
+      - data
+      - the remainder of a single attribute where the tag specifies the
+        type of the value.
+
+3.2 Syntax of Encoding
+
+   The syntax below is ABNF [RFC2234] except 'strings of literals' MUST
+   be case sensitive. For example 'a' means lower case  'a' and not
+   upper case 'A'.   In addition, SIGNED-BYTE and SIGNED-SHORT fields
+   are represented as '%x' values which show their range of values.
+
+
+
+Herriot, et al.               Experimental                      [Page 7]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+  ipp-message = ipp-request / ipp-response
+  ipp-request = version-number operation-id request-id
+           *(xxx-attributes-tag  xxx-attribute-sequence)
+           end-of-attributes-tag data
+  ipp-response = version-number status-code request-id
+           *(xxx-attributes-tag xxx-attribute-sequence)
+           end-of-attributes-tag data
+  xxx-attribute-sequence = *compound-attribute
+
+  xxx-attributes-tag = operation-attributes-tag / job-attributes-tag /
+        printer-attributes-tag / unsupported-attributes-tag
+
+  version-number = major-version-number minor-version-number
+  major-version-number = SIGNED-BYTE  ; initially %d1
+  minor-version-number = SIGNED-BYTE  ; initially %d0
+
+  operation-id = SIGNED-SHORT    ; mapping from model defined below
+  status-code = SIGNED-SHORT  ; mapping from model defined below
+  request-id = SIGNED-INTEGER ; whose value is > 0
+
+  compound-attribute = attribute *additional-values
+  attribute = value-tag name-length name value-length value
+  additional-values = value-tag zero-name-length value-length value
+
+  name-length = SIGNED-SHORT    ; number of octets of 'name'
+  name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
+  value-length = SIGNED-SHORT  ; number of octets of 'value'
+  value = OCTET-STRING
+
+  data = OCTET-STRING
+
+  zero-name-length = %x00.00           ; name-length of 0
+  operation-attributes-tag =  %x01             ; tag of 1
+  job-attributes-tag   =  %x02                 ; tag of 2
+  printer-attributes-tag =  %x04               ; tag of 4
+  unsupported-attributes-tag =  %x05          ; tag of 5
+  end-of-attributes-tag = %x03                 ; tag of 3
+  value-tag = %x10-FF
+
+  SIGNED-BYTE = BYTE
+  SIGNED-SHORT = 2BYTE
+  SIGNED-INTEGER = 4BYTE
+  DIGIT = %x30-39    ;  "0" to "9"
+  LALPHA = %x61-7A   ;  "a" to "z"
+  BYTE = %x00-FF
+  OCTET-STRING = *BYTE
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 8]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   The syntax allows an xxx-attributes-tag to be present when the xxx-
+   attribute-sequence that follows is empty. The syntax is defined this
+   way to allow for the response of Get-Jobs where no attributes are
+   returned for some job-objects.  Although it is RECOMMENDED that the
+   sender not send an xxx-attributes-tag if there are no attributes
+   (except in the Get-Jobs response just mentioned), the receiver MUST
+   be able to decode such syntax.
+
+3.3 Version-number
+
+   The version-number MUST consist of a major and minor version-number,
+   each of which MUST be represented by a SIGNED-BYTE. The protocol
+   described in this document MUST have a major version-number of 1
+   (0x01) and a minor version-number of  0 (0x00).  The ABNF for these
+   two bytes MUST be %x01.00.
+
+3.4 Operation-id
+
+   Operation-ids are defined as enums in the model document. An
+   operation-ids enum value MUST be encoded as a SIGNED-SHORT.
+
+   Note: the values 0x4000 to 0xFFFF are reserved for private
+   extensions.
+
+3.5 Status-code
+
+   Status-codes are defined as enums in the model document. A status-
+   code enum value MUST be encoded as a SIGNED-SHORT.
+
+   The status-code is an operation attribute in the model document. In
+   the protocol, the status-code is in a special position, outside of
+   the operation attributes.
+
+   If an IPP status-code is returned, then the HTTP Status-Code MUST be
+   200 (successful-ok).  With any other HTTP Status-Code value, the HTTP
+   response MUST NOT contain an IPP message-body, and thus no IPP
+   status-code is returned.
+
+3.6 Request-id
+
+   The request-id allows a client to match a response with a request.
+   This mechanism is unnecessary in HTTP, but may be useful when
+   application/ipp entity bodies are used in another context.
+
+   The request-id in a response MUST be the value of the request-id
+   received in the corresponding request.  A client can set the
+   request-id in each request to a unique value or a constant value,
+   such as 1, depending on what the client does with the request-id
+
+
+
+Herriot, et al.               Experimental                      [Page 9]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   returned in the response. The value of the request-id MUST be greater
+   than zero.
+
+3.7 Tags
+
+   There are two kinds of tags:
+
+      - delimiter tags: delimit major sections of the protocol, namely
+        attributes and data
+      - value tags: specify the type of each attribute value
+
+3.7.1 Delimiter Tags
+
+   The following table specifies the values for the delimiter tags:
+
+      Tag Value (Hex)   Delimiter
+
+      0x00              reserved
+      0x01              operation-attributes-tag
+      0x02              job-attributes-tag
+      0x03              end-of-attributes-tag
+      0x04              printer-attributes-tag
+      0x05              unsupported-attributes-tag
+      0x06-0x0e         reserved for future delimiters
+      0x0F              reserved for future chunking-end-of-attributes-
+                         tag
+
+   When an xxx-attributes-tag occurs in the protocol, it MUST mean that
+   zero or more following attributes up to the next delimiter tag are
+   attributes belonging to group xxx as defined in the model document,
+   where xxx is operation, job, printer, unsupported.
+
+   Doing substitution for xxx in the above paragraph, this means the
+   following. When an operation-attributes-tag occurs in the protocol,
+   it MUST mean that the zero or more following attributes up to the
+   next delimiter tag are operation attributes as defined in the model
+   document.  When an job-attributes-tag occurs in the protocol, it MUST
+   mean that the zero or more following attributes up to the next
+   delimiter tag are job attributes or job template attributes as
+   defined in the model document.  When a printer-attributes-tag occurs
+   in the protocol, it MUST mean that the zero or more following
+   attributes up to the next delimiter tag are printer attributes as
+   defined in the model document. When an unsupported-attributes-tag
+   occurs in the protocol, it MUST mean that the zero or more following
+   attributes up to the next delimiter tag are unsupported attributes as
+   defined in the model document.
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 10]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   The operation-attributes-tag and end-of-attributes-tag MUST each
+   occur exactly once in an operation. The operation-attributes-tag MUST
+   be the first tag delimiter, and the end-of-attributes-tag MUST be the
+   last tag delimiter. If the operation has a document-content group,
+   the document data in that group MUST follow the end-of-attributes-
+   tag.
+
+   Each of the  other three  xxx-attributes-tags defined above is
+   OPTIONAL in an operation and each MUST occur at most once in an
+   operation, except for job-attributes-tag in a Get-Jobs response which
+   may occur zero or more times.
+
+   The order and presence of delimiter tags for each operation request
+   and each operation response MUST be that defined in the model
+   document. For further details, see section 3.9 "(Attribute) Name" and
+   section 9 "Appendix A: Protocol Examples".
+
+   A Printer MUST treat the reserved delimiter tags differently from
+   reserved value tags so that the Printer knows that there is an entire
+   attribute group that it doesn't understand as opposed to a single
+   value that it doesn't understand.
+
+3.7.2 Value Tags
+
+   The remaining tables show values for the value-tag, which is the
+   first octet of  an attribute. The value-tag specifies the type of the
+   value of the attribute. The following table specifies the "out-of-
+   band" values for the value-tag.
+
+      Tag Value (Hex) Meaning
+
+      0x10            unsupported
+      0x11            reserved for future 'default'
+      0x12            unknown
+      0x13            no-value
+
+      Tag Value (Hex) Meaning
+
+      0x14-0x1F       reserved for future "out-of-band" values.
+
+   The "unsupported" value MUST be used in the attribute-sequence of an
+   error response for those attributes which the printer does not
+   support.  The "default" value is reserved for future use of setting
+   value back to their default value. The "unknown" value is used for
+   the value of a supported attribute when its value is temporarily
+   unknown.  The "no-value" value is used for a supported attribute to
+   which
+
+
+
+
+Herriot, et al.               Experimental                     [Page 11]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   no value has been assigned, e.g. "job-k-octets-supported" has no
+   value if an implementation supports this attribute, but an
+   administrator has not configured the printer to have a limit.
+
+   The following table specifies the integer values for the value-tag:
+
+      Tag Value (Hex)  Meaning
+
+      0x20             reserved
+      0x21             integer
+      0x22             boolean
+      0x23             enum
+      0x24-0x2F        reserved for future integer types
+
+   NOTE: 0x20 is reserved for "generic integer" if it should ever be
+   needed.
+
+   The following table specifies the octetString values for the value-
+   tag:
+
+      Tag Value (Hex)  Meaning
+
+      0x30             octetString with an  unspecified format
+      0x31             dateTime
+      0x32             resolution
+      0x33             rangeOfInteger
+      0x34             reserved for collection (in the future)
+      0x35             textWithLanguage
+      0x36             nameWithLanguage
+      0x37-0x3F        reserved for future octetString types
+
+   The following table specifies the character-string values for the
+   value-tag:
+
+      Tag Value (Hex)  Meaning
+
+      0x40             reserved
+      0x41             textWithoutLanguage
+      0x42             nameWithoutLanguage
+      0x43             reserved
+      0x44             keyword
+      0x45             uri
+      0x46             uriScheme
+      0x47             charset
+      0x48             naturalLanguage
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 12]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+      Tag Value (Hex)  Meaning
+
+      0x49             mimeMediaType
+      0x4A-0x5F        reserved for future character string types
+
+   NOTE: 0x40 is reserved for "generic character-string" if it should
+   ever be needed.
+
+   NOTE:  an attribute value always has a type, which is explicitly
+   specified by its tag; one such tag value is "nameWithoutLanguage".
+   An attribute's name has an implicit type, which is keyword.
+
+   The values 0x60-0xFF are reserved for future types. There are no
+   values allocated for private extensions. A new type MUST be
+   registered via the type 2 registration process [RFC2566].
+
+   The tag 0x7F is reserved for extending types beyond the 255 values
+   available with a single byte. A tag value of 0x7F MUST signify that
+   the first 4 bytes of the value field are interpreted as the tag
+   value.  Note, this future extension doesn't affect parsers that  are
+   unaware of this special tag. The tag is like any other unknown tag,
+   and the value length specifies the length of a value which contains a
+   value that the parser treats atomically.  All these 4 byte tag values
+   are currently unallocated except that the values 0x40000000-
+   0x7FFFFFFF are reserved for experimental use.
+
+3.8 Name-Length
+
+   The name-length field MUST consist of a SIGNED-SHORT. This field MUST
+   specify the number of octets in the name field which follows the
+   name-length field, excluding the two bytes of the name-length field.
+
+   If a name-length field has a value of zero, the following name field
+   MUST be empty, and the following value MUST be treated as an
+   additional value for the preceding attribute. Within an attribute-
+   sequence, if two attributes have the same name, the first occurrence
+   MUST be ignored. The zero-length name is the only mechanism for
+   multi-valued attributes.
+
+3.9 (Attribute) Name
+
+   Some operation elements are called parameters in the model document
+   [RFC2566]. They MUST be encoded in a special position and they MUST
+   NOT appear as an operation attributes.  These parameters are:
+
+      - "version-number": The parameter  named "version-number" in the
+        IPP model document MUST become the "version-number" field in the
+        operation layer request or response.
+
+
+
+Herriot, et al.               Experimental                     [Page 13]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+      - "operation-id": The parameter named "operation-id" in the IPP
+        model document MUST become the "operation-id" field in the
+        operation layer request.
+      - "status-code": The parameter named "status-code" in the IPP
+        model document MUST become the "status-code" field in the
+        operation layer response.
+      - "request-id": The parameter named "request-id" in the IPP model
+        document MUST become the "request-id" field in the operation
+        layer request or response.
+
+   All Printer and Job objects are identified by a Uniform Resource
+   Identifier (URI) [RFC2396] so that they can be persistently and
+   unambiguously referenced.  The notion of a URI is a useful concept,
+   however, until the notion of URI is more stable (i.e.,  defined more
+   completely and deployed more widely), it is expected that the URIs
+   used for IPP objects will actually be URLs [RFC1738]  [RFC1808].
+   Since every URL is a specialized form of a URI, even though the more
+   generic term URI is used throughout the rest of this document, its
+   usage is intended to cover the more specific notion of URL as well.
+
+   Some operation elements are encoded twice, once as the request-URI on
+   the HTTP Request-Line and a second time as a REQUIRED operation
+   attribute in the application/ipp entity.  These attributes are the
+   target URI for the operation:
+
+      - "printer-uri": When the target is a printer and the transport is
+        HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined
+        in each operation in the IPP model document MUST be an operation
+        attribute called "printer-uri" and it MUST also be specified
+        outside of  the operation layer as the request-URI on the
+        Request-Line at the HTTP level.
+      - "job-uri": When the target is a job and the transport is HTTP or
+        HTTPS (for SSL3), the target job-uri of each operation in the
+        IPP model document MUST be an operation attribute called "job-
+        uri" and it MUST also be specified outside of  the operation
+        layer as the request-URI on the Request-Line at the HTTP level.
+
+   Note: The target URI is included twice in an operation referencing
+   the same IPP object, but the two URIs NEED NOT be literally
+   identical. One can be a relative URI and the other can be an absolute
+   URI.  HTTP/1.1 allows clients to generate and send a relative URI
+   rather than an absolute URI.  A relative URI identifies a resource
+   with the scope of the HTTP server, but does not include scheme, host
+   or port.  The following statements characterize how URLs should be
+   used in the mapping of IPP onto HTTP/1.1:
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 14]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+      1. Although potentially redundant, a client MUST supply the target
+         of the operation both as an operation attribute and as a URI at
+         the HTTP layer.  The rationale for this decision is to maintain
+         a consistent set of rules for mapping application/ipp to
+         possibly many communication layers, even where URLs are not
+         used as the addressing mechanism in the transport layer.
+      2. Even though these two URLs might not be literally identical
+         (one being relative and the other being absolute), they MUST
+         both reference the same IPP object.
+      3. The URI in the HTTP layer is either relative or absolute and is
+         used by the HTTP server to route the HTTP request to the
+         correct resource relative to that HTTP server.  The HTTP server
+         need not be aware of the URI within the operation request.
+      4. Once the HTTP server resource begins to process the HTTP
+         request, it might get the reference to the appropriate IPP
+         Printer object from either the HTTP URI (using to the context
+         of the HTTP server for relative URLs) or from the URI within
+         the operation request; the choice is up to the implementation.
+      5. HTTP URIs can be relative or absolute, but the target URI in
+         the operation MUST be an absolute URI.
+
+   The model document arranges the remaining attributes into groups for
+   each operation request and response. Each such group MUST be
+   represented in the protocol by an xxx-attribute-sequence preceded by
+   the appropriate xxx-attributes-tag (See the table below and section 9
+   "Appendix A:  Protocol Examples"). In addition, the order of these
+   xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST
+   be the same as in the model document, but the order of attributes
+   within each xxx-attribute-sequence MUST be unspecified. The table
+   below maps the model document group name to xxx-attributes-sequence:
+
+   Model Document Group           xxx-attributes-sequence
+
+   Operation Attributes           operations-attributes-sequence
+   Job Template Attributes        job-attributes-sequence
+   Job Object Attributes          job-attributes-sequence
+   Unsupported Attributes         unsupported-attributes-sequence
+   Requested Attributes           job-attributes-sequence
+   Get-Job-Attributes)
+   Requested Attributes           printer-attributes-sequence
+   Get-Printer-Attributes)
+   Document Content               in a special position as described
+                                  above
+
+   If an operation contains attributes from more than one job object
+   (e.g.  Get-Jobs response), the attributes from each job object MUST
+   be in a separate job-attribute-sequence, such that the attributes
+
+
+
+
+Herriot, et al.               Experimental                     [Page 15]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   from the ith job object are in the ith job-attribute-sequence. See
+   Section 9 "Appendix A: Protocol Examples" for table showing the
+   application of the rules above.
+
+3.10 Value Length
+
+   Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST
+   specify the number of octets in the value which follows this length,
+   exclusive of the two bytes specifying the length.
+
+   For any of the types represented by binary signed integers, the
+   sender MUST encode the value in exactly four octets.
+
+   For any of the types represented by character-strings, the sender
+   MUST encode the value with all the characters of the string and
+   without any padding characters.
+
+   If a value-tag contains an "out-of-band" value, such as
+   "unsupported", the value-length MUST be 0 and the value empty. The
+   value has no meaning when the value-tag has an "out-of-band" value.
+   If a client receives a response with a nonzero value-length in this
+   case, it MUST ignore the value field. If a printer receives a request
+   with a nonzero value-length in this case, it MUST reject the request.
+
+3.11 (Attribute) Value
+
+   The syntax types and most of the details of their representation are
+   defined in the IPP model document. The table below augments the
+   information in the model document, and defines the syntax types from
+   the model document in terms of the 5 basic types defined in section 3
+   "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING,
+   LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and
+   OCTET-STRING.
+
+Syntax of Attribute  Encoding
+Value
+
+textWithoutLanguage, LOCALIZED-STRING.
+nameWithoutLanguage
+
+textWithLanguage     OCTET_STRING consisting of 4 fields:
+                       a) a SIGNED-SHORT which is the number of octets
+                          in the following field
+                       b) a value of type natural-language,
+                       c) a SIGNED-SHORT which is the number of octets
+                          in the following field,
+                       d) a value of type textWithoutLanguage.
+
+
+
+
+Herriot, et al.               Experimental                     [Page 16]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+                      The length of a textWithLanguage value MUST be 4
+                      + the value of field a + the value of field c.
+
+nameWithLanguage     OCTET_STRING consisting of 4 fields:
+                       a) a SIGNED-SHORT which is the number of octets
+                          in the following field
+                       b) a value of type natural-language,
+                       c) a SIGNED-SHORT which is the number of octets
+                          in the following field
+                       d) a value of type nameWithoutLanguage.
+
+                      The length of a nameWithLanguage value MUST be 4
+                      + the value of field a + the value of field c.
+
+charset,             US-ASCII-STRING.
+naturalLanguage,
+mimeMediaType,
+keyword, uri, and
+uriScheme
+
+boolean              SIGNED-BYTE  where 0x00 is 'false' and 0x01 is
+                      'true'.
+
+Syntax of Attribute  Encoding
+Value
+
+
+integer and enum     a SIGNED-INTEGER.
+
+dateTime             OCTET-STRING consisting of eleven octets whose
+                      contents are defined by "DateAndTime" in RFC
+                      2579 [RFC2579].
+
+resolution           OCTET_STRING consisting of nine octets of  2
+                      SIGNED-INTEGERs followed by a SIGNED-BYTE. The
+                      first SIGNED-INTEGER contains the value of cross
+                      feed direction resolution. The second SIGNED-
+                      INTEGER contains the value of feed direction
+                      resolution. The SIGNED-BYTE contains the units
+                      value.
+
+rangeOfInteger       Eight octets consisting of 2 SIGNED-INTEGERs.
+                      The first SIGNED-INTEGER contains the lower
+                      bound and the second SIGNED-INTEGER contains the
+                      upper  bound.
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 17]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+1setOf  X            Encoding according to the rules for an attribute
+                      with more than 1 value.  Each value X is encoded
+                      according to the rules for encoding its type.
+
+octetString          OCTET-STRING
+
+   The type of the value in the model document determines the encoding
+   in the value and the value of the value-tag.
+
+3.12 Data
+
+   The data part MUST include any data required by the operation
+
+4. Encoding of Transport Layer
+
+   HTTP/1.1 [RFC2068] is the transport layer for this protocol.
+
+   The operation layer has been designed with the assumption that the
+   transport layer contains the following information:
+
+      - the URI of the target job or printer operation
+      - the total length of the data in the operation layer, either as a
+        single length or as a sequence of chunks each with a length.
+
+   It is REQUIRED that a printer implementation support HTTP over the
+   IANA assigned Well Known Port 631 (the IPP default port), though a
+   printer implementation may support HTTP over some other port as well.
+   In addition, a printer may have to support another port for privacy
+   (See Section 5 "Security Considerations").
+
+   Note: even though port 631 is the IPP default, port 80 remains the
+   default for an HTTP URI.  Thus a URI for a printer using port 631
+   MUST contain an explicit port, e.g. "http://forest:631/pinetree".  An
+   HTTP URI for IPP with no explicit port implicitly reference port 80,
+   which is consistent with the rules for HTTP/1.1. Each HTTP operation
+   MUST use the POST method where the request-URI is the object target
+   of the operation, and where the "Content-Type" of the message-body in
+   each request and response MUST be "application/ipp". The message-body
+   MUST contain the operation layer and MUST have the syntax described
+   in section 3.2 "Syntax of Encoding". A client implementation MUST
+   adhere to the rules for a client described for HTTP1.1 [RFC2068]. A
+   printer (server) implementation MUST adhere the rules for an origin
+   server described for HTTP1.1 [RFC2068].
+
+   An IPP server sends a response for each request that it receives.  If
+   an IPP server detects an error, it MAY send a response before it has
+   read the entire request.  If the HTTP layer of the IPP server
+   completes processing the HTTP headers successfully, it MAY send an
+
+
+
+Herriot, et al.               Experimental                     [Page 18]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   intermediate response, such as "100 Continue", with no IPP data
+   before sending the IPP response.  A client MUST expect such a variety
+   of responses from an IPP server. For further information on HTTP/1.1,
+   consult the HTTP documents [RFC2068].
+
+5. Security Considerations
+
+   The IPP Model document defines an IPP implementation with "privacy"
+   as one that implements Secure Socket Layer Version 3 (SSL3).  Note:
+   SSL3 is not an IETF standards track specification. SSL3 meets the
+   requirements for IPP security with regards to features such as mutual
+   authentication and privacy (via encryption). The IPP Model document
+   also outlines IPP-specific security considerations and should be the
+   primary reference for security implications with regards to the IPP
+   protocol itself.
+
+   The IPP Model document defines an IPP implementation with
+   "authentication" as one that implements the standard way for
+   transporting IPP messages within HTTP 1.1. These include the security
+   considerations outlined in the HTTP 1.1 standard document [RFC2068]
+   and Digest Access Authentication extension [RFC2069].
+
+   The current HTTP infrastructure supports HTTP over TCP port 80. IPP
+   server implementations MUST offer IPP services using HTTP over the
+   IANA assigned Well Known Port 631 (the IPP default port). IPP server
+   implementations may support other ports, in addition to this port.
+
+   See further discussion of IPP security concepts in the model document
+   [RFC2566].
+
+5.1 Using IPP with SSL3
+
+   An assumption is that the URI for a secure IPP Printer object has
+   been found by means outside the IPP printing protocol, via a
+   directory service, web site or other means.
+
+   IPP provides a transparent connection to SSL by calling the
+   corresponding URL (a https URI connects by default to port 443).
+   However, the following functions can be provided to ease the
+   integration of IPP with SSL during implementation:
+
+      connect (URI), returns a status
+
+         "connect" makes an https call and returns the immediate status
+         of the connection as returned by SSL to the user. The status
+         values are explained in section 5.4.2 of the SSL document
+         [ssl].
+
+
+
+
+Herriot, et al.               Experimental                     [Page 19]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+         A session-id may also be retained to later resume a session.
+         The SSL handshake protocol may also require the cipher
+         specifications supported by the client, key length of the
+         ciphers, compression methods, certificates, etc. These should
+         be sent to the server and hence should be available to the IPP
+         client (although as part of administration features).
+
+      disconnect (session)
+
+         to disconnect a particular session.
+
+         The session-id available from the "connect" could be used.
+
+      resume (session)
+
+         to reconnect using a previous session-id.
+
+   The availability of this information as administration features are
+   left for implementers, and need not be specified at this time.
+
+6. References
+
+   [RFC2278] Freed, N. and J. Postel, "IANA Charset Registration
+             Procedures", BCP 19, RFC 2278, January 1998.
+
+   [dpa]     ISO/IEC 10175 Document Printing Application (DPA), June
+             1996.
+
+   [iana]    IANA Registry of Coded Character Sets:
+             ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
+
+   [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.0:
+             Implementer's Guide", Work in Progress.
+
+   [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+             "Mapping between LPD and IPP Protocols", RFC 2569, April
+             1999.
+
+   [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
+             Powell, "Internet Printing Protocol/1.0: Model and
+             Semantics", RFC 2566, April 1999.
+
+   [RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
+             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+             April 1999.
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 20]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   [RFC2568] Zilles, S., "Rationale for the Structure and Model and
+             Protocol for the Internet Printing Protocol", RFC 2568,
+             April 1999.
+
+   [RFC2567] Wright, D., "Design Goals for an Internet Printing
+             Protocol", RFC 2567, April 1999.
+
+   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text
+             Messages", STD 11, RFC 822, August 1982.
+
+   [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+             and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon
+             Protocol" RFC 1179, August 1990.
+
+   [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
+             RFC 2223, October 1997.
+
+   [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+             Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+             Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+   [RFC1766] Alvestrand, H., " Tags for the Identification of
+             Languages", RFC 1766, March 1995.
+
+   [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
+             1808, June 1995.
+
+   [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
+             Conventions for SMIv2", STD 58, RFC 2579, April 1999.
+
+   [RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail
+             Extensions (MIME) Part Two: Media Types", RFC 2046,
+             November 1996.
+
+   [RFC2048] Freed, N., Klensin J. and J. Postel.  Multipurpose Internet
+             Mail Extension (MIME) Part Four: Registration Procedures",
+             BCP 13, RFC 2048, November 1996.
+
+   [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+             2068, January 1997.
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 21]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+             Luotonen, A., Sink, E. and L. Stewart, "An Extension to
+             HTTP: Digest Access Authentication", RFC 2069, January
+             1997.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
+             Word Extensions: Character Sets, Languages, and
+             Continuations", RFC 2184, August 1997.
+
+   [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+             Specifications: ABNF", RFC 2234. November 1997.
+
+   [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+             Resource Identifiers (URI): Generic Syntax", RFC 2396,
+             August 1998.
+
+7. Authors' Addresses
+
+   Robert Herriot (Editor)
+   Xerox Corporation
+   3400 Hillview Ave., Bldg #1
+   Palo Alto, CA 94304
+
+   Phone: 650-813-7696
+   Fax:  650-813-6860
+   EMail: rherriot@pahv.xerox.com
+
+
+   Sylvan Butler
+   Hewlett-Packard
+   11311 Chinden Blvd.
+   Boise, ID 83714
+
+   Phone: 208-396-6000
+   Fax: 208-396-3457
+   EMail: sbutler@boi.hp.com
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 22]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   Paul Moore
+   Microsoft
+   One Microsoft Way
+   Redmond, WA 98053
+
+   Phone: 425-936-0908
+   Fax: 425-93MS-FAX
+   EMail: paulmo@microsoft.com
+
+
+   Randy Turner
+   Sharp Laboratories
+   5750 NW Pacific Rim Blvd
+   Camas, WA 98607
+
+   Phone: 360-817-8456
+   Fax: 360-817-8436
+   EMail: rturner@sharplabs.com
+
+
+   IPP Mailing List:  ipp@pwg.org
+   IPP Mailing List Subscription:  ipp-request@pwg.org
+   IPP Web Page:  http://www.pwg.org/ipp/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 23]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+8. Other Participants:
+
+   Chuck Adams - Tektronix          Harry Lewis - IBM
+   Ron Bergman - Dataproducts       Tony Liao - Vivid Image
+   Keith Carter - IBM               David Manchala - Xerox
+   Angelo Caruso - Xerox            Carl-Uno Manros - Xerox
+   Jeff Copeland - QMS              Jay Martin - Underscore
+   Roger deBry - IBM                Larry Masinter - Xerox
+   Lee Farrell - Canon              Ira McDonald - High North Inc.
+   Sue Gleeson - Digital            Bob Pentecost - Hewlett-Packard
+   Charles Gordon - Osicom          Patrick Powell - Astart
+                                    Technologies
+   Brian Grimshaw - Apple           Jeff Rackowitz - Intermec
+   Jerry Hadsell - IBM              Xavier Riley - Xerox
+   Richard Hart - Digital           Gary Roberts - Ricoh
+   Tom Hastings - Xerox             Stuart Rowley - Kyocera
+   Stephen Holmstead                Richard Schneider - Epson
+   Zhi-Hong Huang - Zenographics    Shigern Ueda - Canon
+   Scott Isaacson - Novell          Bob Von Andel - Allegro Software
+   Rich Lomicka - Digital           William Wagner - Digital Products
+   David Kellerman - Northlake      Jasper Wong - Xionics
+   Software
+   Robert Kline - TrueSpectra       Don Wright - Lexmark
+   Dave Kuntz - Hewlett-Packard     Rick Yardumian - Xerox
+   Takami Kurono - Brother          Lloyd Young - Lexmark
+   Rich Landau - Digital            Peter Zehler - Xerox
+   Greg LeClair - Epson             Frank Zhao - Panasonic
+                                    Steve Zilles - Adobe
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 24]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+9. Appendix A: Protocol Examples
+
+9.1 Print-Job Request
+
+   The following is an example of a Print-Job request with job-name,
+   copies, and sides specified. The "ipp-attribute-fidelity" attribute
+   is set to 'true' so that the print request will fail if the "copies"
+   or the "sides" attribute are not supported or their values are not
+   supported.
+
+ Octets          Symbolic Value                Protocol field
+
+ 0x0100          1.0                           version-number
+ 0x0002          Print-Job                     operation-id
+ 0x00000001      1                             request-id
+ 0x01            start operation-attributes    operation-attributes-tag
+ 0x47            charset type                  value-tag
+ 0x0012                                        name-length
+ attributes-     attributes-charset            name
+ charset
+ 0x0008                                        value-length
+ us-ascii        US-ASCII                      value
+ 0x48            natural-language type         value-tag
+ 0x001B                                        name-length
+ attributes-     attributes-natural-language   name
+ natural-
+ language
+ 0x0005                                        value-length
+ en-us           en-US                         value
+ 0x45            uri type                      value-tag
+ 0x000B                                        name-length
+ printer-uri     printer-uri                   name
+ 0x001A                                        value-length
+ http://forest:  printer pinetree              value
+ 631/pinetree
+ 0x42            nameWithoutLanguage type      value-tag
+ 0x0008                                        name-length
+ job-name        job-name                      name
+ 0x0006                                        value-length
+ foobar          foobar                        value
+ 0x22            boolean type                  value-tag
+ 0x16                                          name-length
+ ipp-attribute-  ipp-attribute-fidelity        name
+ fidelity
+ 0x01                                          value-length
+ 0x01            true                          value
+ 0x02            start job-attributes          job-attributes-tag
+ 0x21            integer type                  value-tag
+
+
+
+Herriot, et al.               Experimental                     [Page 25]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ 0x0006                                        name-length
+ copies          copies                        name
+ 0x0004                                        value-length
+ 0x00000014      20                            value
+ 0x44            keyword type                  value-tag
+ 0x0005                                        name-length
+ sides           sides                         name
+ 0x0013                                        value-length
+ two-sided-      two-sided-long-edge           value
+ long-edge
+ 0x03            end-of-attributes             end-of-attributes-tag
+ %!PS...         <PostScript>                  data
+
+9.2 Print-Job Response (successful)
+
+   Here is an example of a successful Print-Job response to the previous
+   Print-Job request.  The printer supported the "copies" and "sides"
+   attributes and their supplied values.  The status code returned is '
+   successful-ok'.
+
+ Octets            Symbolic Value              Protocol field
+
+ 0x0100            1.0                         version-number
+ 0x0000            successful-ok               status-code
+ 0x00000001        1                           request-id
+ 0x01              start operation-attributes  operation-attributes-tag
+ 0x47              charset type                value-tag
+ 0x0012                                        name-length
+ attributes-       attributes-charset          name
+ charset
+ 0x0008                                        value-length
+ us-ascii          US-ASCII                    value
+ 0x48              natural-language type       value-tag
+ 0x001B                                        name-length
+ attributes-       attributes-natural-         name
+ natural-language  language
+ 0x0005                                        value-length
+ en-us             en-US                       value
+ 0x41              textWithoutLanguage type    value-tag
+ 0x000E                                        name-length
+ status-message    status-message              name
+ 0x000D                                        value-length
+ successful-ok     successful-ok               value
+ 0x02              start job-attributes        job-attributes-tag
+ 0x21              integer                     value-tag
+ 0x0006                                        name-length
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 26]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ Octets            Symbolic Value              Protocol field
+
+ job-id            job-id                      name
+ 0x0004                                        value-length
+ 147               147                         value
+ 0x45              uri type                    value-tag
+ 0x0007                                        name-length
+ job-uri           job-uri                     name
+ 0x001E                                        value-length
+ http://forest:63  job 123 on pinetree         value
+ 1/pinetree/123
+ 0x42              nameWithoutLanguage type    value-tag
+ 0x0009                                        name-length
+ job-state         job-state                   name
+ 0x0004                                        value-length
+ 0x0003            pending                     value
+ 0x03              end-of-attributes           end-of-attributes-tag
+
+9.3 Print-Job Response (failure)
+
+   Here is an example of an unsuccessful Print-Job response to the
+   previous Print-Job request. It fails because, in this case, the
+   printer does not support the "sides" attribute and because the value
+   '20' for the "copies" attribute is not supported. Therefore, no job
+   is created, and neither a "job-id" nor a "job-uri" operation
+   attribute is returned. The error code returned is 'client-error-
+   attributes-or-values-not-supported' (0x040B).
+
+ Octets        Symbolic Value                Protocol field
+
+ 0x0100        1.0                           version-number
+ 0x040B        client-error-attributes-or-   status-code
+               values-not-supported
+ 0x00000001    1                             request-id
+ 0x01          start operation-attributes    operation-attribute tag
+ 0x47          charset type                  value-tag
+ 0x0012                                      name-length
+ attributes-   attributes-charset            name
+ charset
+ 0x0008                                      value-length
+ us-ascii      US-ASCII                      value
+ 0x48          natural-language type         value-tag
+ 0x001B                                      name-length
+ attributes-   attributes-natural-language   name
+ natural-
+ language
+ 0x0005                                      value-length
+
+
+
+
+Herriot, et al.               Experimental                     [Page 27]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ Octets            Symbolic Value              Protocol field
+
+ en-us         en-US                         value
+ 0x41          textWithoutLanguage type      value-tag
+ 0x000E                                      name-length
+ status-       status-message                name
+ message
+ 0x002F                                      value-length
+ client-error- client-error-attributes-or-   value
+ attributes-   values-not-supported
+ or-values-
+ not-supported
+ 0x05          start unsupported-attributes  unsupported-attributes tag
+ 0x21          integer type                  value-tag
+ 0x0006                                      name-length
+ copies        copies                        name
+ 0x0004                                      value-length
+ 0x00000014    20                            value
+ 0x10          unsupported  (type)           value-tag
+ 0x0005                                      name-length
+ sides         sides                         name
+ 0x0000                                      value-length
+ 0x03          end-of-attributes             end-of-attributes-tag
+
+9.4 Print-Job Response (success with attributes ignored)
+
+   Here is an example of a successful Print-Job response to a Print-Job
+   request like the previous Print-Job request, except that the value of
+   'ipp-attribute-fidelity' is false. The print request succeeds, even
+   though, in this case, the printer supports neither the "sides"
+   attribute nor the value '20' for the "copies" attribute. Therefore, a
+   job is created, and both a "job-id" and a "job-uri" operation
+   attribute are returned. The unsupported attributes are also returned
+   in an Unsupported Attributes Group. The error code returned is '
+   successful-ok-ignored-or-substituted-attributes' (0x0001).
+
+ Octets            Symbolic Value              Protocol field
+
+ 0x0100            1.0                         version-number
+ 0x0001            successful-ok-ignored-or-   status-code
+                   substituted-attributes
+ 0x00000001        1                           request-id
+ 0x01              start operation-attributes  operation-attributes-tag
+ 0x47              charset type                value-tag
+ 0x0012                                        name-length
+ attributes-       attributes-charset          name
+ charset
+ 0x0008                                        value-length
+
+
+
+Herriot, et al.               Experimental                     [Page 28]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ Octets            Symbolic Value              Protocol field
+
+ us-ascii          US-ASCII                    value
+ 0x48              natural-language type       value-tag
+ 0x001B                                        name-length
+ attributes-       attributes-natural-         name
+ natural-language  language
+ 0x0005                                        value-length
+ en-us             en-US                       value
+ 0x41              textWithoutLanguage type    value-tag
+ 0x000E                                        name-length
+ status-message    status-message              name
+ 0x002F                                        value-length
+ successful-ok-    successful-ok-ignored-or-   value
+ ignored-or-       substituted-attributes
+ substituted-
+ attributes
+ 0x05              start unsupported-          unsupported-attributes
+                   attributes                  tag
+ 0x21              integer type                value-tag
+ 0x0006                                        name-length
+ copies            copies                      name
+ 0x0004                                        value-length
+ 0x00000014        20                          value
+ 0x10              unsupported  (type)         value-tag
+ 0x0005                                        name-length
+ sides             sides                       name
+ 0x0000                                        value-length
+ 0x02              start job-attributes        job-attributes-tag
+ 0x21              integer                     value-tag
+ 0x0006                                        name-length
+ job-id            job-id                      name
+ 0x0004                                        value-length
+ 147               147                         value
+ 0x45              uri type                    value-tag
+ 0x0007                                        name-length
+ job-uri           job-uri                     name
+ 0x001E                                        value-length
+ http://forest:63  job 123 on pinetree         value
+ 1/pinetree/123
+ 0x42              nameWithoutLanguage type    value-tag
+ 0x0009                                        name-length
+ job-state         job-state                   name
+ 0x0004                                        value-length
+ 0x0003            pending                     value
+ 0x03              end-of-attributes           end-of-attributes-tag
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 29]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+9.5 Print-URI Request
+
+   The following is an example of Print-URI request with copies and
+   job-name parameters:
+
+ Octets         Symbolic Value               Protocol field
+
+ 0x0100         1.0                          version-number
+
+ Octets         Symbolic Value               Protocol field
+ 0x0003         Print-URI                    operation-id
+ 0x00000001     1                            request-id
+ 0x01           start operation-attributes   operation-attributes-tag
+ 0x47           charset type                 value-tag
+ 0x0012                                      name-length
+ attributes-    attributes-charset           name
+ charset
+ 0x0008                                      value-length
+ us-ascii       US-ASCII                     value
+ 0x48           natural-language type        value-tag
+ 0x001B                                      name-length
+ attributes-    attributes-natural-language  name
+ natural-
+ language
+ 0x0005                                      value-length
+ en-us          en-US                        value
+ 0x45           uri type                     value-tag
+ 0x000B                                      name-length
+ printer-uri    printer-uri                  name
+ 0x001A                                      value-length
+ http://forest  printer pinetree             value
+ :631/pinetree
+ 0x45           uri type                     value-tag
+ 0x000C                                      name-length
+ document-uri   document-uri                 name
+ 0x11                                        value-length
+ ftp://foo.com  ftp://foo.com/foo            value
+ /foo
+ 0x42           nameWithoutLanguage type     value-tag
+ 0x0008                                      name-length
+ job-name       job-name                     name
+ 0x0006                                      value-length
+ foobar         foobar                       value
+ 0x02           start job-attributes         job-attributes-tag
+ 0x21           integer type                 value-tag
+ 0x0006                                      name-length
+ copies         copies                       name
+ 0x0004                                      value-length
+
+
+
+Herriot, et al.               Experimental                     [Page 30]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ 0x00000001     1                            value
+ 0x03           end-of-attributes            end-of-attributes-tag
+
+9.6 Create-Job Request
+
+   The following is an example of Create-Job request with no parameters
+   and no attributes:
+
+ Octets         Symbolic Value              Protocol field
+ 0x0100         1.0                         version-number
+ 0x0005         Create-Job                  operation-id
+ 0x00000001     1                           request-id
+ 0x01           start operation-attributes  operation-attributes-tag
+ 0x47           charset type                value-tag
+ 0x0012                                     name-length
+
+ Octets         Symbolic Value              Protocol field
+ attributes-    attributes-charset          name
+ charset
+ 0x0008                                     value-length
+ us-ascii       US-ASCII                    value
+ 0x48           natural-language type       value-tag
+ 0x001B                                     name-length
+ attributes-    attributes-natural-language name
+ natural-
+ language
+ 0x0005                                     value-length
+ en-us          en-US                       value
+ 0x45           uri type                    value-tag
+ 0x000B                                     name-length
+ printer-uri    printer-uri                 name
+ 0x001A                                     value-length
+ http://forest: printer pinetree            value
+ 631/pinetree
+ 0x03           end-of-attributes           end-of-attributes-tag
+
+9.7 Get-Jobs Request
+
+   The following is an example of Get-Jobs request with parameters but
+   no attributes:
+
+ Octets           Symbolic Value               Protocol field
+
+ 0x0100           1.0                          version-number
+ 0x000A           Get-Jobs                     operation-id
+ 0x00000123       0x123                        request-id
+ 0x01             start operation-attributes   operation-attributes-tag
+ 0x47             charset type                 value-tag
+
+
+
+Herriot, et al.               Experimental                     [Page 31]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ Octets           Symbolic Value               Protocol field
+
+ 0x0012                                        name-length
+ attributes-      attributes-charset           name
+ charset
+ 0x0008                                        value-length
+ us-ascii         US-ASCII                     value
+ 0x48             natural-language type        value-tag
+ 0x001B                                        name-length
+ attributes-      attributes-natural-language  name
+ natural-
+ language
+ 0x0005                                        value-length
+ en-us            en-US                        value
+ 0x45             uri type                     value-tag
+ 0x000B                                        name-length
+ printer-uri      printer-uri                  name
+ 0x001A                                        value-length
+ http://forest:6  printer pinetree             value
+ 31/pinetree
+ 0x21             integer type                 value-tag
+ 0x0005                                        name-length
+ limit            limit                        name
+ 0x0004                                        value-length
+ 0x00000032       50                           value
+ 0x44             keyword type                 value-tag
+ 0x0014                                        name-length
+ requested-       requested-attributes         name
+ attributes
+ 0x0006                                        value-length
+ job-id           job-id                       value
+ 0x44             keyword type                 value-tag
+ 0x0000           additional value             name-length
+ 0x0008                                        value-length
+ job-name         job-name                     value
+ 0x44             keyword type                 value-tag
+ 0x0000           additional value             name-length
+ 0x000F                                        value-length
+ document-format  document-format              value
+ 0x03             end-of-attributes            end-of-attributes-tag
+
+9.8 Get-Jobs Response
+
+   The following is an of Get-Jobs response from previous request with 3
+   jobs. The Printer returns no information about the second job
+   (because of security reasons):
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 32]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ Octets           Symbolic Value                Protocol field
+
+ 0x0100           1.0                           version-number
+ 0x0000           successful-ok                 status-code
+ 0x00000123       0x123                         request-id (echoed
+                                                back)
+ 0x01             start operation-attributes    operation-attribute-tag
+ 0x47             charset type                  value-tag
+ 0x0012                                         name-length
+ attributes-      attributes-charset            name
+ charset
+ 0x000A                                         value-length
+ ISO-8859-1       ISO-8859-1                    value
+ 0x48             natural-language type         value-tag
+ 0x001B                                         name-length
+ attributes-      attributes-natural-language   name
+ natural-
+ language
+ 0x0005                                         value-length
+ en-us            en-US                         value
+ 0x41             textWithoutLanguage type      value-tag
+ 0x000E                                         name-length
+ status-message   status-message                name
+ 0x000D                                         value-length
+ successful-ok    successful-ok                 value
+ 0x02             start job-attributes (1st     job-attributes-tag
+                  object)
+ 0x21             integer type                  value-tag
+ 0x0006                                         name-length
+ job-id           job-id                        name
+ 0x0004                                         value-length
+ 147              147                           value
+ 0x36             nameWithLanguage              value-tag
+ 0x0008                                         name-length
+ job-name         job-name                      name
+ 0x000C                                         value-length
+ 0x0005                                         sub-value-length
+ fr-ca            fr-CA                         value
+ 0x0003                                         sub-value-length
+ fou              fou                           name
+ 0x02             start job-attributes (2nd     job-attributes-tag
+                  object)
+ 0x02             start job-attributes (3rd     job-attributes-tag
+                  object)
+ 0x21             integer type                  value-tag
+ 0x0006                                         name-length
+ job-id           job-id                        name
+ 0x0004                                         value-length
+
+
+
+Herriot, et al.               Experimental                     [Page 33]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+ Octets           Symbolic Value                Protocol field
+
+ 148              148                           value
+ 0x36             nameWithLanguage              value-tag
+ 0x0008                                         name-length
+ job-name         job-name                      name
+ 0x0012                                         value-length
+ 0x0005                                         sub-value-length
+ de-CH            de-CH                         value
+ 0x0009                                         sub-value-length
+ isch guet        isch guet                     name
+ 0x03             end-of-attributes             end-of-attributes-tag
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 34]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+10. Appendix C: Registration of MIME Media Type Information for
+    "application/ipp"
+
+   This appendix contains the information that IANA requires for
+   registering a MIME media type.  The information following this
+   paragraph will be forwarded to IANA to register application/ipp whose
+   contents are defined in Section 3 "Encoding of the Operation Layer"
+   in this document:
+
+   MIME type name: application
+
+   MIME subtype name: ipp
+
+   A Content-Type of "application/ipp" indicates an Internet Printing
+   Protocol message body (request or response). Currently there is one
+   version: IPP/1.0, whose syntax is described in Section 3 "Encoding of
+   the Operation Layer" of [RFC2565], and whose semantics are described
+   in [RFC2566].
+
+   Required parameters:  none
+
+   Optional parameters:  none
+
+   Encoding considerations:
+
+   IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS
+   contain binary data (for example attribute value lengths).
+
+   Security considerations:
+
+   IPP/1.0 protocol requests/responses do not introduce any security
+   risks not already inherent in the underlying transport protocols.
+   Protocol mixed-version interworking rules in [RFC2566] as well as
+   protocol encoding rules in [RFC2565] are complete and unambiguous.
+
+   Interoperability considerations:
+
+   IPP/1.0 requests (generated by clients) and responses (generated by
+   servers) MUST comply with all conformance requirements imposed by the
+   normative specifications [RFC2566] and [RFC2565]. Protocol encoding
+   rules specified in [RFC2565] are comprehensive, so that
+   interoperability between conforming implementations is guaranteed
+   (although support for specific optional features is not ensured).
+   Both the "charset" and "natural-language" of all IPP/1.0 attribute
+   values which are a LOCALIZED-STRING  are explicit within IPP protocol
+   requests/responses (without recourse to any external information in
+   HTTP, SMTP, or other message transport headers).
+
+
+
+
+Herriot, et al.               Experimental                     [Page 35]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+   Published specification:
+
+   [RFC2566] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P.
+             Powell, "Internet Printing Protocol/1.0: Model and
+             Semantics" RFC 2566, April 1999.
+
+   [RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
+             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+             April 1999.
+
+   Applications which use this media type:
+
+   Internet Printing Protocol (IPP) print clients and print servers,
+   communicating using HTTP/1.1 (see [RFC2565]), SMTP/ESMTP, FTP, or
+   other transport protocol. Messages of type "application/ipp" are
+   self-contained and transport-independent, including "charset" and
+   "natural-language" context for any LOCALIZED-STRING value.
+
+   Person & email address to contact for further information:
+
+   Scott A. Isaacson
+   Novell, Inc.
+   122 E 1700 S
+   Provo, UT 84606
+
+   Phone: 801-861-7366
+   Fax: 801-861-4025
+   Email: sisaacson@novell.com
+
+   or
+
+   Robert Herriot (Editor)
+   Xerox Corporation
+   3400 Hillview Ave., Bldg #1
+   Palo Alto, CA 94304
+
+   Phone: 650-813-7696
+   Fax:  650-813-6860
+   EMail: rherriot@pahv.xerox.com
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 36]
+
+RFC 2565            IPP/1.0: Encoding and Transport           April 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 37]
+
diff --git a/standards/rfc2566.txt b/standards/rfc2566.txt
new file mode 100644
index 000000000..f373d6a0f
--- /dev/null
+++ b/standards/rfc2566.txt
@@ -0,0 +1,9691 @@
+
+
+
+
+
+
+Network Working Group                                           R. deBry
+Request for Comments: 2566                     Utah Valley State College
+Category: Experimental                                       T. Hastings
+                                                       Xerox Corporation
+                                                              R. Herriot
+                                                       Xerox Corporation
+                                                             S. Isaacson
+                                                            Novell, Inc.
+                                                               P. Powell
+                                                     Astart Technologies
+                                                              April 1999
+
+
+          Internet Printing Protocol/1.0: Model and Semantics
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+IESG Note
+
+   This document defines an Experimental protocol for the Internet
+   community.  The IESG expects that a revised version of this protocol
+   will be published as Proposed Standard protocol.  The Proposed
+   Standard, when published, is expected to change from the protocol
+   defined in this memo.  In particular, it is expected that the
+   standards-track version of the protocol will incorporate strong
+   authentication and privacy features, and that an "ipp:" URL type will
+   be defined which supports those security measures.  Other changes to
+   the protocol are also possible.  Implementors are warned that future
+   versions of this protocol may not interoperate with the version of
+   IPP defined in this document, or if they do interoperate, that some
+   protocol features may not be available.
+
+   The IESG encourages experimentation with this protocol, especially in
+   combination with Transport Layer Security (TLS) [RFC 2246], to help
+   determine how TLS may effectively be used as a security layer for
+   IPP.
+
+
+
+
+
+
+deBry, et al.                 Experimental                      [Page 1]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+Abstract
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies.  This document describes a
+   simplified model consisting of abstract objects, their attributes,
+   and their operations that is independent of encoding and transport.
+   The model consists of a Printer and a Job object.  A Job optionally
+   supports multiple documents.  IPP 1.0 semantics allow end-users and
+   operators to query printer capabilities, submit print jobs, inquire
+   about the status of print jobs and printers, and cancel print jobs.
+   This document also addresses security, internationalization, and
+   directory issues.
+
+   The full set of IPP documents includes:
+
+     Design Goals for an Internet Printing Protocol [RFC2567]
+     Rationale for the Structure and Model and Protocol for the Internet
+        Printing Protocol [RFC2568]
+     Internet Printing Protocol/1.0: Model and Semantics (this document)
+     Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
+     Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
+     Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0.  Operator and administrator requirements
+   are out of scope for version 1.0.
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specifications, and gives background and rationale for the
+   IETF working group's major decisions.
+
+   The "Internet Printing Protocol/1.0: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1.  It defines the encoding rules
+   for a new Internet media type called "application/ipp".
+
+   The "Internet Printing Protocol/1.0: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.0 and some of
+
+
+
+deBry, et al.                 Experimental                      [Page 2]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+Table of Contents
+
+1. Introduction                                                        8
+ 1.1   Simplified Printing Model                                       9
+2. IPP Objects                                                        11
+ 2.1   Printer Object                                                 12
+ 2.2   Job Object                                                     14
+ 2.3   Object Relationships                                           14
+ 2.4   Object Identity                                                15
+3. IPP Operations                                                     18
+ 3.1   Common Semantics                                               19
+  3.1.1   Required Parameters                                         19
+  3.1.2   Operation IDs and Request IDs                               20
+  3.1.3   Attributes                                                  20
+  3.1.4   Character Set and Natural Language Operation Attributes     22
+   3.1.4.1  Request Operation Attributes                              22
+   3.1.4.2  Response Operation Attributes                             26
+  3.1.5   Operation Targets                                           28
+  3.1.6   Operation Status Codes and Messages                         29
+  3.1.7   Versions                                                    30
+  3.1.8   Job Creation Operations                                     32
+ 3.2   Printer Operations                                             34
+  3.2.1   Print-Job Operation                                         34
+   3.2.1.1  Print-Job Request                                         34
+   3.2.1.2  Print-Job Response                                        38
+  3.2.2   Print-URI Operation                                         41
+  3.2.3   Validate-Job Operation                                      42
+  3.2.4   Create-Job Operation                                        42
+  3.2.5   Get-Printer-Attributes Operation                            43
+   3.2.5.1  Get-Printer-Attributes Request                            44
+   3.2.5.2  Get-Printer-Attributes Response                           46
+  3.2.6   Get-Jobs Operation                                          47
+   3.2.6.1  Get-Jobs Request                                          47
+   3.2.6.2  Get-Jobs Response                                         49
+ 3.3   Job Operations                                                 50
+  3.3.1   Send-Document Operation                                     50
+   3.3.1.1  Send-Document Request                                     51
+   3.3.1.2  Send-Document Response                                    53
+  3.3.2   Send-URI Operation                                          54
+
+
+
+deBry, et al.                 Experimental                      [Page 3]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+  3.3.3   Cancel-Job Operation                                        54
+   3.3.3.1  Cancel-Job Request                                        54
+   3.3.3.2  Cancel-Job Response                                       55
+  3.3.4   Get-Job-Attributes Operation                                56
+   3.3.4.1  Get-Job-Attributes Request                                57
+   3.3.4.2  Get-Job-Attributes Response                               57
+4. Object Attributes                                                  58
+ 4.1   Attribute Syntaxes                                             59
+  4.1.1   'text'                                                      60
+   4.1.1.1  'textWithoutLanguage'                                     61
+   4.1.1.2  'textWithLanguage'                                        61
+  4.1.2   'name'                                                      62
+   4.1.2.1  'nameWithoutLanguage'                                     62
+   4.1.2.2  'nameWithLanguage'                                        63
+   4.1.2.3  Matching 'name' attribute values                          63
+  4.1.3   'keyword'                                                   64
+  4.1.4   'enum'                                                      65
+  4.1.5   'uri'                                                       65
+  4.1.6   'uriScheme'                                                 65
+  4.1.7   'charset'                                                   66
+  4.1.8   'naturalLanguage'                                           67
+  4.1.9   'mimeMediaType'                                             67
+  4.1.10  'octetString'                                               69
+  4.1.11  'boolean'                                                   69
+  4.1.12  'integer'                                                   69
+  4.1.13  'rangeOfInteger'                                            69
+  4.1.14  'dateTime'                                                  69
+  4.1.15  'resolution'                                                69
+  4.1.16  '1setOf  X'                                                 70
+ 4.2   Job Template Attributes                                        70
+  4.2.1   job-priority (integer(1:100))                               74
+  4.2.2   job-hold-until (type3 keyword | name (MAX))                 75
+  4.2.3   job-sheets (type3 keyword | name(MAX))                      75
+  4.2.4   multiple-document-handling (type2 keyword)                  76
+  4.2.5   copies (integer(1:MAX))                                     77
+  4.2.6   finishings (1setOf type2 enum)                              78
+  4.2.7   page-ranges (1setOf rangeOfInteger (1:MAX))                 79
+  4.2.8   sides (type2 keyword)                                       80
+  4.2.9   number-up (integer(1:MAX))                                  80
+  4.2.10  orientation-requested (type2 enum)                          81
+  4.2.11  media (type3 keyword | name(MAX))                           82
+  4.2.12  printer-resolution (resolution)                             83
+  4.2.13  print-quality (type2 enum)                                  83
+ 4.3   Job Description Attributes                                     84
+  4.3.1   job-uri (uri)                                               85
+  4.3.2   job-id (integer(1:MAX))                                     85
+  4.3.3   job-printer-uri (uri)                                       86
+  4.3.4   job-more-info (uri)                                         86
+
+
+
+deBry, et al.                 Experimental                      [Page 4]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+  4.3.5   job-name (name(MAX))                                        86
+  4.3.6   job-originating-user-name (name(MAX))                       86
+  4.3.7   job-state (type1 enum)                                      87
+  4.3.8   job-state-reasons (1setOf  type2 keyword)                   90
+  4.3.9   job-state-message (text(MAX))                               92
+  4.3.10  number-of-documents (integer(0:MAX))                        93
+  4.3.11  output-device-assigned (name(127))                          93
+  4.3.12  time-at-creation (integer(0:MAX))                           93
+  4.3.13  time-at-processing (integer(0:MAX))                         93
+  4.3.14  time-at-completed (integer(0:MAX))                          94
+  4.3.15  number-of-intervening-jobs (integer(0:MAX))                 94
+  4.3.16  job-message-from-operator (text(127))                       94
+  4.3.17  job-k-octets (integer(0:MAX))                               94
+  4.3.18  job-impressions (integer(0:MAX))                            95
+  4.3.19  job-media-sheets (integer(0:MAX))                           95
+  4.3.20  job-k-octets-processed (integer(0:MAX))                     96
+  4.3.21  job-impressions-completed (integer(0:MAX))                  96
+  4.3.22  job-media-sheets-completed (integer(0:MAX))                 96
+  4.3.23  attributes-charset (charset)                                97
+  4.3.24  attributes-natural-language (naturalLanguage)               97
+ 4.4   Printer Description Attributes                                 97
+  4.4.1   printer-uri-supported (1setOf uri)                          99
+  4.4.2   uri-security-supported (1setOf type2 keyword)              100
+  4.4.3   printer-name (name(127))                                   101
+  4.4.4   printer-location (text(127))                               101
+  4.4.5   printer-info (text(127))                                   101
+  4.4.6   printer-more-info (uri)                                    101
+  4.4.7   printer-driver-installer (uri)                             102
+  4.4.8   printer-make-and-model (text(127))                         102
+  4.4.9   printer-more-info-manufacturer (uri)                       102
+  4.4.10  printer-state (type1 enum)                                 102
+  4.4.11  printer-state-reasons (1setOf type2 keyword)               103
+  4.4.12  printer-state-message (text(MAX))                          106
+  4.4.13  operations-supported (1setOf type2 enum)                   106
+  4.4.14  charset-configured (charset)                               107
+  4.4.15  charset-supported (1setOf charset)                         107
+  4.4.16  natural-language-configured (naturalLanguage)              107
+  4.4.17  generated-natural-language-supported(1setOf naturalLanguage108
+  4.4.18  document-format-default (mimeMediaType)                    108
+  4.4.19  document-format-supported (1setOf mimeMediaType)           108
+  4.4.20  printer-is-accepting-jobs (boolean)                        109
+  4.4.21  queued-job-count (integer(0:MAX))                          109
+  4.4.22  printer-message-from-operator (text(127))                  109
+  4.4.23  color-supported (boolean)                                  109
+  4.4.24  reference-uri-schemes-supported (1setOf uriScheme)         109
+  4.4.25  pdl-override-supported (type2 keyword)                     110
+  4.4.26  printer-up-time (integer(1:MAX))                           110
+  4.4.27  printer-current-time (dateTime)                            111
+
+
+
+deBry, et al.                 Experimental                      [Page 5]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+  4.4.28  multiple-operation-time-out (integer(1:MAX))               111
+  4.4.29  compression-supported (1setOf type3 keyword)               111
+  4.4.30  job-k-octets-supported (rangeOfInteger(0:MAX))             112
+  4.4.31  job-impressions-supported (rangeOfInteger(0:MAX))          112
+  4.4.32  job-media-sheets-supported (rangeOfInteger(0:MAX))         112
+5. Conformance                                                       112
+ 5.1   Client Conformance Requirements                               112
+ 5.2   IPP Object Conformance Requirements                           113
+  5.2.1   Objects                                                    113
+  5.2.2   Operations                                                 113
+  5.2.3   IPP Object Attributes                                      114
+  5.2.4   Extensions                                                 114
+  5.2.5   Attribute Syntaxes                                         115
+ 5.3   Charset and Natural Language Requirements                     115
+ 5.4   Security Conformance Requirements                             115
+6. IANA Considerations (registered and private extensions)           116
+ 6.1   Typed 'keyword' and 'enum' Extensions                         116
+ 6.2   Attribute Extensibility                                       119
+ 6.3   Attribute Syntax Extensibility                                119
+ 6.4   Operation Extensibility                                       120
+ 6.5   Attribute Groups                                              120
+ 6.6   Status Code Extensibility                                     120
+ 6.7   Registration of MIME types/sub-types for document-formats     121
+ 6.8   Registration of charsets for use in 'charset' attribute values121
+7. Internationalization Considerations                               121
+8. Security Considerations                                           125
+ 8.1   Security Scenarios                                            126
+  8.1.1   Client and Server in the Same Security Domain              126
+  8.1.2   Client and Server in Different Security Domains            126
+  8.1.3   Print by Reference                                         127
+ 8.2   URIs for SSL3 and non-SSL3 Access                             127
+ 8.3   The "requesting-user-name" (name(MAX)) Operation Attribute    127
+ 8.4   Restricted Queries                                            129
+ 8.5   Queries on jobs submitted using non-IPP protocols             129
+ 8.6   IPP Security Application Profile for SSL3                     130
+9. References                                                        131
+10. Authors' Addresses                                               134
+11. Formats for IPP Registration Proposals                           136
+ 11.1  Type2 keyword attribute values registration                   136
+ 11.2  Type3 keyword attribute values registration                   137
+ 11.3  Type2 enum attribute values registration                      137
+ 11.4  Type3 enum attribute values registration                      137
+ 11.5  Attribute registration                                        138
+ 11.6  Attribute Syntax registration                                 138
+ 11.7  Operation registration                                        139
+ 11.8  Attribute Group registration                                  139
+ 11.9  Status code registration                                      139
+12.APPENDIX A: Terminology                                           141
+
+
+
+deBry, et al.                 Experimental                      [Page 6]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+ 12.1  Conformance Terminology                                       141
+  12.1.1  NEED NOT                                                   141
+ 12.2  Model Terminology                                             141
+  12.2.1  Keyword                                                    141
+  12.2.2  Attributes                                                 141
+   12.2.2.1 Attribute Name                                           141
+   12.2.2.2 Attribute Group Name                                     142
+   12.2.2.3 Attribute Value                                          142
+   12.2.2.4 Attribute Syntax                                         142
+  12.2.3  Supports                                                   142
+  12.2.4  print-stream page                                          144
+  12.2.5  impression                                                 144
+13.APPENDIX B:  Status Codes and Suggested Status Code Messages      145
+ 13.1  Status Codes                                                  146
+  13.1.1  Informational                                              146
+  13.1.2  Successful Status Codes                                    146
+   13.1.2.1 successful-ok (0x0000)                                   146
+   13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 146
+   13.1.2.3 successful-ok-conflicting-attributes (0x0002)            147
+  13.1.3  Redirection Status Codes                                   147
+  13.1.4  Client Error Status Codes                                  147
+   13.1.4.1 client-error-bad-request (0x0400)                        147
+   13.1.4.2 client-error-forbidden (0x0401)                          147
+   13.1.4.3 client-error-not-authenticated (0x0402)                  148
+   13.1.4.4 client-error-not-authorized (0x0403)                     148
+   13.1.4.5 client-error-not-possible (0x0404)                       148
+   13.1.4.6 client-error-timeout (0x0405)                            148
+   13.1.4.7 client-error-not-found (0x0406)                          149
+   13.1.4.8 client-error-gone (0x0407)                               149
+   13.1.4.9 client-error-request-entity-too-large (0x0408)           149
+   13.1.4.10client-error-request-value-too-long (0x0409)             150
+   13.1.4.11client-error-document-format-not-supported (0x040A)      150
+   13.1.4.12client-error-attributes-or-values-not-supported (0x040B) 150
+   13.1.4.13client-error-uri-scheme-not-supported (0x040C)           151
+   13.1.4.14client-error-charset-not-supported (0x040D)              151
+   13.1.4.15client-error-conflicting-attributes (0x040E)             151
+  13.1.5  Server Error Status Codes                                  151
+   13.1.5.1 server-error-internal-error (0x0500)                     151
+   13.1.5.2 server-error-operation-not-supported (0x0501)            152
+   13.1.5.3 server-error-service-unavailable (0x0502)                152
+   13.1.5.4 server-error-version-not-supported (0x0503)              152
+   13.1.5.5 server-error-device-error (0x0504)                       152
+   13.1.5.6 server-error-temporary-error (0x0505)                    153
+   13.1.5.7 server-error-not-accepting-jobs (0x0506)                 153
+   13.1.5.8 server-error-busy (0x0507)                               153
+   13.1.5.9 server-error-job-canceled (0x0508)                       153
+ 13.2  Status Codes for IPP Operations                               153
+14.APPENDIX C:  "media" keyword values                               155
+
+
+
+deBry, et al.                 Experimental                      [Page 7]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+15.APPENDIX D: Processing IPP Attributes                             160
+ 15.1  Fidelity                                                      160
+ 15.2  Page Description Language (PDL) Override                      161
+ 15.3  Using Job Template Attributes During Document Processing.     163
+16.APPENDIX E: Generic Directory Schema                              166
+17.APPENDIX F: Change History for the Model and Semantics document   168
+18.FULL COPYRIGHT STATEMENT                                          173
+
+1. Introduction
+
+   The Internet Printing Protocol (IPP) is an application level protocol
+   that can be used for distributed printing using Internet tools and
+   technologies.  IPP version 1.0 (IPP/1.0) focuses only on end user
+   functionality.  This document is just one of a suite of documents
+   that fully define IPP.  The full set of IPP documents includes:
+
+     Design Goals for an Internet Printing Protocol [RFC2567]
+     Rationale for the Structure and Model and Protocol for the Internet
+        Printing Protocol [RFC2568]
+     Internet Printing Protocol/1.0: Model and Semantics (this document)
+     Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
+     Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
+     Mapping between LPD and IPP Protocols [RFC2569]
+
+   Anyone reading these documents for the first time is strongly
+   encouraged to read the IPP documents in the above order.
+
+   This document is laid out as follows:
+
+     - The rest of Section 1 is an introduction to the IPP simplified
+       model for distributed printing.
+     - Section 2 introduces the object types covered in the model with
+       their basic behaviors, attributes, and interactions.
+     - Section 3 defines the operations included in IPP/1.0.  IPP
+       operations are synchronous, therefore, for each operation, there
+       is a both request and a response.
+     - Section 4 defines the attributes (and their syntaxes) that are
+       used in the model.
+     - Sections 5 - 6 summarizes the implementation conformance
+       requirements for objects that support the protocol and IANA
+       considerations, respectively.
+     - Sections 7 - 11 cover the Internationalization and Security
+       considerations as well as References, Author contact information,
+       and Formats for Registration Proposals.
+     - Sections 12 - 14 are appendices that cover Terminology, Status
+       Codes and Messages, and "media" keyword values.
+
+
+
+
+
+deBry, et al.                 Experimental                      [Page 8]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+             Note: This document uses terms such as "attributes",
+             "keywords", and "support".  These terms have special
+             meaning and are defined in the model terminology section
+             12.2.  Capitalized terms, such as MUST, MUST NOT, REQUIRED,
+             SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have
+             special meaning relating to conformance.  These terms are
+             defined in section 12.1 on conformance terminology, most of
+             which is taken from RFC 2119 [RFC2119].
+
+     - Section 15 is an appendix that helps to clarify the effects of
+       interactions between related attributes and their values.
+     - Section 16 is an appendix that enumerates the subset of Printer
+       attributes that form a generic directory schema.  These
+       attributes are useful when registering a Printer so that a
+       client can find the Printer not just by name, but by filtered
+       searches as well.
+     - Section 17 is an appendix that provides a Change History
+       summarizing the clarification and changes that might affect an
+       implementation since the June 30, 1998 draft.
+
+1.1 Simplified Printing Model
+
+   In order to achieve its goal of realizing a workable printing
+   protocol for the Internet, the Internet Printing Protocol (IPP) is
+   based on a simplified printing model that abstracts the many
+   components of real world printing solutions.  The Internet is a
+   distributed computing environment where requesters of print services
+   (clients, applications, printer drivers, etc.) cooperate and interact
+   with print service providers.  This model and semantics document
+   describes a simple, abstract model for IPP even though the underlying
+   configurations may be complex "n-tier" client/server systems.  An
+   important simplifying step in the IPP model is to expose only the key
+   objects and interfaces required for printing.  The model described in
+   this model document does not include features, interfaces, and
+   relationships that are beyond the scope of the first version of IPP
+   (IPP/1.0).  IPP/1.0 incorporates many of the relevant ideas and
+   lessons learned from other specification and development efforts
+   [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP].  IPP is
+   heavily influenced by the printing model introduced in the Document
+   Printing Application (DPA) [ISO10175] standard.  Although DPA
+   specifies both end user and administrative features, IPP version 1.0
+   (IPP/1.0) focuses only on end user functionality.
+
+   The IPP/1.0 model encapsulates the important components of
+   distributed printing into two object types:
+
+     - Printer (Section 2.1)
+     - Job (Section 2.2)
+
+
+
+deBry, et al.                 Experimental                      [Page 9]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Each object type has an associated set of operations (see section 3)
+   and attributes (see section 4).
+
+   It is important, however, to understand that in real system
+   implementations (which lie underneath the abstracted IPP/1.0 model),
+   there are other components of a print service which are not
+   explicitly defined in the IPP/1.0 model. The following figure
+   illustrates where IPP/1.0 fits with respect to these other
+   components.
+
+                                +--------------+
+                                |  Application |
+                      o         +. . . . . . . |
+                     \|/        |   Spooler    |
+                     / \        +. . . . . . . |   +---------+
+                   End-User     | Print Driver |---|  File   |
+         +-----------+ +-----+  +------+-------+   +----+----+
+         |  Browser  | | GUI |         |                |
+         +-----+-----+ +--+--+         |                |
+               |          |            |                |
+               |      +---+------------+---+            |
+   N   D   S   |      |      IPP Client    |------------+
+   O   I   E   |      +---------+----------+
+   T   R   C   |                |
+   I   E   U   |
+   F   C   R   -------------- Transport ------------------
+   I   T   I
+   C   O   T                    |         --+
+   A   R   Y           +--------+--------+  |
+   T   Y               |    IPP Server   |  |
+   I                   +--------+--------+  |
+   O                            |           |
+   N                   +-----------------+  | IPP Printer
+                       |  Print Service  |  |
+                       +-----------------+  |
+                                |         --+
+                       +-----------------+
+                       | Output Device(s)|
+                       +-----------------+
+
+   An IPP Printer object encapsulates the functions normally associated
+   with physical output devices along with the spooling, scheduling and
+   multiple device management functions often associated with a print
+   server. Printer objects are optionally registered as entries in a
+   directory where end users find and select them based on some sort of
+   filtered and context based searching mechanism (see section 16).  The
+   directory is used to store relatively static information about the
+   Printer, allowing end users to search for and find Printers that
+
+
+
+deBry, et al.                 Experimental                     [Page 10]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   match their search criteria, for example: name, context, printer
+   capabilities, etc.  The more dynamic information, such as state,
+   currently loaded and ready media, number of jobs at the Printer,
+   errors, warnings, and so forth, is directly associated with the
+   Printer object itself rather than with the entry in the directory
+   which only represents the Printer object.
+
+   IPP clients implement the IPP protocol on the client side and give
+   end users (or programs running on behalf of end users) the ability to
+   query Printer objects and submit and manage print jobs.  An IPP
+   server is just that part of the Printer object that implements the
+   server-side protocol.  The rest of the Printer object implements (or
+   gateways into) the application semantics of the print service itself.
+   The Printer objects may be embedded in an output device or may be
+   implemented on a host on the network that communicates with an output
+   device.
+
+   When a job is submitted to the Printer object and the Printer object
+   validates the attributes in the submission request, the Printer
+   object creates a new Job object.  The end user then interacts with
+   this new Job object to query its status and monitor the progress of
+   the job.  End users may also cancel the print job by using the Job
+   object's Cancel-Job operation.  The notification service is out of
+   scope for IPP/1.0, but using such a notification service, the end
+   user is able to register for and receive Printer specific and Job
+   specific events.  An end user can query the status of Printer objects
+   and can follow the progress of Job objects by polling using the Get-
+   Printer-Attributes, Get-Jobs, and Get-Job-Attributes operations.
+
+2. IPP Objects
+
+   The IPP/1.0 model introduces objects of type Printer and Job.  Each
+   type of object models relevant aspects of a real-world entity such as
+   a real printer or real print job.  Each object type is defined as a
+   set of possible attributes that may be supported by instances of that
+   object type.  For each object (instance), the actual set of supported
+   attributes and values describe a specific implementation.  The
+   object's attributes and values describe its state, capabilities,
+   realizable features, job processing functions, and default behaviors
+   and characteristics.  For example, the Printer object type is defined
+   as a set of attributes that each Printer object potentially supports.
+   In the same manner, the Job object type is defined as a set of
+   attributes that are potentially supported by each Job object.
+
+   Each attribute included in the set of attributes defining an object
+   type is labeled as:
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 11]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     - "REQUIRED": each object MUST support the attribute.
+     - "OPTIONAL": each object MAY support the attribute.
+
+   There is no such similar labeling of attribute values.  However, if
+   an implementation supports an attribute, it MUST support at least one
+   of the possible values for that attribute.
+
+2.1 Printer Object
+
+   The major component of the IPP/1.0 model is the Printer object.  A
+   Printer object implements the server-side of the IPP/1.0 protocol.
+   Using the protocol, end users may query the attributes of the Printer
+   object and submit print jobs to the Printer object.  The actual
+   implementation components behind the Printer abstraction may take on
+   different forms and different configurations.  However, the model
+   abstraction allows the details of the configuration of real
+   components to remain opaque to the end user.  Section 3 describes
+   each of the Printer operations in detail.
+
+   The capabilities and state of a Printer object are described by its
+   attributes.  Printer attributes are divided into two groups:
+
+     - "job-template" attributes: These attributes describe supported
+       job processing capabilities and defaults for the Printer object.
+       (See section 4.2)
+     - "printer-description" attributes: These attributes describe the
+       Printer object's identification, state, location, references to
+       other sources of information about the Printer object, etc. (see
+       section 4.4)
+
+   Since a Printer object is an abstraction of a generic document output
+   device and print service provider, a Printer object could be used to
+   represent any real or virtual device with semantics consistent with
+   the Printer object, such as a fax device, an imager, or even a CD
+   writer.
+
+   Some examples of configurations supporting a Printer object include:
+
+     1) An output device with no spooling capabilities
+     2) An output device with a built-in spooler
+     3) A print server supporting IPP with one or more associated output
+        devices
+        3a) The associated output devices may or may not be capable of
+          spooling jobs
+        3b) The associated output devices may or may not support IPP
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 12]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   The following figures show some examples of how Printer objects can
+   be realized on top of various distributed printing configurations.
+   The embedded case below represents configurations 1 and 2. The hosted
+   and fan-out figures below represent configurations 3a and 3b.
+
+   Legend:
+
+   ##### indicates a Printer object which is
+         either embedded in an output device or is
+         hosted in a server.  The Printer object
+         might or might not be capable of queuing/spooling.
+
+   any   indicates any network protocol or direct
+         connect, including IPP
+
+
+   embedded printer:
+                                             output device
+                                           +---------------+
+    O   +--------+                         |  ###########  |
+   /|\  | client |------------IPP------------># Printer #  |
+   / \  +--------+                         |  # Object  #  |
+                                           |  ###########  |
+                                           +---------------+
+
+
+   hosted printer:
+                                           +---------------+
+    O   +--------+        ###########      |               |
+   /|\  | client |--IPP--># Printer #-any->| output device |
+   / \  +--------+        # Object  #      |               |
+                          ###########      +---------------+
+
+
+
+                                            +---------------+
+   fan out:                                 |               |
+                                        +-->| output device |
+                                    any/    |               |
+    O   +--------+      ###########   /     +---------------+
+   /|\  | client |-IPP-># Printer #--*
+   / \  +--------+      # Object  #   \     +---------------+
+                        ########### any\    |               |
+                                        +-->| output device |
+                                            |               |
+                                            +---------------+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 13]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+2.2 Job Object
+
+   A Job object is used to model a print job.  A Job object contains
+   documents.  The information required to create a Job object is sent
+   in a create request from the end user via an IPP Client to the
+   Printer object.  The Printer object validates the create request, and
+   if the Printer object accepts the request, the Printer object creates
+   the new Job object.  Section 3 describes each of the Job operations
+   in detail.
+
+   The characteristics and state of a Job object are described by its
+   attributes.  Job attributes are grouped into two groups as follows:
+
+     - "job-template" attributes: These attributes can be supplied by
+       the client or end user and include job processing instructions
+       which are intended to override any Printer object defaults and/or
+       instructions embedded within the document data. (See section 4.2)
+     - "job-description" attributes: These attributes describe the Job
+       object's identification, state, size, etc. The client supplies
+       some of these attributes, and the Printer object generates others.
+       (See section 4.3)
+
+   An implementation MUST support at least one document per Job object.
+   An implementation MAY support multiple documents per Job object.  A
+   document is either:
+
+     - a stream of document data in a format supported by the Printer
+       object (typically a Page Description Language - PDL), or
+     - a reference to such a stream of document data
+
+   In IPP/1.0, a document is not modeled as an IPP object, therefore it
+   has no object identifier or associated attributes.  All job
+   processing instructions are modeled as Job object attributes.  These
+   attributes are called Job Template attributes and they apply equally
+   to all documents within a Job object.
+
+2.3 Object Relationships
+
+   IPP objects have relationships that are maintained persistently along
+   with the persistent storage of the object attributes.
+
+   A Printer object can represent either one or more physical output
+   devices or a logical device which "processes" jobs but never actually
+   uses a physical output device to put marks on paper.  Examples of
+   logical devices include a Web page publisher or a gateway into an
+   online document archive or repository.  A Printer object contains
+   zero or more Job objects.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 14]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   A Job object is contained by exactly one Printer object, however the
+   identical document data associated with a Job object could be sent to
+   either the same or a different Printer object.  In this case, a
+   second Job object would be created which would be almost identical to
+   the first Job object, however it would have new (different) Job
+   object identifiers (see section 2.4).
+
+   A Job object is either empty (before any documents have been added)
+   or contains one or more documents.  If the contained document is a
+   stream of document data, that stream can be contained in only one
+   document.  However, there can be identical copies of the stream in
+   other documents in the same or different Job objects.  If the
+   contained document is just a reference to a stream of document data,
+   other documents (in the same or different Job object(s)) may contain
+   the same reference.
+
+2.4 Object Identity
+
+   All Printer and Job objects are identified by a Uniform Resource
+   Identifier (URI) [RFC2396] so that they can be persistently and
+   unambiguously referenced.  The notion of a URI is a useful concept,
+   however, until the notion of URI is more stable (i.e., defined more
+   completely and deployed more widely), it is expected that the URIs
+   used for IPP objects will actually be URLs [RFC2396].  Since every
+   URL is a specialized form of a URI, even though the more generic term
+   URI is used throughout the rest of this document, its usage is
+   intended to cover the more specific notion of URL as well.
+
+   An administrator configures Printer objects to either support or not
+   support authentication and/or message privacy using SSL3 [SSL] (the
+   mechanism for security configuration is outside the scope of
+   IPP/1.0).  In some situations, both types of connections (both
+   authenticated and unauthenticated) can be established using a single
+   communication channel that has some sort of negotiation mechanism.
+   In other situations, multiple communication channels are used, one
+   for each type of security configuration.  Section 8 provides a full
+   description of all security considerations and configurations.
+
+   If a Printer object supports more than one communication channel,
+   some or all of those channels might support and/or require different
+   security mechanisms.  In such cases, an administrator could expose
+   the simultaneous support for these multiple communication channels as
+   multiple URIs for a single Printer object where each URI represents
+   one of the communication channels to the Printer object. To support
+   this flexibility, the IPP Printer object type defines a multi-valued
+   identification attribute called the "printer-uri-supported"
+   attribute.  It MUST contain at least one URI.  It MAY contain more
+   than one URI.  That is, every Printer object will have at least one
+
+
+
+deBry, et al.                 Experimental                     [Page 15]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   URI that identifies at least one communication channel to the Printer
+   object, but it may have more than one URI where each URI identifies a
+   different communication channel to the Printer object.  The
+   "printer-uri-supported" attribute has a companion attribute, the
+   "uri-security-supported" attribute, that has the same cardinality as
+   "printer-uri-supported".  The purpose of the "uri-security-supported"
+   attribute is to indicate the security mechanisms (if any) used for
+   each URI listed in "printer-uri-supported".  These two attributes are
+   fully described in sections 4.4.1 and 4.4.2.
+
+   When a job is submitted to the Printer object via a create request,
+   the client supplies only a single Printer object URI.  The client
+   supplied Printer object URI MUST be one of the values in the
+   "printer-uri-supported" Printer attribute.
+
+   Note:  IPP/1.0 does not specify how the client obtains the client
+   supplied URI, but it is RECOMMENDED that a Printer object be
+   registered as an entry in a directory service.  End-users and
+   programs can then interrogate the directory searching for Printers.
+   Section 16 defines a generic schema for Printer object entries in the
+   directory service and describes how the entry acts as a bridge to the
+   actual IPP Printer object.  The entry in the directory that
+   represents the IPP Printer object includes the possibly many URIs for
+   that Printer object as values in one its attributes.
+
+   When a client submits a create request to the Printer object, the
+   Printer object validates the request and creates a new Job object.
+   The Printer object assigns the new Job object a URI which is stored
+   in the "job-uri" Job attribute.  This URI is then used by clients as
+   the target for subsequent Job operations.  The Printer object
+   generates a Job URI based on its configured security policy and the
+   URI used by the client in the create request.
+
+   For example, consider a Printer object that supports both a
+   communication channel secured by the use of SSL3 (using HTTP over
+   SSL3 with an "https" schemed URI) and another open communication
+   channel that is not secured with SSL3 (using a simple "http" schemed
+   URI).  If a client were to submit a job using the secure URI, the
+   Printer object would assign the new Job object a secure URI as well.
+   If a client were to submit a job using the open-channel URI, the
+   Printer would assign the new Job object an open-channel URI.
+
+   In addition, the Printer object also populates the Job object's
+   "job-printer-uri" attribute.  This is a reference back to the Printer
+   object that created the Job object.  If a client only has access to a
+   Job object's "job-uri" identifier, the client can query the Job's
+   "job-printer-uri" attribute in order to determine which Printer
+   object created the Job object.  If the Printer object supports more
+
+
+
+deBry, et al.                 Experimental                     [Page 16]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   than one URI, the Printer object picks the one URI supplied by the
+   client when creating the job to build the value for and to populate
+   the Job's "job-printer-uri" attribute.
+
+   Allowing Job objects to have URIs allows for flexibility and
+   scalability.  For example, in some implementations, the Printer
+   object might create Jobs that are processed in the same local
+   environment as the Printer object itself.  In this case, the Job URI
+   might just be a composition of the Printer's URI and some unique
+   component for the Job object, such as the unique 32-bit positive
+   integer mentioned later in this paragraph.  In other implementations,
+   the Printer object might be a central clearing-house for validating
+   all Job object creation requests, but the Job object itself might be
+   created in some environment that is remote from the Printer object.
+   In this case, the Job object's URI may have no physical-location
+   relationship at all to the Printer object's URI.  Again, the fact
+   that Job objects have URIs allows for flexibility and scalability,
+   however, many existing printing systems have local models or
+   interface constraints that force print jobs to be identified using
+   only a 32-bit positive integer rather than an independent URI.  This
+   numeric Job ID is only unique within the context of the Printer
+   object to which the create request was originally submitted.
+   Therefore, in order to allow both types of client access to IPP Job
+   objects (either by Job URI or by numeric Job ID), when the Printer
+   object successfully processes a create request and creates a new Job
+   object, the Printer object MUST generate both a Job URI and a Job ID.
+   The Job ID (stored in the "job-id" attribute) only has meaning in the
+   context of the Printer object to which the create request was
+   originally submitted. This requirement to support both Job URIs and
+   Job IDs allows all types of clients to access Printer objects and Job
+   objects no matter the local constraints imposed on the client
+   implementation.
+
+   In addition to identifiers, Printer objects and Job objects have
+   names ("printer-name" and "job-name").  An object name NEED NOT be
+   unique across all instances of all objects. A Printer object's name
+   is chosen and set by an administrator through some mechanism outside
+   the scope of IPP/1.0.  A Job object's name is optionally chosen and
+   supplied by the IPP client submitting the job.  If the client does
+   not supply a Job object name, the Printer object generates a name for
+   the new Job object.  In all cases, the name only has local meaning.
+
+   To summarize:
+
+     - Each Printer object is identified with one or more URIs.  The
+       Printer's "printer-uri-supported" attribute contains the URI(s).
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 17]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     - The Printer object's "uri-security-supported" attribute
+       identifies the communication channel security protocols that may
+       or may not have been configured for the various Printer object
+       URIs (e.g., 'ssl3' or 'none').
+     - Each Job object is identified with a Job URI.  The Job's "job-uri"
+       attribute contains the URI.
+     - Each Job object is also identified with Job ID which is a 32-bit,
+       positive integer.  The Job's "job-id" attribute contains the Job
+       ID.  The Job ID is only unique within the context of the Printer
+       object  which created the Job object.
+     - Each Job object has a "job-printer-uri" attribute which contains
+       the URI of the Printer object that was used to create the Job
+       object.  This attribute is used to determine the Printer object
+       that created a Job object when given only the URI for the Job
+       object.  This linkage is necessary to determine the languages,
+       charsets, and operations which are supported on that Job (the
+       basis for such support comes from the creating Printer object).
+     - Each Printer object has a name (which is not necessarily unique).
+       The administrator chooses and sets this name through some
+       mechanism outside the scope of IPP/1.0 itself.  The Printer
+       object's "printer-name" attribute contains the name.
+     - Each Job object has a name (which is not necessarily unique).  The
+       client optionally supplies this name in the create request.  If
+       the client does not supply this name, the Printer object generates
+       a name for the Job object. The Job object's "job-name" attribute
+       contains the name.
+
+3. IPP Operations
+
+   IPP objects support operations.  An operation consists of a request
+   and a response.  When a client communicates with an IPP object, the
+   client issues an operation request to the URI for that object.
+   Operation requests and responses have parameters that identify the
+   operation.  Operations also have attributes that affect the run-time
+   characteristics of the operation (the intended target, localization
+   information, etc.).  These operation-specific attributes are called
+   operation attributes (as compared to object attributes such as
+   Printer object attributes or Job object attributes).  Each request
+   carries along with it any operation attributes, object attributes,
+   and/or document data required to perform the operation.  Each request
+   requires a response from the object.  Each response indicates success
+   or failure of the operation with a status code as a response
+   parameter.  The response contains any operation attributes, object
+   attributes, and/or status messages generated during the execution of
+   the operation request.
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 18]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   This section describes the semantics of the IPP operations, both
+   requests and responses, in terms of the parameters, attributes, and
+   other data associated with each operation.
+
+   The IPP/1.0 Printer operations are:
+
+     Print-Job (section 3.2.1)
+     Print-URI (section 3.2.2)
+     Validate-Job (section 3.2.3)
+     Create-Job (section 3.2.4)
+     Get-Printer-Attributes (section 3.2.5)
+     Get-Jobs (section 3.2.6)
+
+   The Job operations are:
+
+     Send-Document (section 3.3.1)
+     Send-URI (section 3.3.2)
+     Cancel-Job (section 3.3.3)
+     Get-Job-Attributes (section 3.3.4)
+
+   The Send-Document and Send-URI Job operations are used to add a new
+   document to an existing multi-document Job object created using the
+   Create-Job operation.
+
+3.1 Common Semantics
+
+   All IPP operations require some common parameters and operation
+   attributes.  These common elements and their semantic characteristics
+   are defined and described in more detail in the following sections.
+
+3.1.1 Required Parameters
+
+   Every operation request contains the following REQUIRED parameters:
+
+     - a "version-number",
+     - an "operation-id",
+     - a "request-id", and
+     - the attributes that are REQUIRED for that type of request.
+
+   Every operation response contains the following REQUIRED parameters:
+
+     - a "version-number",
+     - a "status-code",
+     - the "request-id" that was supplied in the corresponding request,
+        and
+     - the attributes that are REQUIRED for that type of response.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 19]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   The encoding and transport document [RFC2565] defines special rules
+   for the encoding of these parameters.  All other operation elements
+   are represented using the more generic encoding rules for attributes
+   and groups of attributes.
+
+3.1.2 Operation IDs and Request IDs
+
+   Each IPP operation request includes an identifying "operation-id"
+   value.  Valid values are defined in the "operations-supported"
+   Printer attribute section (see section 4.4.13).  The client specifies
+   which operation is being requested by supplying the correct
+   "operation-id" value.
+
+   In addition, every invocation of an operation is identified by a
+   "request-id" value. For each request, the client chooses the
+   "request-id" which MUST be an integer (possibly unique depending on
+   client requirements) in the range from 1 to 2**31 - 1 (inclusive).
+   This "request-id" allows clients to manage multiple outstanding
+   requests. The receiving IPP object copies all 32-bits of the client-
+   supplied "request-id" attribute into the response so that the client
+   can match the response with the correct outstanding request, even if
+   the "request-id" is out of range.  If the request is terminated
+   before the complete "request-id" is received, the IPP object rejects
+   the request and returns a response with a "request-id" of 0.
+
+   Note: In some cases, the transport protocol underneath IPP might be a
+   connection oriented protocol that would make it impossible for a
+   client to receive responses in any order other than the order in
+   which the corresponding requests were sent.  In such cases, the
+   "request-id" attribute would not be essential for correct protocol
+   operation.  However, in other mappings, the operation responses can
+   come back in any order.  In these cases, the "request-id" would be
+   essential.
+
+3.1.3 Attributes
+
+   Operation requests and responses are both composed of groups of
+   attributes and/or document data.  The attributes groups are:
+
+     - Operation Attributes: These attributes are passed in the
+       operation and affect the IPP object's behavior while processing
+       the operation request and may affect other attributes or groups
+       of attributes.  Some operation attributes describe the document
+       data associated with the print job and are associated with new
+       Job objects, however most operation attributes do not persist
+       beyond the life of the operation.  The description of each
+       operation attribute includes conformance statements indicating
+       which operation attributes are REQUIRED and which are OPTIONAL
+
+
+
+deBry, et al.                 Experimental                     [Page 20]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+       for an IPP object to support and which attributes a client MUST
+       supply in a request and an IPP object MUST supply in a response.
+     - Job Template Attributes: These attributes affect the processing
+       of a job.  A client OPTIONALLY supplies Job Template Attributes
+       in a create request, and the receiving object MUST be prepared to
+       receive all supported attributes.  The Job object can later be
+       queried to find out what Job Template attributes were originally
+       requested in the create request, and such attributes are returned
+       in the response as Job Object Attributes.  The Printer object can
+       be queried about its Job Template attributes to find out what
+       type of job processing capabilities are supported and/or what the
+       default job processing behaviors are, though such attributes are
+       returned in the response as Printer Object Attributes.  The
+       "ipp-attribute-fidelity" operation attribute affects processing
+       of all client-supplied Job Template attributes (see section 15
+       for a full description of "ipp-attribute-fidelity" and its
+       relationship to other attributes).
+     - Job Object Attributes: These attributes are returned in response
+       to a query operation directed at a Job object.
+     - Printer Object Attributes: These attributes are returned in
+       response to a query operation directed at a Printer object.
+     - Unsupported Attributes: In a create request, the client supplies
+       a set of Operation and Job Template attributes.  If any of these
+       attributes or their values is unsupported by the Printer object,
+       the Printer object returns the set of unsupported attributes in
+       the response.  Section 15 gives a full description of how Job
+       Template attributes supplied by the client in a create request
+       are processed by the Printer object and how unsupported
+       attributes are returned to the client.  Because of extensibility,
+       any IPP object might receive a request that contains new or
+       unknown attributes or values for which it has no support. In such
+       cases, the IPP object processes what it can and returns the
+       unsupported attributes in the response.
+
+   Later in this section, each operation is formally defined by
+   identifying the allowed and expected groups of attributes for each
+   request and response.  The model identifies a specific order for each
+   group in each request or response, but the attributes within each
+   group may be in any order, unless specified otherwise.
+
+   Each attribute specification includes the attribute's name followed
+   by the name of its attribute syntax(es) in parenthesizes.  In
+   addition, each 'integer' attribute is followed by the allowed range
+   in parentheses, (m:n), for values of that attribute.  Each 'text' or
+   'name' attribute is followed by the maximum size in octets in
+   parentheses, (size), for values of that attribute. For more details
+   on attribute syntax notation, see the descriptions of these
+   attributes syntaxes in section 4.1.
+
+
+
+deBry, et al.                 Experimental                     [Page 21]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Note: Document data included in the operation is not strictly an
+   attribute, but it is treated as a special attribute group for
+   ordering purposes.  The only operations that support supplying the
+   document data within an operation request are Print-Job and Send-
+   Document.  There are no operation responses that include document
+   data.
+
+   Note: Some operations are REQUIRED for IPP objects to support; the
+   others are OPTIONAL (see section 5.2.2).  Therefore, before using an
+   OPTIONAL operation, a client SHOULD first use the REQUIRED Get-
+   Printer-Attributes operation to query the Printer's "operations-
+   supported" attribute in order to determine which OPTIONAL Printer and
+   Job operations are actually supported.  The client SHOULD NOT use an
+   OPTIONAL operation that is not supported.  When an IPP object
+   receives a request to perform an operation it does not support, it
+   returns the 'server-error-operation-not-supported' status code (see
+   section 13.1.5.2).  An IPP object is non-conformant if it does not
+   support a REQUIRED operation.
+
+3.1.4 Character Set and Natural Language Operation Attributes
+
+   Some Job and Printer attributes have values that are text strings and
+   names intended for human understanding rather than machine
+   understanding (see the 'text' and 'name' attribute syntax
+   descriptions in section 4.1).  The following sections describe two
+   special Operation Attributes called "attributes-charset" and
+   "attributes-natural-language".  These attributes are always part of
+   the Operation Attributes group.  For most attribute groups, the order
+   of the attributes within the group is not important.  However, for
+   these two attributes within the Operation Attributes group, the order
+   is critical.  The "attributes-charset" attribute MUST be the first
+   attribute in the group and the "attributes-natural-language"
+   attribute MUST be the second attribute in the group.  In other words,
+   these attributes MUST be supplied in every IPP request and response,
+   they MUST come first in the group, and MUST come in the specified
+   order.  For job creation operations, the IPP Printer implementation
+   saves these two attributes with the new Job object as Job Description
+   attributes.  For the sake of brevity in this document, these
+   operation attribute descriptions are not repeated with every
+   operation request and response, but have a reference back to this
+   section instead.
+
+3.1.4.1 Request Operation Attributes
+
+   The client MUST supply and the Printer object MUST support the
+   following REQUIRED operation attributes in every IPP/1.0 operation
+   request:
+
+
+
+
+deBry, et al.                 Experimental                     [Page 22]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     "attributes-charset" (charset):
+        This operation attribute identifies the charset (coded character
+        set and encoding method) used by any 'text' and 'name'
+        attributes that the client is supplying in this request.  It
+        also identifies the charset that the Printer object MUST use (if
+        supported) for all 'text' and 'name' attributes and status
+        messages that the Printer object returns in the response to this
+        request. See Sections 4.1.1 and 4.1.2 for the specification of
+        the 'text' and 'name' attribute syntaxes.
+
+        All clients and IPP objects MUST support the 'utf-8' charset
+        [RFC2279] and MAY support additional charsets provided that they
+        are registered with IANA [IANA-CS].  If the Printer object does
+        not support the client supplied charset value, the Printer
+        object MUST reject the request, set the "attributes-charset" to
+        'utf-8' in the response, and return the 'client-error-charset-
+        not-supported' status code and any 'text' or 'name' attributes
+        using the 'utf-8' charset.  The Printer object MUST indicate the
+        charset(s) supported as the values of the "charset-supported"
+        Printer attribute (see Section 4.4.15), so that the client can
+        query to determine which charset(s) are supported.
+
+        Note to client implementers: Since IPP objects are only required
+        to support the 'utf-8' charset, in order to maximize
+        interoperability with multiple IPP object implementations, a
+        client may want to supply 'utf-8' in the "attributes-charset"
+        operation attribute, even though the client is only passing and
+        able to present a simpler charset, such as US-ASCII or ISO-
+        8859-1.  Then the client will have to filter out (or charset
+        convert) those characters that are returned in the response that
+        it cannot present to its user.  On the other hand, if both the
+        client and the IPP objects also support a charset in common
+        besides utf-8, the client may want to use that charset in order
+        to avoid charset conversion or data loss.
+
+        See the 'charset' attribute syntax description in Section 4.1.7
+        for the syntax and semantic interpretation of the values of this
+        attribute and for example values.
+
+     "attributes-natural-language" (naturalLanguage):
+        This operation attribute identifies the natural language used by
+        any 'text' and 'name' attributes that the client is supplying in
+        this request.  This attribute also identifies the natural
+        language that the Printer object SHOULD use for all 'text' and '
+        name' attributes and status messages that the Printer object
+        returns in the response to this request.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 23]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        There are no REQUIRED natural languages required for the Printer
+        object to support.  However, the Printer object's "generated-
+        natural-language-supported" attribute identifies the natural
+        languages supported by the Printer object and any contained Job
+        objects for all text strings generated by the IPP object.  A
+        client MAY query this attribute to determine which natural
+        language(s) are supported for generated messages.
+
+        For any of the attributes for which the Printer object generates
+        text, i.e., for the "job-state-message", "printer-state-
+        message", and status messages (see Section 3.1.6), the Printer
+        object MUST be able to generate these text strings in any of its
+        supported natural languages.  If the client requests a natural
+        language that is not supported, the Printer object MUST return
+        these generated messages in the Printer's configured natural
+        language as specified by the Printer's "natural-language-
+        configured" attribute" (see Section 4.4.16).
+
+        For other 'text' and 'name' attributes supplied by the client,
+        authentication system, operator, system administrator, or
+        manufacturer (i.e., for "job-originating-user-name", "printer-
+        name" (name), "printer-location" (text), "printer-info" (text),
+        and "printer-make-and-model" (text)), the Printer object is only
+        required to support the configured natural language of the
+        Printer identified by the Printer object's "natural-language-
+        configured" attribute, though support of additional natural
+        languages for these attributes is permitted.
+
+        For any 'text' or 'name' attribute in the request that is in a
+        different natural language than the value supplied in the
+        "attributes-natural-language" operation attribute, the client
+        MUST use the Natural Language Override mechanism (see sections
+        4.1.1.2 and 4.1.2.2) for each such attribute value supplied.
+        The client MAY use the Natural Language Override mechanism
+        redundantly, i.e., use it even when the value is in the same
+        natural language as the value supplied in the "attributes-
+        natural-language" operation attribute of the request.
+
+        The IPP object MUST accept any natural language and any Natural
+        Language Override, whether the IPP object supports that natural
+        language or not (and independent of the value of the "ipp-
+        attribute-fidelity" Operation attribute).  That is the IPP
+        object accepts all client supplied values no matter what the
+        values are in the Printer object's "generated-natural-language-
+        supported" attribute.  That attribute, "generated-natural-
+        language-supported", only applies to generated messages,
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 24]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        not client supplied messages.  The IPP object MUST remember that
+        natural language for all client-supplied attributes, and when
+        returning those attributes in response to a query, the IPP
+        object MUST indicate that natural language.
+
+        Each value whose attribute syntax type is 'text' or 'name' (see
+        sections 4.1.1 and 4.1.2) has an Associated Natural-Language.
+        This document does not specify how this association is stored in
+        a Printer or Job object.  When such a value is encoded in a
+        request or response, the natural language is either implicit or
+        explicit:
+
+             - In the implicit case, the value contains only the
+               text/name value, and the language is specified by the
+               "attributes-natural-language" operation attribute in the
+               request or response (see sections 4.1.1.1
+               textWithoutLanguage and 4.1.2.1 nameWithoutLanguage).
+
+             - In the explicit case (also known as the Natural-Language
+               Override case), the value contains both the language and
+               the text/name value (see sections 4.1.1.2
+               textWithLanguage and 4.1.2.2 nameWithLanguage).
+
+        For example, the "job-name" attribute MAY be supplied by the
+        client in a create request.  The text value for this attribute
+        will be in the natural language identified by the "attribute-
+        natural-language" attribute, or if different, as identified by
+        the Natural Language Override mechanism.  If supplied, the IPP
+        object will use the value of the "job-name" attribute to
+        populate the Job object's "job-name" attribute.  Whenever any
+        client queries the Job object's "job-name" attribute, the IPP
+        object returns the attribute as stored and uses the Natural
+        Language Override mechanism to specify the natural language, if
+        it is different from that reported in the "attributes-natural-
+        language" operation attribute of the response.  The IPP object
+        MAY use the Natural Language Override mechanism redundantly,
+        i.e., use it even when the value is in the same natural language
+        as the value supplied in the "attributes-natural-language"
+        operation attribute of the response.
+
+        An IPP object MUST NOT reject a request based on a supplied
+        natural language in an "attributes-natural-language" Operation
+        attribute or in any attribute that uses the Natural Language
+        Override.
+
+        See the 'naturalLanguage' attribute syntax description in
+        section 4.1.8 for the syntax and semantic interpretation of the
+        values of this attribute and for example values.
+
+
+
+deBry, et al.                 Experimental                     [Page 25]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Clients SHOULD NOT supply 'text' or 'name' attributes that use an
+   illegal combination of natural language and charset.  For example,
+   suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and
+   'iso-8859-7'.  Suppose also, that it supports natural languages 'en'
+   (English), 'fr' (French), and 'el' (Greek).  Although the Printer
+   object supports the charset 'iso-8859-1' and natural language 'el',
+   it probably does not support the combination of Greek text strings
+   using the 'iso-8859-1' charset.  The Printer object handles this
+   apparent incompatibility differently depending on the context in
+   which it occurs:
+
+     - In a create request: If the client supplies a text or name
+       attribute (for example, the "job-name" operation attribute) that
+       uses an apparently incompatible combination, it is a client
+       choice that does not affect the Printer object or its correct
+       operation.  Therefore, the Printer object simply accepts the
+       client supplied value, stores it with the Job object, and
+       responds back with the same combination whenever the client (or
+       any client) queries for that attribute.
+     - In a query-type operation, like Get-Printer-Attributes: If the
+       client requests an apparently incompatible combination, the
+       Printer object responds (as described in section 3.1.4.2) using
+       the Printer's configured natural language rather than the natural
+       language requested by the client.
+
+   In either case, the Printer object does not reject the request
+   because of the apparent incompatibility.  The potential incompatible
+   combination of charset and natural language can occur either at the
+   global operation level or at the Natural Language Override
+   attribute-by-attribute level.  In addition, since the response always
+   includes explicit charset and natural language information, there is
+   never any question or ambiguity in how the client interprets the
+   response.
+
+3.1.4.2 Response Operation Attributes
+
+   The Printer object MUST supply and the client MUST support the
+   following REQUIRED operation attributes in every IPP/1.0 operation
+   response:
+
+     "attributes-charset" (charset):
+        This operation attribute identifies the charset used by any '
+        text' and 'name' attributes that the Printer object is returning
+        in this response.  The value in this response MUST be the same
+        value as the "attributes-charset" operation attribute supplied
+        by the client in the request.  If this is not possible
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 26]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        (i.e., the charset requested is not supported), the request
+        would have been rejected.  See "attributes-charset" described in
+        Section 3.1.4.1 above.
+
+        If the Printer object supports more than just the 'utf-8'
+        charset, the Printer object MUST be able to code convert between
+        each of the charsets supported on a highest fidelity possible
+        basis in order to return the 'text' and 'name' attributes in the
+        charset requested by the client.  However, some information loss
+        MAY occur during the charset conversion depending on the
+        charsets involved.  For example, the Printer object may convert
+        from a UTF-8 'a' to a US-ASCII 'a' (with no loss of
+        information), from an ISO Latin 1 CAPITAL LETTER A WITH ACUTE
+        ACCENT to US-ASCII 'A' (losing the accent), or from a UTF-8
+        Japanese Kanji character to some ISO Latin 1 error character
+        indication such as '?', decimal code equivalent, or to the
+        absence of a character, depending on implementation.
+
+        Note: Whether an implementation that supports more than one
+        charset stores the data in the charset supplied by the client or
+        code converts to one of the other supported charsets, depends on
+        implementation.  The strategy should try to minimize loss of
+        information during code conversion.  On each response, such an
+        implementation converts from its internal charset to that
+        requested.
+
+     "attributes-natural-language" (naturalLanguage):
+        This operation attribute identifies the natural language used by
+        any 'text' and 'name' attributes that the IPP object is
+        returning in this response.  Unlike the "attributes-charset"
+        operation attribute, the IPP object NEED NOT return the same
+        value as that supplied by the client in the request.  The IPP
+        object MAY return the natural language of the Job object or the
+        Printer's configured natural language as identified by the
+        Printer object's "natural-language-configured" attribute, rather
+        than the natural language supplied by the client.  For any '
+        text' or 'name' attribute or status message in the response that
+        is in a different natural language than the value returned in
+        the "attributes-natural-language" operation attribute, the IPP
+        object MUST use the Natural Language Override mechanism (see
+        sections 4.1.1.2 and 4.1.2.2) on each attribute value returned.
+        The IPP object MAY use the Natural Language Override mechanism
+        redundantly, i.e., use it even when the value is in the same
+        natural language as the value supplied in the "attributes-
+        natural-language" operation attribute of the response.
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 27]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+3.1.5 Operation Targets
+
+   All IPP operations are directed at IPP objects.  For Printer
+   operations, the operation is always directed at a Printer object
+   using one of its URIs (i.e., one of the values in the Printer
+   object's "printer-uri-supported" attribute).  Even if the Printer
+   object supports more than one URI, the client supplies only one URI
+   as the target of the operation.  The client identifies the target
+   object by supplying the correct URI in the "printer-uri (uri)"
+   operation attribute.
+
+   For Job operations, the operation is directed at either:
+
+     - The Job object itself using the Job object's URI.  In this case,
+       the client identifies the target object by supplying the correct
+       URI in the "job-uri (uri)" operation attribute.
+     - The Printer object that created the Job object using both the
+       Printer objects URI and the Job object's Job ID.  Since the
+       Printer object that created the Job object generated the Job ID,
+       it MUST be able to correctly associate the client supplied Job ID
+       with the correct Job object.  The client supplies the Printer
+       object's URI in the "printer-uri (uri)" operation attribute and
+       the Job object's Job ID in the "job-id (integer(1:MAX))"
+       operation attribute.
+
+   If the operation is directed at the Job object directly using the Job
+   object's URI, the client MUST NOT include the redundant "job-id"
+   operation attribute.
+
+   The operation target attributes are REQUIRED operation attributes
+   that MUST be included in every operation request.  Like the charset
+   and natural language attributes (see section 3.1.4), the operation
+   target attributes are specially ordered operation attributes.  In all
+   cases, the operation target attributes immediately follow the
+   "attributes-charset" and "attributes-natural-language" attributes
+   within the operation attribute group, however the specific ordering
+   rules are:
+
+     - In the case where there is only one operation target attribute
+       (i.e., either only the "printer-uri" attribute or only the "job-
+       uri" attribute), that attribute MUST be the third attribute in
+       the operation attributes group.
+     - In the case where Job operations use two operation target
+       attributes (i.e., the "printer-uri" and "job-id" attributes), the
+       "printer-uri" attribute MUST be the third attribute and the
+       "job-id" attribute MUST be the fourth attribute.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 28]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   In all cases, the target URIs contained within the body of IPP
+   operation requests and responses must be in absolute format rather
+   than relative format (a relative URL identifies a resource with the
+   scope of the HTTP server, but does not include scheme, host or port).
+
+   The following rules apply to the use of port numbers in URIs that
+   identify IPP objects:
+
+     1. If the URI scheme allows the port number to be explicitly
+        included in the URI string, and a port number is specified
+        within the URI, then that port number MUST be used by the client
+        to contact the IPP object.
+
+     2. If the URI scheme allows the port number to be explicitly
+        included in the URI string, and a port number is not specified
+        within the URI, then default port number implied by that URI
+        scheme MUST be used by the client to contact the IPP object.
+
+     3. If the URI scheme does not allow an explicit port number to be
+        specified within the URI, then the default port number implied
+        by that URI MUST be used by the client to contact the IPP
+        object.
+
+   Note: The IPP encoding and transport document [RFC2565] shows a
+   mapping of IPP onto HTTP/1.1 and defines a new default port number
+   for using IPP over HTTP/1.1.
+
+3.1.6 Operation Status Codes and Messages
+
+   Every operation response includes a REQUIRED "status-code" parameter
+   and an OPTIONAL "status-message" operation attribute.  The "status-
+   code" provides information on the processing of a request.  A
+   "status-message" attribute provides a short textual description of
+   the status of the operation.  The status code is intended for use by
+   automata, and the status message is intended for the human end user.
+   If a response does include a "status-message" attribute, an IPP
+   client NEED NOT examine or display the message, however it SHOULD do
+   so in some implementation specific manner.
+
+   The "status-code" value is a numeric value that has semantic meaning.
+   The "status-code" syntax is similar to a "type2 enum" (see section
+   4.1 on "Attribute Syntaxes") except that values can range only from
+   0x0000 to 0x7FFF.  Section 13 describes the status codes, assigns the
+   numeric values, and suggests a corresponding status message for each
+   status code.  The "status-message" attribute's syntax is "text(255)".
+   A client implementation of IPP SHOULD convert status code values into
+   any localized message that has semantic meaning to the end user.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 29]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   If the Printer object supports the "status-message" operation
+   attribute, the Printer object MUST be able to generate this message
+   in any of the natural languages identified by the Printer object's
+   "generated-natural-language-supported" attribute (see the
+   "attributes-natural-language" operation attribute specified in
+   section 3.1.4.1).  As described in section 3.1.4.1 for any returned '
+   text' attribute, if there is a choice for generating this message,
+   the Printer object uses the natural language indicated by the value
+   of the "attributes-natural-language" in the client request if
+   supported, otherwise the Printer object uses the value in the Printer
+   object's own "natural-language-configured" attribute.  If the Printer
+   object supports the "status-message" operation attribute, it SHOULD
+   use the REQUIRED 'utf-8' charset to return a status message for the
+   following error status codes (see section 13): 'client-error-bad-
+   request', 'client-error-charset-not-supported', 'server-error-
+   internal-error', 'server-error-operation-not-supported', and '
+   server-error-version-not-supported'.  In this case, it MUST set the
+   value of the "attributes-charset" operation attribute to 'utf-8' in
+   the error response.
+
+3.1.7 Versions
+
+   Each operation request and response carries with it a "version-
+   number" parameter.  Each value of the "version-number" is in the form
+   "X.Y" where X is the major version number and Y is the minor version
+   number.  By including a version number in the client request, it
+   allows the client  to identify which version of IPP it is interested
+   in using.  If the IPP object does not support that version, the
+   object responds with a status code of 'server-error-version-not-
+   supported' along with the closest version number that is supported
+   (see section 13.1.5.4).
+
+   There is no version negotiation per se.  However, if after receiving
+   a 'server-error-version-not-supported' status code from an IPP
+   object, there is nothing that prevents a client from trying again
+   with a different version number. In order to conform to IPP/1.0, an
+   implementation MUST support at least version '1.0'.
+
+   There is only one notion of "version number" that covers both IPP
+   Model and IPP Protocol changes. Thus the version number MUST change
+   when introducing a new version of the Model and Semantics document
+   [RFC2566] or a new version of the Encoding and Transport document
+   [RFC2565].
+
+   Changes to the major version number indicate structural or syntactic
+   changes that make it impossible for older version of IPP clients and
+   Printer objects to correctly parse and process the new or changed
+   attributes, operations and responses.  If the major version number
+
+
+
+deBry, et al.                 Experimental                     [Page 30]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   changes, the minor version numbers is set to zero.  As an example,
+   adding the "ipp-attribute-fidelity" attribute (if it had not been
+   part of version '1.0'), would have required a change to the major
+   version number.  Items that might affect the changing of the major
+   version number include any changes to the Model and Semantics
+   document [RFC2566] or the Encoding and Transport [RFC2565] itself,
+   such as:
+
+     - reordering of ordered attributes or attribute sets
+     - changes to the syntax of existing attributes
+     - changing Operation or Job Template attributes from OPTIONAL to
+       REQUIRED and vice versa
+     - adding REQUIRED (for an IPP object to support) operation
+       attributes
+     - adding REQUIRED (for an IPP object to support) operation
+       attribute groups
+     - adding values to existing operation attributes
+     - adding REQUIRED operations
+
+   Changes to the minor version number indicate the addition of new
+   features, attributes and attribute values that may not be understood
+   by all IPP objects, but which can be ignored if not understood.
+   Items that might affect the changing of the minor version number
+   include any changes to the model objects and attributes but not the
+   encoding and transport rules [RFC2565] (except adding attribute
+   syntaxes).  Examples of such changes are:
+
+     - grouping all extensions not included in a previous version into
+       a new version
+     - adding new attribute values
+     - adding new object attributes
+     - adding OPTIONAL (for an IPP object to support) operation
+       attributes (i.e., those attributes that an IPP object can ignore
+       without confusing clients)
+     - adding OPTIONAL (for an IPP object to support) operation
+       attribute groups (i.e., those attributes that an IPP object can
+       ignore without confusing clients)
+     - adding new attribute syntaxes
+     - adding OPTIONAL operations
+     - changing Job Description attributes or Printer Description
+       attributes from OPTIONAL to REQUIRED or vice versa.
+
+   The encoding of the "operation-id", the "version-number", the
+   "status-code", and the "request-id" MUST NOT change over any version
+   number (either major or minor).  This rule guarantees that all future
+   versions will be backwards compatible with all previous versions (at
+   least for checking the "operation-id", the "version-number", and the
+   "request-id").  In addition, any protocol elements (attributes, error
+
+
+
+deBry, et al.                 Experimental                     [Page 31]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   codes, tags, etc.) that are not carried forward from one version to
+   the next are deprecated so that they can never be reused with new
+   semantics.
+
+   Implementations that support a certain major version NEED NOT support
+   ALL previous versions.  As each new major version is defined (through
+   the release of a new specification), that major version will specify
+   which previous major versions MUST be supported in compliant
+   implementations.
+
+3.1.8 Job Creation Operations
+
+   In order to "submit a print job" and create a new Job object, a
+   client issues a create request.  A create request is any one of
+   following three operation requests:
+
+     - The Print-Job Request: A client that wants to submit a print job
+       with only a single document uses the Print-Job operation.  The
+       operation allows for the client to "push" the document data to
+       the Printer object by including the document data in the request
+       itself.
+
+     - The Print-URI Request: A client that wants to submit a print job
+       with only a single document (where the Printer object "pulls" the
+       document data instead of the client "pushing" the data to the
+       Printer object) uses the Print-URI operation.   In this case, the
+       client includes in the request only a URI reference to the
+       document data (not the document data itself).
+
+     - The Create-Job Request: A client that wants to submit a print job
+       with multiple documents uses the Create-Job operation.  This
+       operation is followed by an arbitrary number of Send-Document
+       and/or Send-URI operations (each creating another document for
+       the newly create Job object).  The Send-Document operation
+       includes the document data in the request (the client "pushes"
+       the document data to the printer), and the Send-URI operation
+       includes only a URI reference to the document data in the request
+       (the Printer "pulls" the document data from the referenced
+       location).  The last Send-Document or Send-URI request for a
+       given Job object includes a "last-document" operation attribute
+       set to 'true' indicating that this is the last request.
+
+   Throughout this model specification, the term "create request" is
+   used to refer to any of these three operation requests.
+
+   A Create-Job operation followed by only one Send-Document operation
+   is semantically equivalent to a Print-Job operation, however, for
+   performance reasons, the client SHOULD use the Print-Job operation
+
+
+
+deBry, et al.                 Experimental                     [Page 32]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   for all single document jobs.  Also, Print-Job is a REQUIRED
+   operation (all implementations MUST support it) whereas Create-Job is
+   an OPTIONAL operation, hence some implementations might not support
+   it.
+
+   Job submission time is the point in time when a client issues a
+   create request.  The initial state of every Job object is the '
+   pending' or 'pending-held' state.  Later, the Printer object begins
+   processing the print job.  At this point in time, the Job object's
+   state moves to 'processing'.  This is known as job processing time.
+   There are validation checks that must be done at job submission time
+   and others that must be performed at job processing time.
+
+   At job submission time and at the time a Validate-Job operation is
+   received, the Printer MUST do the following:
+
+     1. Process the client supplied attributes and either accept or
+        reject the request
+     2. Validate the syntax of and support for the scheme of any client
+        supplied URI
+
+   At job submission time the Printer object MUST validate whether or
+   not the supplied attributes, attribute syntaxes, and values are
+   supported by matching them with the Printer object's corresponding
+   "xxx-supported" attributes.  See section 3.2.1.2 for details.  [ipp-
+   iig] presents suggested steps for an IPP object to either accept or
+   reject any request and additional steps for processing create
+   requests.
+
+   At job submission time the Printer object NEED NOT perform the
+   validation checks reserved for job processing time such as:
+
+     1. Validating the document data
+     2. Validating the actual contents of any client supplied URI
+        (resolve the reference and follow the link to the document data)
+
+   At job submission time, these additional job processing time
+   validation checks are essentially useless, since they require
+   actually parsing and interpreting the document data, are not
+   guaranteed to be 100% accurate, and MUST be done, yet again, at job
+   processing time.  Also, in the case of a URI, checking for
+   availability at job submission time does not guarantee availability
+   at job processing time.   In addition, at job processing time, the
+   Printer object might discover any of the following conditions that
+   were not detectable at job submission time:
+
+     - runtime errors in the document data,
+     - nested document data that is in an unsupported format,
+
+
+
+deBry, et al.                 Experimental                     [Page 33]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     - the URI reference is no longer valid (i.e., the server hosting
+       the document might be down), or
+     - any other job processing error
+
+   At job processing time, since the Printer object has already
+   responded with a successful status code in the response to the create
+   request, if the Printer object detects an error, the Printer object
+   is unable to inform the end user of the error with an operation
+   status code.   In this case, the Printer, depending on the error, can
+   set the "job-state", "job-state-reasons", or "job-state-message"
+   attributes to the appropriate value(s) so that later queries can
+   report the correct job status.
+
+   Note: Asynchronous notification of events is outside the scope of
+   IPP/1.0.
+
+3.2 Printer Operations
+
+   All Printer operations are directed at Printer objects.  A client
+   MUST always supply the "printer-uri" operation attribute in order to
+   identify the correct target of the operation.
+
+3.2.1 Print-Job Operation
+
+   This REQUIRED operation allows a client to submit a print job with
+   only one document and supply the document data (rather than just a
+   reference to the data).  See Section 15 for the suggested steps for
+   processing create operations and their Operation and Job Template
+   attributes.
+
+3.2.1.1 Print-Job Request
+
+   The following groups of attributes are supplied as part of the
+   Print-Job Request:
+
+   Group 1: Operation Attributes
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.  The Printer object
+        MUST copy these values to the corresponding Job Description
+        attributes described in sections 4.3.23 and 4.3.24.
+
+     Target:
+        The "printer-uri" (uri) operation attribute which is the target
+        for this operation as described in section 3.1.5.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 34]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+     "job-name" (name(MAX)):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  It contains the client
+        supplied Job name.  If this attribute is supplied by the client,
+        its value is used for the "job-name" attribute of the newly
+        created Job object.  The client MAY automatically include any
+        information that will help the end-user distinguish amongst
+        his/her jobs, such as the name of the application program along
+        with information from the document, such as the document name,
+        document subject, or source file name.  If this attribute is not
+        supplied by the client, the Printer generates a name to use in
+        the "job-name" attribute of the newly created Job object (see
+        Section 4.3.5).
+
+     "ipp-attribute-fidelity" (boolean):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  The value 'true' indicates
+        that total fidelity to client supplied Job Template attributes
+        and values is required, else the Printer object MUST reject the
+        Print-Job request.  The value 'false' indicates that a
+        reasonable attempt to print the Job object is acceptable and the
+        Printer object MUST accept the Print-job request. If not
+        supplied, the Printer object assumes the value is 'false'.  All
+        Printer objects MUST support both types of job processing.  See
+        section 15 for a full description of "ipp-attribute-fidelity"
+        and its relationship to other attributes, especially the Printer
+        object's "pdl-override-supported" attribute.
+
+     "document-name" (name(MAX)):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.   It contains the client
+        supplied document name.  The document name MAY be different than
+        the Job name.  Typically, the client software automatically
+        supplies the document name on behalf of the end user by using a
+        file name or an application generated name.  If this attribute
+        is supplied, its value can be used in a manner defined by each
+        implementation.  Examples include: printed along with the Job
+        (job start sheet, page adornments, etc.), used by accounting or
+        resource tracking management tools, or even stored along with
+        the document as a document level attribute.  IPP/1.0 does not
+        support the concept of document level attributes.
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 35]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     "document-format" (mimeMediaType) :
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  The value of this attribute
+        identifies the format of the supplied document data.  If the
+        client does not supply this attribute, the Printer object
+        assumes that the document data is in the format defined by the
+        Printer object's "document-format-default" attribute.  If the
+        client supplies this attribute, but the value is not supported
+        by the Printer object, i.e., the value is not one of the values
+        of the Printer object's "document-format-supported" attribute,
+        the Printer object MUST reject the request and return the '
+        client-error-document-format-not-supported' status code.
+
+     "document-natural-language" (naturalLanguage):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute. This attribute
+        specifies the natural language of the document for those
+        document-formats that require a specification of the natural
+        language in order to image the document unambiguously. There are
+        no particular values required for the Printer object to support.
+
+     "compression" (type3 keyword)
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute and the "compression-
+        supported" attribute (see section 4.4.29).  The client supplied
+        "compression" operation attribute identifies the compression
+        algorithm used on the document data.  If the client omits this
+        attribute, the Printer object MUST assume that the data is not
+        compressed.  If the client supplies the attribute and the
+        Printer object supports the attribute, the Printer object uses
+        the corresponding decompression algorithm on the document data.
+        If the client supplies this attribute, but the value is not
+        supported by the Printer object, i.e., the value is not one of
+        the values of the Printer object's "compression-supported"
+        attribute, the Printer object MUST copy the attribute and its
+        value to the Unsupported Attributes response group, reject the
+        request, and return the 'client-error-attributes-or-values-not-
+        supported' status code.
+
+     "job-k-octets" (integer(0:MAX))
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute and the "job-k-
+        octets-supported" attribute (see section 4.4.30).  The client
+        supplied "job-k-octets" operation attribute identifies the total
+        size of the document(s) in K octets being submitted (see section
+        4.3.17 for the complete semantics).  If the client supplies the
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 36]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        attribute and the Printer object supports the attribute, the
+        value of the attribute is used to populate the Job object's
+        "job-k-octets" Job Description attribute.
+
+        Note: For this attribute and the following two attributes
+        ("job-impressions", and "job-media-sheets"), if the client
+        supplies the attribute, but the Printer object does not support
+        the attribute, the Printer object ignores the client-supplied
+        value.  If the client supplies the attribute and the Printer
+        supports the attribute, and the value is within the range of the
+        corresponding Printer object's "xxx-supported" attribute, the
+        Printer object MUST use the value to populate the Job object's
+        "xxx" attribute.  If the client supplies the attribute and the
+        Printer supports the attribute, but the value is outside the
+        range of the corresponding Printer object's "xxx-supported"
+        attribute, the Printer object MUST copy the attribute and its
+        value to the Unsupported Attributes response group, reject the
+        request, and return the 'client-error-attributes-or-values-not-
+        supported' status code.  If the client does not supply the
+        attribute, the Printer object MAY choose to populate the
+        corresponding Job object attribute depending on whether the
+        Printer object supports the attribute and is able to calculate
+        or discern the correct value.
+
+     "job-impressions" (integer(0:MAX))
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute and the "job-
+        impressions-supported" attribute (see section 4.4.31).  The
+        client supplied "job-impressions" operation attribute identifies
+        the total size in number of impressions of the document(s) being
+        submitted (see section 4.3.18 for the complete semantics).
+
+        See note under "job-k-octets".
+
+     "job-media-sheets" (integer(0:MAX))
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute and the "job-media-
+        sheets-supported" attribute (see section 4.4.32).  The client
+        supplied "job-media-sheets" operation attribute identifies the
+        total number of media sheets to be produced for this job (see
+        section 4.3.19 for the complete semantics).
+
+        See note under "job-k-octets".
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 37]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Group 2: Job Template Attributes
+
+        The client OPTIONALLY supplies a set of Job Template attributes
+        as defined in section 4.2.  If the client is not supplying any
+        Job Template attributes in the request, the client SHOULD omit
+        Group 2 rather than sending an empty group.  However, a Printer
+        object MUST be able to accept an empty group.
+
+   Group 3: Document Content
+
+        The client MUST supply the document data to be processed.
+
+   Note: In addition to the MANDATORY parameters required for every
+   operation request, the simplest Print-Job Request consists of just
+   the "attributes-charset" and "attributes-natural-language" operation
+   attributes; the "printer-uri" target operation attribute; the
+   Document Content and nothing else.  In this simple case, the Printer
+   object:
+
+     - creates a new Job object (the Job object contains a single
+       document),
+     - stores a generated Job name in the "job-name" attribute in the
+       natural language and charset requested (see Section 3.1.4.1) (if
+       those are supported, otherwise using the Printer object's default
+       natural language and charset), and
+     - at job processing time, uses its corresponding default value
+       attributes for the supported Job Template attributes that were
+       not supplied by the client as IPP attribute or embedded
+       instructions in the document data.
+
+3.2.1.2 Print-Job Response
+
+       The Printer object MUST return to the client the following sets
+       of attributes as part of the Print-Job Response:
+
+       Group 1: Operation Attributes
+
+     Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text) operation attribute as described in sections 14 and
+        3.1.6.  If the client supplies unsupported or conflicting Job
+        Template attributes or values, the Printer object MUST reject or
+        accept the Print-Job request depending on the whether the client
+        supplied a 'true' or 'false' value for the "ipp-attribute-
+        fidelity" operation attribute.  See the Implementer's Guide
+        [ipp-iig] for a complete description of the suggested steps for
+        processing a create request.
+
+
+
+deBry, et al.                 Experimental                     [Page 38]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+        This is a set of Operation and Job Template attributes supplied
+        by the client (in the request) that are not supported by the
+        Printer object or that conflict with one another (see the
+        Implementer's Guide [ipp-iig]).  If the Printer object is not
+        returning any Unsupported Attributes in the response, the
+        Printer object SHOULD omit Group 2 rather than sending an empty
+        group.  However, a client MUST be able to accept an empty group.
+
+        Unsupported attributes fall into three categories:
+
+        1. The Printer object does not support the supplied attribute
+           (no matter what the attribute syntax or value).
+        2. The Printer object does support the attribute, but does not
+           support some or all of the particular attribute syntaxes or
+           values supplied by the client (i.e., the Printer object does
+           not have those attribute syntaxes or values in its
+           corresponding "xxx-supported" attribute).
+        3. The Printer object does support the attributes and values
+           supplied, but the particular values are in conflict with one
+           another, because they violate a constraint, such as not being
+           able to staple transparencies.
+
+        In the case of an unsupported attribute name, the Printer object
+        returns the client-supplied attribute with a substituted "out-
+        of-band" value of 'unsupported' indicating no support for the
+        attribute itself (see the beginning of section 4.1).
+
+        In the case of a supported attribute with one or more
+        unsupported attribute syntaxes or values, the Printer object
+        simply returns the client-supplied attribute with the
+        unsupported attribute syntaxes or values as supplied by the
+        client.  This indicates support for the attribute, but no
+        support for that particular attribute syntax or value.  If the
+        client supplies a multi-valued attribute with more than one
+        value and the Printer object supports the attribute but only
+        supports a subset of the client-supplied attribute syntaxes or
+        values, the Printer object MUST return only those attribute
+        syntaxes or values that are unsupported.
+
+        In the case of two (or more) supported attribute values that are
+        in conflict with one another (although each is supported
+        independently, the values conflict when requested together
+
+
+
+deBry, et al.                 Experimental                     [Page 39]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        within the same job), the Printer object MUST return all the
+        values that it ignores or substitutes to resolve the conflict,
+        but not any of the values that it is still using.  The choice
+        for exactly how to resolve the conflict is implementation
+        dependent.  See The Implementer's Guide [ipp-iig] for an
+        example.
+
+        In these three cases, the value of the "ipp-attribute-fidelity"
+        supplied by the client does not affect what the Printer object
+        returns.  The value of "ipp-attribute-fidelity" only affects
+        whether the Print-Job operation is accepted or rejected.  If the
+        job is accepted, the client may query the job using the Get-
+        Job-Attributes operation requesting the unsupported attributes
+        that were returned in the create response to see which
+        attributes were ignored (not stored on the Job object) and which
+        attributes were stored with other (substituted) values.
+
+   Group 3: Job Object Attributes
+
+     "job-uri" (uri):
+        The Printer object MUST return the Job object's URI by returning
+        the contents of the REQUIRED "job-uri" Job object attribute.
+        The client uses the Job object's URI when directing operations
+        at the Job object.  The Printer object always uses its
+        configured security policy when creating the new URI.  However,
+        if the Printer object supports more than one URI, the Printer
+        object also uses information about which URI was used in the
+        Print-Job Request to generated the new URI so that the new URI
+        references the correct access channel.  In other words, if the
+        Print-Job Request comes in over a secure channel, the Printer
+        object MUST generate a Job URI that uses the secure channel as
+        well.
+
+     "job-id" (integer(1:MAX)):
+        The Printer object MUST return the Job object's Job ID by
+        returning the REQUIRED "job-id" Job object attribute.  The
+        client uses this "job-id" attribute in conjunction with the
+        "printer-uri" attribute used in the Print-Job Request when
+        directing Job operations at the Printer object.
+
+     "job-state":
+        The Printer object MUST return the Job object's REQUIRED "job-
+        state" attribute. The value of this attribute (along with the
+        value of the next attribute "job-state-reasons") is taken from a
+        "snapshot" of the new Job object at some meaningful point in
+        time (implementation defined) between when the Printer object
+        receives the Print-Job Request and when the Printer object
+        returns the response.
+
+
+
+deBry, et al.                 Experimental                     [Page 40]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     "job-state-reasons":
+        The Printer object OPTIONALLY returns the Job object's OPTIONAL
+        "job-state-reasons" attribute.  If the Printer object supports
+        this attribute then it MUST be returned in the response.  If
+        this attribute is not returned in the response, the client can
+        assume that the "job-state-reasons" attribute is not supported
+        and will not be returned in a subsequent Job object query.
+
+     "job-state-message":
+        The Printer object OPTIONALLY returns the Job object's OPTIONAL
+        "job-state-message" attribute.  If the Printer object supports
+        this attribute then it MUST be returned in the response.  If
+        this attribute is not returned in the response, the client can
+        assume that the "job-state-message" attribute is not supported
+        and will not be returned in a subsequent Job object query.
+
+     "number-of-intervening-jobs":
+        The Printer object OPTIONALLY returns the Job object's OPTIONAL
+        "number-of-intervening-jobs" attribute.  If the Printer object
+        supports this attribute then it MUST be returned in the
+        response.  If this attribute is not returned in the response,
+        the client can assume that the "number-of-intervening-jobs"
+        attribute is not supported and will not be returned in a
+        subsequent Job object query.
+
+        Note: Since any printer state information which affects a job's
+        state is reflected in the "job-state" and "job-state-reasons"
+        attributes, it is sufficient to return only these attributes and
+        no specific printer status attributes.
+
+   Note: In addition to the MANDATORY parameters required for every
+   operation response, the simplest response consists of the just the
+   "attributes-charset" and "attributes-natural-language" operation
+   attributes and the "job-uri", "job-id", and "job-state" Job Object
+   Attributes.  In this simplest case, the status code is "successful-
+   ok" and there is no "status-message" operation attribute.
+
+3.2.2 Print-URI Operation
+
+   This OPTIONAL operation is identical to the Print-Job operation
+   (section 3.2.1) except that a client supplies a URI reference to the
+   document data using the "document-uri" (uri) operation attribute (in
+   Group 1) rather than including the document data itself.  Before
+   returning the response, the Printer MUST validate that the Printer
+   supports the retrieval method (e.g., http, ftp, etc.) implied by the
+   URI, and MUST check for valid URI syntax.  If the client-supplied URI
+   scheme is not supported, i.e. the value is not in the Printer
+   object's "referenced-uri-scheme-supported" attribute, the Printer
+
+
+
+deBry, et al.                 Experimental                     [Page 41]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   object MUST reject the request and return the 'client-error-uri-
+   scheme-not-supported' status code.  See The Implementer's Guide
+   [ipp-iig] for suggested additional checks.  The Printer NEED NOT
+   follow the reference and validate the contents of the reference.
+
+   If the Printer object supports this operation, it MUST support the
+   "reference-uri-schemes-supported" Printer attribute (see section
+   4.4.24).
+
+   It is up to the IPP object to interpret the URI and subsequently
+   "pull" the document from the source referenced by the URI string.
+
+3.2.3 Validate-Job Operation
+
+   This REQUIRED operation is similar to the Print-Job operation
+   (section 3.2.1) except that a client supplies no document data and
+   the Printer allocates no resources (i.e., it does not create a new
+   Job object).  This operation is used only to verify capabilities of a
+   printer object against whatever attributes are supplied by the client
+   in the Validate-Job request.  By using the Validate-Job operation a
+   client can validate that an identical Print-Job operation (with the
+   document data) would be accepted. The Validate-Job operation also
+   performs the same security negotiation as the Print-Job operation
+   (see section 8), so that a client can check that the client and
+   Printer object security requirements can be met before performing a
+   Print-Job operation.
+
+   Note: The Validate-Job operation does not accept a "document-uri"
+   attribute in order to allow a client to check that the same Print-URI
+   operation will be accepted, since the client doesn't send the data
+   with the Print-URI operation.  The client SHOULD just issue the
+   Print-URI request.
+
+   The Printer object returns the same status codes, Operation
+   Attributes (Group 1) and Unsupported Attributes (Group 2) as the
+   Print-Job operation.  However, no Job Object Attributes (Group 3) are
+   returned, since no Job object is created.
+
+3.2.4 Create-Job Operation
+
+   This OPTIONAL operation is similar to the Print-Job operation
+   (section 3.2.1) except that in the Create-Job request, a client does
+   not supply document data or any reference to document data.  Also,
+   the client does not supply any of the "document-name", "document-
+   format", "compression", or "document-natural-language" operation
+   attributes.  This operation is followed by one or more Send-Document
+   or Send-URI operations.  In each of those operation requests, the
+
+
+
+
+deBry, et al.                 Experimental                     [Page 42]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   client OPTIONALLY supplies the "document-name", "document-format",
+   and "document-natural-language" attributes for each document in the
+   multi-document Job object.
+
+   If a Printer object supports the Create-Job operation, it MUST also
+   support the Send-Document operation and also MAY support the Send-URI
+   operation.
+
+   If the Printer object supports this operation, it MUST support the
+   "multiple-operation-time-out" Printer attribute (see section 4.4.28).
+
+
+3.2.5 Get-Printer-Attributes Operation
+
+   This REQUIRED operation allows a client to request the values of the
+   attributes of a Printer object.   In the request, the client supplies
+   the set of Printer attribute names and/or attribute group names in
+   which the requester is interested.  In the response, the Printer
+   object returns a corresponding attribute set with the appropriate
+   attribute values filled in.
+
+   For Printer objects, the possible names of attribute groups are:
+
+     - 'job-template': all of the Job Template attributes that apply to
+       a Printer object (the last two columns of the table in Section
+       4.2).
+     - 'printer-description': the attributes specified in Section 4.4.
+     - 'all': the special group 'all' that includes all supported
+       attributes.
+
+   Since a client MAY request specific attributes or named groups, there
+   is a potential that there is some overlap.  For example, if a client
+   requests, 'printer-name' and 'all', the client is actually requesting
+   the "printer-name" attribute twice: once by naming it explicitly, and
+   once by inclusion in the 'all' group.  In such cases, the Printer
+   object NEED NOT return each attribute only once in the response even
+   if it is requested multiple times.  The client SHOULD NOT request the
+   same attribute in multiple ways.
+
+   It is NOT REQUIRED that a Printer object support all attributes
+   belonging to a group (since some attributes are OPTIONAL).  However,
+   it is REQUIRED that each Printer object support all group names.
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 43]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+3.2.5.1 Get-Printer-Attributes Request
+
+   The following sets of attributes are part of the Get-Printer-
+   Attributes Request:
+
+   Group 1: Operation Attributes
+
+     Natural Language and Character Set:
+        attributes-charset" and "attributes-natural-language" butes as
+        described in section 3.1.4.1.
+
+     Target:
+        The "printer-uri" (uri) operation attribute which is the target
+        for this operation as described in section 3.1.5.
+
+     Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+     "requested-attributes" (1setOf keyword) :
+        The client OPTIONALLY supplies a set of attribute names and/or
+        attribute group names in whose values the requester is
+        interested.  The Printer object MUST support this attribute.  If
+        the client omits this attribute, the Printer MUST respond as if
+        this attribute had been supplied with a value of 'all'.
+
+     "document-format" (mimeMediaType) :
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  This attribute is useful
+        for a Printer object to determine the set of supported attribute
+        values that relate to the requested document format.  The
+        Printer object MUST return the attributes and values that it
+        uses to validate a job on a create or Validate-Job operation in
+        which this document format is supplied. The Printer object
+        SHOULD return only (1) those attributes that are supported for
+        the specified format and (2) the attribute values that are
+        supported for the specified document format.  By specifying the
+        document format, the client can get the Printer object to
+        eliminate the attributes and values that are not supported for a
+        specific document format.  For example, a Printer object might
+        have multiple interpreters to support both '
+        application/postscript' (for PostScript) and 'text/plain' (for
+        text) documents.  However, for only one of those interpreters
+        might the Printer object be able to support "number-up" with
+        values of '1', '2', and '4'.  For the other interpreter it might
+        be able to only support "number-up" with a value of '1'. Thus a
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 44]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        client can use the Get-Printer-Attributes operation to obtain
+        the attributes and values that will be used to accept/reject a
+        create job operation.
+
+        If the Printer object does not distinguish between different
+        sets of supported values for each different document format when
+        validating jobs in the create and Validate-Job operations, it
+        MUST NOT distinguish between different document formats in the
+        Get-Printer-Attributes operation. If the Printer object does
+        distinguish between different sets of supported values for each
+        different document format specified by the client, this
+        specialization applies only to the following Printer object
+        attributes:
+
+       - Printer attributes that are Job Template attributes ("xxx-
+          default" "xxx-supported", and "xxx-ready" in the Table in
+          Section 4.2),
+       - "pdl-override-supported",
+       - "compression-supported",
+       - "job-k-octets-supported",
+       - "job-impressions-supported,
+       - "job-media-sheets-supported"
+       - "printer-driver-installer",
+       - "color-supported", and
+       - "reference-uri-schemes-supported"
+
+        The values of all other Printer object attributes (including
+        "document-format-supported") remain invariant with respect to
+        the client supplied document format (except for new Printer
+        description attribute as registered according to section 6.2).
+
+        If the client omits this "document-format" operation attribute,
+        the Printer object MUST respond as if the attribute had been
+        supplied with the value of the Printer object's "document-
+        format-default" attribute.  It is recommended that the client
+        always supply a value for "document-format", since the Printer
+        object's "document-format-default" may be 'application/octet-
+        stream', in which case the returned attributes and values are
+        for the union of the document formats that the Printer can
+        automatically sense.  For more details, see the description of
+        the 'mimeMediaType' attribute syntax in section 4.1.9.
+
+        If the client supplies a value for the "document-format"
+        Operation attribute that is not supported by the Printer, i.e.,
+        is not among the values of the Printer object's "document-
+        format-supported" attribute, the Printer object MUST reject the
+        operation and return the 'client-error-document-format-not-
+        supported' status code.
+
+
+
+deBry, et al.                 Experimental                     [Page 45]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+3.2.5.2 Get-Printer-Attributes Response
+
+   The Printer object returns the following sets of attributes as part
+   of the Get-Printer-Attributes Response:
+
+   Group 1: Operation Attributes
+
+     Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text) operation attribute as described in section 3.1.6.
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+        This is a set of Operation attributes supplied by the client (in
+        the request) that are not supported by the Printer object or
+        that conflict with one another (see sections 3.2.1.2 and 16).
+        The response NEED NOT contain the "requested-attributes"
+        operation attribute with any supplied values (attribute
+        keywords) that were requested by the client but are not
+        supported by the IPP object.  If the Printer object is not
+        returning any Unsupported Attributes in the response, the
+        Printer object SHOULD omit Group 2 rather than sending an empty
+        group.  However, a client MUST be able to accept an empty group.
+
+   Group 3: Printer Object Attributes
+
+        This is the set of requested attributes and their current
+        values.  The Printer object ignores (does not respond with) any
+        requested attribute which is not supported.  The Printer object
+        MAY respond with a subset of the supported attributes and
+        values, depending on the security policy in force.  However, the
+        Printer object MUST respond with the 'unknown' value for any
+        supported attribute (including all REQUIRED attributes) for
+        which the Printer object does not know the value.  Also the
+        Printer object MUST respond with the 'no-value' for any
+        supported attribute (including all REQUIRED attributes) for
+        which the system administrator has not configured a value.  See
+        the description of the "out-of-band" values in the beginning of
+        Section 4.1.
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 46]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+3.2.6 Get-Jobs Operation
+
+   This REQUIRED operation allows a client to retrieve the list of Job
+   objects belonging to the target Printer object.  The client may also
+   supply a list of Job attribute names and/or attribute group names.  A
+   group of Job object attributes will be returned for each Job object
+   that is returned.
+
+   This operation is similar to the Get-Job-Attributes operation, except
+   that this Get-Jobs operation returns attributes from possibly more
+   than one object (see the description of Job attribute group names in
+   section 3.3.4).
+
+3.2.6.1 Get-Jobs Request
+
+   The client submits the Get-Jobs request to a Printer object.
+
+   The following groups of attributes are part of the Get-Jobs Request:
+
+   Group 1: Operation Attributes
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.
+
+     Target:
+        The "printer-uri" (uri) operation attribute which is the target
+        for this operation as described in section 3.1.5.
+
+     Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+     "limit" (integer(1:MAX)):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute. It is an integer value that
+        indicates a limit to the number of Job objects returned.  The
+        limit is a "stateless limit" in that if the value supplied by
+        the client is 'N', then only the first 'N' jobs are returned in
+        the Get-Jobs Response.  There is no mechanism to allow for the
+        next 'M' jobs after the first 'N' jobs.  If the client does not
+        supply this attribute, the Printer object responds with all
+        applicable jobs.
+
+     "requested-attributes" (1setOf keyword):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  It is a set of Job
+        attribute names and/or attribute groups names in whose values
+
+
+
+deBry, et al.                 Experimental                     [Page 47]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        the requester is interested.  This set of attributes is returned
+        for each Job object that is returned.  The allowed attribute
+        group names are the same as those defined in the Get-Job-
+        Attributes operation in section 3.3.4.  If the client does not
+        supply this attribute, the Printer MUST respond as if the client
+        had supplied this attribute with two values:  'job-uri' and '
+        job-id'.
+
+     "which-jobs" (type2 keyword):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  It indicates which Job
+        objects MUST be returned by the Printer object. The values for
+        this attribute are:
+
+          'completed': This includes any Job object whose state is
+             'completed', 'canceled', or 'aborted'.
+          'not-completed': This includes any Job object whose state is '
+             pending', 'processing', 'processing-stopped', or 'pending-
+             held'.
+
+        A Printer object MUST support both values.  However, if the
+        mentation does not keep jobs in the 'completed', 'canceled', '
+        aborted' states, then it returns no jobs when the 'completed'
+        value is supplied.
+
+        If a client supplies some other value, the Printer object MUST
+        copy the attribute and the unsupported value to the Unsupported
+        Attributes response group, reject the request, and return the '
+        client-error-attributes-or-values-not-supported' status code.
+
+        If the client does not supply this attribute, the Printer object
+        MUST respond as if the client had supplied the attribute with a
+        value of 'not-completed'.
+
+     "my-jobs" (boolean):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  It indicates whether all
+        jobs or just the jobs submitted by the requesting user of this
+        request  MUST be returned by the Printer object.  If the client
+        does not supply this attribute, the Printer object MUST respond
+        as if the client had supplied the attribute with a value of '
+        false', i.e., all jobs.  The means for authenticating the
+        requesting user and matching the jobs is described in section 8.
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 48]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+3.2.6.2 Get-Jobs Response
+
+   The Printer object returns all of the Job objects that match the
+   criteria as defined by the attribute values supplied by the client in
+   the request.  It is possible that no Job objects are returned since
+   there may literally be no Job objects at the Printer, or there may be
+   no Job objects that match the criteria supplied by the client.  If
+   the client requests any Job attributes at all, there is a set of Job
+   Object Attributes returned for each Job object.
+
+   Group 1: Operation Attributes
+
+     Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text) operation attribute as described in sections 14 and
+        3.1.6.
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+        This is a set of Operation attributes supplied by the client (in
+        the request) that are not supported by the Printer object or
+        that conflict with one another (see sections 3.2.1.2 and the
+        Implementer's Guide [ipp-iig]).  The response NEED NOT contain
+        the "requested-attributes" operation attribute with any supplied
+        values (attribute keywords) that were requested by the client
+        but are not supported by the IPP object.  If the Printer object
+        is not returning any Unsupported Attributes in the response, the
+        Printer object SHOULD omit Group 2 rather than sending an empty
+        group.  However, a client MUST be able to accept an empty group.
+
+   Groups 3 to N: Job Object Attributes
+
+        The Printer object responds with one set of Job Object
+        Attributes for each returned Job object.  The Printer object
+        ignores (does not respond with) any requested attribute or value
+        which is not supported or which is restricted by the security
+        policy in force, including whether the requesting user is the
+        user that submitted the job (job originating user) or not (see
+        section 8).  However, the Printer object MUST respond with the '
+        unknown' value for any supported attribute (including all
+        REQUIRED attributes) for which the Printer object does not know
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 49]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        the value, unless it would violate the security policy.  See the
+        description of the "out-of-band" values in the beginning of
+        Section 4.1.
+
+        Jobs are returned in the following order:
+
+          - If the client requests all 'completed' Jobs (Jobs in the '
+            completed', 'aborted', or 'canceled' states), then the Jobs
+            are returned newest to oldest (with respect to actual
+            completion time)
+          - If the client requests all 'not-completed' Jobs (Jobs in the
+            'pending', 'processing', 'pending-held', and 'processing-
+            stopped' states), then Jobs are returned in relative
+            chronological order of expected time to complete (based on
+            whatever scheduling algorithm is configured for the Printer
+            object).
+
+3.3 Job Operations
+
+   All Job operations are directed at Job objects.  A client MUST always
+   supply some means of identifying the Job object in order to identify
+   the correct target of the operation.  That job identification MAY
+   either be a single Job URI or a combination of a Printer URI with a
+   Job ID.  The IPP object implementation MUST support both forms of
+   identification for every job.
+
+3.3.1 Send-Document Operation
+
+   This OPTIONAL operation allows a client to create a multi-document
+   Job object that is initially "empty" (contains no documents).  In the
+   Create-Job response, the Printer object returns the Job object's URI
+   (the "job-uri" attribute) and the Job object's 32-bit identifier (the
+   "job-id" attribute).  For each new document that the client desires
+   to add, the client uses a Send-Document operation.  Each Send-
+   Document Request contains the entire stream of document data for one
+   document.
+
+   Since the Create-Job and the send operations (Send-Document or Send-
+   URI operations) that follow could occur over an arbitrarily long
+   period of time for a particular job, a client MUST send another send
+   operation within an IPP Printer defined minimum time interval after
+   the receipt of the previous request for the job.  If a Printer object
+   supports multiple document jobs, the Printer object MUST support the
+   "multiple-operation-time-out" attribute (see section 4.4.28).  This
+   attribute indicates the minimum number of seconds the Printer object
+   will wait for the next send operation before taking some recovery
+   action.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 50]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   An IPP object MUST recover from an errant client that does not supply
+   a send operation, sometime after the minimum time interval specified
+   by the Printer object's "multiple-operation-time-out" attribute.
+   Such recovery MAY include any of the following or other recovery
+   actions:
+
+     1. Assume that the Job is an invalid job, start the process of
+        changing the job state to 'aborted', add the 'aborted-by-system'
+        value to the job's "job-state-reasons" attribute (see section
+        4.3.8), if supported, and clean up all resources associated with
+        the Job.  In this case, if another send operation is finally
+        received, the Printer responds with an "client-error-not-
+        possible" or "client-error-not-found" depending on whether or
+        not the Job object is still around when the send operation
+        finally arrives.
+     2. Assume that the last send operation received was in fact the
+        last document (as if the "last-document" flag had been set to '
+        true'), close the Job object, and proceed to process it (i.e.,
+        move the Job's state to 'pending').
+     3. Assume that the last send operation received was in fact the
+        last document, close the Job, but move it to the 'pending-held'
+        and add the 'submission-interrupted' value to the job's "job-
+        state-reasons" attribute (see section 4.3.8), if supported.
+        This action allows the user or an operator to determine whether
+        to continue processing the Job by moving it back to the '
+        pending' state or to cancel the job.
+
+   Each implementation is free to decide the "best" action to take
+   depending on local policy, whether any documents have been added,
+   whether the implementation spools jobs or not, and/or any other piece
+   of information available to it.  If the choice is to abort the Job
+   object, it is possible that the Job object may already have been
+   processed to the point that some media sheet pages have been printed.
+
+3.3.1.1 Send-Document Request
+
+   The following attribute sets are part of the Send-Document Request:
+
+   Group 1: Operation Attributes
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 51]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     Target:
+        Either (1) the "printer-uri" (uri) plus "job-id"
+        (integer(1:MAX))or (2) the "job-uri" (uri) operation
+        attribute(s) which define the target for this operation as
+        described in section 3.1.5.
+
+     Requesting User Name:
+        "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
+        by the client as described in section 8.3.
+
+     "document-name" (name(MAX)):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  It contains the client
+        supplied document name.  The document name MAY be different than
+        the Job name.  It might be helpful, but NEED NOT be unique
+        across multiple documents in the same Job.  Typically, the
+        client software automatically supplies the document name on
+        behalf of the end user by using a file name or an application
+        generated name.  See the description of the "document-name"
+        operation attribute in the Print-Job Request (section 3.2.1.1)
+        for more information about this attribute
+
+   "document-format" (mimeMediaType):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  The value of this attribute
+        identifies the format of the supplied document data.  If the
+        client does not supply this attribute, the Printer object
+        assumes that the document data is in the format defined by the
+        Printer object's "document-format-default" attribute.  If the
+        client supplies this attribute, but the value is not supported
+        by the Printer object, i.e., the value is not one of the values
+        of the Printer object's "document-format-supported" attribute,
+        the Printer object MUST reject the request and return the '
+        client-error-document-format-not-supported' status code.
+
+     "document-natural-language" (naturalLanguage):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute.  This attribute
+        specifies the natural language of the document for those
+        document-formats that require a specification of the natural
+        language in order to image the document unambiguously.  There
+        are no particular values required for the Printer object to
+        support.
+
+     "compression" (type3 keyword)
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute and the "compression-
+        supported" attribute (see section 4.4.29).  The client supplied
+
+
+
+deBry, et al.                 Experimental                     [Page 52]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        "compression" operation attribute identifies the compression
+        algorithm used on the document data.  If the client omits this
+        attribute, the Printer object MUST assume that the data is not
+        compressed.  If the client supplies the attribute and the
+        Printer object supports the attribute, the Printer object MUST
+        use the corresponding decompression algorithm on the document
+        data. If the client supplies this attribute, but the value is
+        not supported by the Printer object, i.e., the value is not one
+        of the values of the Printer object's "compression-supported"
+        attribute, the Printer object MUST copy the attribute and its
+        value to the Unsupported Attributes response group, reject the
+        request, and return the 'client-error-attributes-or-values-not-
+        supported' status code.
+
+     "last-document" (boolean):
+        The client MUST supply this attribute.  The Printer object MUST
+        support this attribute. It is a boolean flag that is set to '
+        true' if this is the last document for the Job, 'false'
+        otherwise.
+
+   Group 2: Document Content
+
+        The client MUST supply the document data if the "last-document"
+        flag is set to 'false'.  However, since a client might not know
+        that the previous document sent with a Send-Document (or Send-
+        URI) operation was the last document (i.e., the "last-document"
+        attribute was set to 'false'), it is legal to send a Send-
+        Document request with no document data where the "last-document"
+        flag is set to 'true'.  Such a request MUST NOT increment the
+        value of the Job object's "number-of-documents" attribute, since
+        no real document was added to the job.
+
+3.3.1.2 Send-Document Response
+
+   The following sets of attributes are part of the Send-Document
+   Response:
+
+   Group 1: Operation Attributes
+
+     Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text) operation attribute as described in sections 14 and
+        3.1.6.
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+
+
+deBry, et al.                 Experimental                     [Page 53]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Group 2: Unsupported Attributes
+
+        This is a set of Operation attributes supplied by the client (in
+        the request) that are not supported by the Printer object or
+        that conflict with one another (see sections 3.2.1.2 and the
+        Implementer's Guide [ipp-iig]).  If the Printer object is not
+        returning any Unsupported Attributes in the response, the
+        Printer object SHOULD omit Group 2 rather than sending an empty
+        group.  However, a client MUST be able to accept an empty group.
+
+   Group 3: Job Object Attributes
+
+        This is the same set of attributes as described in the Print-Job
+        response (see section 3.2.1.2).
+
+3.3.2 Send-URI Operation
+
+   This OPTIONAL operation is identical to the Send-Document operation
+   (see section 3.3.1) except that a client MUST supply a URI reference
+   ("document-uri" operation attribute) rather than the document data
+   itself.  If a Printer object supports this operation, clients can use
+   both Send-URI or Send-Document operations to add new documents to an
+   existing multi-document Job object.  However, if a client needs to
+   indicate that the previous Send-URI or Send-Document was the last
+   document,  the client MUST use the Send-Document operation with no
+   document data and the "last-document" flag set to 'true' (rather than
+   using a Send-URI operation with no "document-uri" operation
+   attribute).
+
+   If a Printer object supports this operation, it MUST also support the
+   Print-URI operation (see section 3.2.2).
+
+   The Printer object MUST validate the syntax and URI scheme of the
+   supplied URI before returning a response, just as in the Print-URI
+   operation.
+
+3.3.3 Cancel-Job Operation
+
+   This REQUIRED operation allows a client to cancel a Print Job from
+   the time the job is created up to the time it is completed, canceled,
+   or aborted.  Since a Job might already be printing by the time a
+   Cancel-Job is received, some media sheet pages might be printed
+   before the job is actually terminated.
+
+3.3.3.1 Cancel-Job Request
+
+   The following groups of attributes are part of the Cancel-Job
+   Request:
+
+
+
+deBry, et al.                 Experimental                     [Page 54]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Group 1: Operation Attributes
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.
+
+     Target:
+        Either (1) the "printer-uri" (uri) plus "job-id"
+        (integer(1:MAX))or (2) the "job-uri" (uri) operation
+        attribute(s) which define the target for this operation as
+        described in section 3.1.5.
+
+     Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+     "message" (text(127)):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute. It is a message to
+        the operator.  This "message" attribute is not the same as the
+        "job-message-from-operator" attribute.  That attribute is used
+        to report a message from the operator to the end user that
+        queries that attribute.  This "message" operation attribute is
+        used to send a message from the client to the operator along
+        with the operation request.  It is an implementation decision of
+        how or where to display this message to the operator (if at
+        all).
+
+3.3.3.2 Cancel-Job Response
+
+   The following sets of attributes are part of the Cancel-Job Response:
+
+   Group 1: Operation Attributes
+
+     Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text) operation attribute as described in sections 14 and
+        3.1.6.
+
+        If the job is already in the 'completed', 'aborted', or '
+        canceled' state, or the 'process-to-stop-point' value is set in
+        the Job's "job-state-reasons" attribute, the Printer object MUST
+        reject the request and return the 'client-error-not-possible'
+        error status code.
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 55]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+        This is a set of Operation attributes supplied by the client (in
+        the request) that are not supported by the Printer object or
+        that conflict with one another (see section 3.2.1.2 and the
+        Implementer's Guide [ipp-iig]).  If the Printer object is not
+        returning any Unsupported Attributes in the response, the
+        Printer object SHOULD omit Group 2 rather than sending an empty
+        group.  However, a client MUST be able to accept an empty group.
+
+   Once a successful response has been sent, the implementation
+   guarantees that the Job will eventually end up in the 'canceled'
+   state. Between the time of the Cancel-Job operation is accepted and
+   when the job enters the 'canceled' job-state (see section 4.3.7), the
+   "job-state-reasons" attribute SHOULD contain the 'processing-to-
+   stop-point' value which indicates to later queries that although the
+   Job might still be 'processing', it will eventually end up in the '
+   canceled' state, not the 'completed' state.
+
+3.3.4 Get-Job-Attributes Operation
+
+   This REQUIRED operation allows a client to request the values of
+   attributes of a Job object and it is almost identical to the Get-
+   Printer-Attributes operation (see section 3.2.5).  The only
+   differences are that the operation is directed at a Job object rather
+   than a Printer object, there is no "document-format" operation
+   attribute used when querying a Job object, and the returned attribute
+   group is a set of Job object attributes rather than a set of Printer
+   object attributes.
+
+   For Jobs, the possible names of attribute groups are:
+
+     - 'job-template': all of the Job Template attributes that apply to a
+       Job object (the first column of the table in Section 4.2).
+     - 'job-description': all of the Job Description attributes specified
+       in Section 4.3.
+     - 'all': the special group 'all' that includes all supported
+       attributes.
+
+   Since a client MAY request specific attributes or named groups, there
+   is a potential that there is some overlap.  For example, if a client
+   requests, 'job-name' and 'job-description', the client is actually
+   requesting the "job-name" attribute once by naming it explicitly, and
+   once by inclusion in the 'job-description' group.  In such cases, the
+
+
+
+deBry, et al.                 Experimental                     [Page 56]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Printer object NEED NOT return the attribute only once in the
+   response even if it is requested multiple times.  The client SHOULD
+   NOT request the same attribute in multiple ways.
+
+   It is NOT REQUIRED that a Job object support all attributes belonging
+   to a group (since some attributes are OPTIONAL).  However it is
+   REQUIRED that each Job object support all group names.
+
+3.3.4.1 Get-Job-Attributes Request
+
+   The following groups of attributes are part of the Get-Job-Attributes
+   Request when the request is directed at a Job object:
+
+   Group 1: Operation Attributes
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.
+
+     Target:
+        Either (1) the "printer-uri" (uri) plus "job-id"
+        (integer(1:MAX)) or (2) the "job-uri" (uri) operation
+        attribute(s) which define the target for this operation as
+        described in section 3.1.5.
+
+     Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+     "requested-attributes" (1setOf keyword) :
+        The client OPTIONALLY supplies this attribute.  The IPP object
+        MUST support this attribute.   It is a set of attribute names
+        and/or attribute group names in whose values the requester is
+        interested.  If the client omits this attribute, the IPP object
+        MUST respond as if this attribute had been supplied with a value
+        of 'all'.
+
+3.3.4.2 Get-Job-Attributes Response
+
+   The Printer object returns the following sets of attributes as part
+   of the Get-Job-Attributes Response:
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 57]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Group 1: Operation Attributes
+
+     Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text) operation attribute as described in sections 14 and
+        3.1.6.
+
+     Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.  The "attributes-
+        natural-language" MAY be the natural language of the Job object,
+        rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+        This is a set of Operation attributes supplied by the client (in
+        the request) that are not supported by the Printer object or
+        that conflict with one another (see sections 3.2.1.2 and the
+        Implementer's Guide [ipp-iig]).  The response NEED NOT contain
+        the "requested-attributes" operation attribute with any supplied
+        values (attribute keywords) that were requested by the client
+        but are not supported by the IPP object.  If the Printer object
+        is not returning any Unsupported Attributes in the response, the
+        Printer object SHOULD omit Group 2 rather than sending an empty
+        group.  However, a client MUST be able to accept an empty group.
+
+   Group 3: Job Object Attributes
+
+        This is the set of requested attributes and their current
+        values.  The IPP object ignores (does not respond with) any
+        requested attribute or value which is not supported or which is
+        restricted by the security policy in force, including whether
+        the requesting user is the user that submitted the job (job
+        originating user) or not (see section 8).  However, the IPP
+        object MUST respond with the 'unknown' value for any supported
+        attribute (including all RED butes) for which the IPP object
+        does not know the value, s it would violate the security policy.
+        See the description e "out-of-band" values in the beginning of
+        Section 4.1.
+
+4. Object Attributes
+
+   This section describes the attributes with their corresponding
+   attribute syntaxes and values that are part of the IPP model.  The
+   sections below show the objects and their associated attributes which
+   are included within the scope of this protocol.  Many of these
+   attributes are derived from other relevant specifications:
+
+
+
+deBry, et al.                 Experimental                     [Page 58]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     - Document Printing Application (DPA) [ISO10175]
+     - RFC 1759 Printer MIB [RFC1759]
+
+   Each attribute is uniquely identified in this document using a
+   "keyword" (see section 12.2.1) which is the name of the attribute.
+   The keyword is included in the section header describing that
+   attribute.
+
+   Note: Not only are keywords used to identify attributes, but one of
+   the attribute syntaxes described below is "keyword" so that some
+   attributes have keyword values.  Therefore, these attributes are
+   defined as having an attribute syntax that is a set of keywords.
+
+4.1 Attribute Syntaxes
+
+   This section defines the basic attribute syntax types that all clients
+   and IPP objects MUST be able to accept in responses and accept in
+   requests, respectively.  Each attribute description in sections 3 and
+   4 includes the name of attribute syntax(es) in the heading (in
+   parentheses).  A conforming implementation of an attribute MUST
+   include the semantics of the attribute syntax(es) so identified.
+   Section 6.3 describes how the protocol can be extended with new
+   attribute syntaxes.
+
+   The attribute syntaxes are specified in the following sub-sections,
+   where the sub-section heading is the keyword name of the attribute
+   syntax inside the single quotes.  In operation requests and responses
+   each attribute value MUST be represented as one of the attribute
+   syntaxes specified in the sub-section heading for the attribute.  In
+   addition, the value of an attribute in a response (but not in a
+   request) MAY be one of the "out-of-band" values.  Standard
+   "out-of-band" values are:
+
+     'unknown': The attribute is supported by the IPP object, but the
+        value is unknown to the IPP object for some reason.
+     'unsupported': The attribute is unsupported by the IPP object.  This
+        value MUST be returned only as the value of an attribute in the
+        Unsupported Attributes Group.
+     'no-value': The attribute is supported by the Printer object, but
+        the system administrator has not yet configured a value.
+
+   The Encoding and Transport specification [RFC2565] defines mechanisms
+   for passing "out-of-band" values.  All attributes in a request MUST
+   have one or more values as defined in Sections 4.2 to 4.4.  Thus
+   clients MUST NOT supply attributes with "out-of-band" values.  All
+   attribute in a response MUST have one or more values as defined in
+   Sections 4.2 to 4.4 or a single "out-of-band" value.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 59]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Most attributes are defined to have a single attribute syntax.
+   However, a few attributes (e.g., "job-sheet", "media", "job-hold-
+   until") are defined to have several attribute syntaxes, depending on
+   the value.  These multiple attribute syntaxes are separated by the
+   "|" character in the sub-section heading to indicate the choice.
+   Since each value MUST be tagged as to its attribute syntax in the
+
+   protocol, a single-valued attribute instance may have any one of its
+   attribute syntaxes and a multi-valued attribute instance may have a
+   mixture of its defined attribute syntaxes.
+
+4.1.1 'text'
+
+   A text attribute is an attribute whose value is a sequence of zero or
+   more characters encoded in a maximum of 1023 ('MAX') octets.  MAX is
+   the maximum length for each value of any text attribute.  However, if
+   an attribute will always contain values whose maximum length is much
+   less than MAX, the definition of that attribute will include a
+   qualifier that defines the maximum length for values of that
+   attribute.  For example: the "printer-location" attribute is
+   specified as "printer-location (text(127))".  In this case, text
+   values for "printer-location" MUST NOT exceed 127 octets; if supplied
+   with a longer text string via some external interface (other than the
+   protocol), implementations are free to truncate to this shorter
+   length limitation.
+
+   In this specification, all text attributes are defined using the '
+   text' syntax.  However, 'text' is used only for brevity; the formal
+   interpretation of 'text' is: 'textWithoutLanguage |
+   textWithLanguage'.  That is, for any attribute defined in this
+   specification using the 'text' attribute syntax, all IPP objects and
+   clients MUST support both the 'textWithoutLanguage' and '
+   textWithLanguage' attribute syntaxes.  However, in actual usage and
+   protocol execution, objects and clients accept and return only one of
+   the two syntax per attribute.  The syntax 'text' never appears "on-
+   the-wire".
+
+   Both 'textWithoutLanguage' and 'textWithLanguage' are needed to
+   support the real world needs of interoperability between sites and
+   systems that use different natural languages as the basis for human
+   communication.  Generally, one natural language applies to all text
+   attributes in a given request or response. The language is indicated
+   by the "attributes-natural-language" operation attribute defined in
+   section 3.1.4 or "attributes-natural-language" job attribute defined
+   in section 4.3.24, and there is no need to identify the natural
+   language for each text string on a value-by-value basis.  In these
+   cases, the attribute syntax 'textWithoutLanguage' is used for text
+   attributes.  In other cases, the client needs to supply or the
+
+
+
+deBry, et al.                 Experimental                     [Page 60]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Printer object needs to return a text value in a natural language
+   that is different from the rest of the text values in the request or
+   response.  In these cases, the client or Printer object uses the
+   attribute syntax 'textWithLanguage' for text attributes (this is the
+   Natural Language Override mechanism described in section 3.1.4).
+
+   The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes
+   are described in more detail in the following sections.
+
+4.1.1.1 'textWithoutLanguage'
+
+   The 'textWithoutLanguage' syntax indicates a value that is sequence
+   of zero or more characters.  Text strings are encoded using the rules
+   of some charset.  The Printer object MUST support the UTF-8 charset
+   [RFC2279] and MAY support additional charsets to represent 'text'
+   values, provided that the charsets are registered with IANA [IANA-
+   CS].  See Section 4.1.7 for the specification of the 'charset'
+   attribute syntax, including restricted semantics and examples of
+   charsets.
+
+4.1.1.2 'textWithLanguage'
+
+   The 'textWithLanguage' attribute syntax is a compound attribute
+   syntax consisting of two parts: a 'textWithoutLanguage' part plus an
+   additional 'naturalLanguage' (see section 4.1.8) part that overrides
+   the natural language in force.  The 'naturalLanguage' part explicitly
+   identifies the natural language that applies to the text part of that
+   value and that value alone.  For any give text attribute, the '
+   textWithoutLanguage' part is limited to the maximum length defined
+   for that attribute, but the 'naturalLanguage' part is always limited
+   to 63 octets. Using the 'textWithLanguage' attribute syntax rather
+   than the normal 'textWithoutLanguage' syntax is the so-called Natural
+   Language Override mechanism and MUST be supported by all IPP objects
+   and clients.
+
+   If the attribute is multi-valued (1setOf text), then the '
+   textWithLanguage' attribute syntax MUST be used to explicitly specify
+   each attribute value whose natural language needs to be overridden.
+   Other values in a multi-valued 'text' attribute in a request or a
+   response revert to the natural language of the operation attribute.
+
+   In a create request, the Printer object MUST accept and store with
+   the Job object any natural language in the "attributes-natural-
+   language" operation attribute, whether the Printer object supports
+   that natural language or not.  Furthermore, the Printer object MUST
+   accept and store any 'textWithLanguage' attribute value, whether the
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 61]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Printer object supports that natural language or not.  These
+   requirements are independent of the value of the "ipp-attribute-
+   fidelity" operation attribute that the client MAY supply.
+
+   Example: If the client supplies the "attributes-natural-language"
+   operation attribute with the value: 'en' indicating English, but the
+   value of the "job-name" attribute is in French, the client MUST use
+   the 'textWithLanguage' attribute syntax with the following two
+   values:
+
+     'fr': Natural Language Override indicating French
+     'Rapport Mensuel': the job name in French
+
+   See the Encoding and Transport document [RFC2565] for a detailed
+   example of the 'textWithLanguage' attribute syntax.
+
+4.1.2 'name'
+
+   This syntax type is used for user-friendly strings, such as a Printer
+   name, that, for humans, are more meaningful than identifiers.  Names
+   are never translated from one natural language to another.  The '
+   name' attribute syntax is essentially the same as 'text', including
+   the REQUIRED support of UTF-8 except that the sequence of characters
+   is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
+
+   Also like 'text', 'name' is really an abbreviated notation for either
+   'nameWithoutLanguage' or 'nameWithLanguage'.  That is, all IPP
+   objects and clients MUST support both the 'nameWithoutLanguage' and '
+   nameWithLanguage' attribute syntaxes.  However, in actual usage and
+   protocol execution, objects and clients accept and return only one of
+   the two syntax per attribute.  The syntax 'name' never appears "on-
+   the-wire".
+
+   Note: Only the 'text' and 'name' attribute syntaxes permit the
+   Natural Language Override mechanism.
+
+   Some attributes are defined as 'type3 keyword | name'.  These
+   attributes support values that are either type3 keywords or names.
+   This dual-syntax mechanism enables a site administrator to extend
+   these attributes to legally include values that are locally defined
+   by the site administrator.  Such names are not registered with IANA.
+
+4.1.2.1 'nameWithoutLanguage'
+
+   The 'nameWithoutLanguage' syntax indicates a value that is sequence
+   of zero or more characters so that its encoded form does not exceed
+   MAX octets.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 62]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.1.2.2 'nameWithLanguage'
+
+   The 'nameWithLanguage' attribute syntax is a compound attribute
+   syntax consisting of two parts: a 'nameWithoutLanguage' part plus an
+   additional 'naturalLanguage' (see section 4.1.8) part that overrides
+   the natural language in force.  The 'naturalLanguage' part explicitly
+   identifies the natural language that applies to that name value and
+   that name value alone.
+
+   The 'nameWithLanguage' attribute syntax behaves the same as the '
+   textWithLanguage' syntax.  If a name is in a language that is
+   different than the rest of the object or operation, then this '
+   nameWithLanguage' syntax is used rather than the generic '
+   nameWithoutLanguage' syntax.
+
+   Example: If the client supplies the "attributes-natural-language"
+   operation attribute with the value: 'en' indicating English, but the
+   "printer-name" attribute is in German, the client MUST use the '
+   nameWithLanguage' attribute syntax as follows:
+
+     'de':  Natural Language Override indicating German
+     'Farbdrucker':  the Printer name in German
+
+4.1.2.3 Matching 'name' attribute values
+
+   For purposes of matching two 'name' attribute values for equality,
+   such as in job validation (where a client-supplied value for
+   attribute "xxx" is checked to see if the value is among the values of
+   the Printer object's corresponding "xxx-supported" attribute), the
+   following match rules apply:
+
+        1. 'keyword' values never match 'name' values.
+
+        2. 'name' (nameWithoutLanguage and nameWithLanguage) values
+        match if (1) the name parts match and (2) the Associated
+        Natural-Language parts (see section 3.1.4.1) match.  The
+        matching rules are:
+
+             a. the name parts match if the two names are identical
+             character by character, except it is RECOMMENDED that case
+             be ignored.  For example: 'Ajax-letter-head-white' MUST
+             match 'Ajax-letter-head-white' and SHOULD match 'ajax-
+             letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'.
+
+             b. the Associated Natural-Language parts match if the
+             shorter of the two meets the syntactic requirements of RFC
+             1766 [RFC1766] and matches byte for byte with the longer.
+             For example, 'en' matches 'en', 'en-us' and 'en-gb', but
+
+
+
+deBry, et al.                 Experimental                     [Page 63]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+             matches neither 'fr' nor 'e'.
+
+4.1.3 'keyword'
+
+   The 'keyword' attribute syntax is a sequence of characters, length: 1
+   to 255, containing only the US-ASCII [ASCII] encoded values for
+   lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot
+   ("."), and underscore ("_").  The first character MUST be a lowercase
+   letter.  Furthermore, keywords MUST be in U.S. English.
+
+   This syntax type is used for enumerating semantic identifiers of
+   entities in the abstract protocol, i.e., entities identified in this
+   document.  Keywords are used as attribute names or values of
+   attributes.  Unlike 'text' and 'name' attribute values, 'keyword'
+   values MUST NOT use the Natural Language Override mechanism, since
+   they MUST always be US-ASCII and U.S. English.
+
+   Keywords are for use in the protocol.  A user interface will likely
+   provide a mapping between protocol keywords and displayable user-
+   friendly words and phrases which are localized to the natural
+   language of the user.  While the keywords specified in this document
+   MAY be displayed to users whose natural language is U.S. English,
+   they MAY be mapped to other U.S. English words for U.S. English
+   users, since the user interface is outside the scope of this
+   document.
+
+   In the definition for each attribute of this syntax type, the full
+   set of defined keyword values for that attribute are listed.
+
+   When a keyword is used to represent an attribute (its name), it MUST
+   be unique within the full scope of all IPP objects and attributes.
+   When a keyword is used to represent a value of an attribute, it MUST
+   be unique just within the scope of that attribute.  That is, the same
+   keyword MUST NOT be used for two different values within the same
+   attribute to mean two different semantic ideas.  However, the same
+   keyword MAY be used across two or more attributes, representing
+   different semantic ideas for each attribute.  Section 6.1 describes
+   how the protocol can be extended with new keyword values.  Examples
+   of attribute name keywords:
+
+     "job-name"
+     "attributes-charset"
+
+   Note:  This document uses "type1", "type2", and "type3" prefixes to
+   the "keyword" basic syntax to indicate different levels of review for
+   extensions (see section 6.1).
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 64]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.1.4 'enum'
+
+   The 'enum' attribute syntax is an enumerated integer value that is in
+   the range from 1 to 2**31 - 1 (MAX).   Each value has an associated '
+   keyword' name.  In the definition for each attribute of this syntax
+   type, the full set of possible values for that attribute are listed.
+   This syntax type is used for attributes for which there are enum
+   values assigned by other standards, such as SNMP MIBs.  A number of
+   attribute enum values in this specification are also used for
+   corresponding attributes in other standards [RFC1759].  This syntax
+   type is not used for attributes to which the system administrator may
+   assign values.  Section 6.1 describes how the protocol can be
+   extended with new enum values.
+
+   Enum values are for use in the protocol.  A user interface will
+   provide a mapping between protocol enum values and displayable user-
+   friendly words and phrases which are localized to the natural
+   language of the user.  While the enum symbols specified in this
+   document MAY be displayed to users whose natural language is U.S.
+   English, they MAY be mapped to other U.S. English words for U.S.
+   English users, since the user interface is outside the scope of this
+   document.
+
+   Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP
+   "out-of-band" value 'unknown'.  See the description of the "out-of-
+   band" values at the beginning of Section 4.1.  Therefore, attributes
+   of type 'enum' start at '3'.
+
+   Note:  This document uses "type1", "type2", and "type3" prefixes to
+   the "enum" basic syntax to indicate different levels of review for
+   extensions (see section 6.1).
+
+4.1.5 'uri'
+
+   The 'uri' attribute syntax is any valid Uniform Resource Identifier
+   or URI [RFC2396].  Most often, URIs are simply Uniform Resource
+   Locators or URLs.  The maximum length of URIs used as values of IPP
+   attributes is 1023 octets.  Although most other IPP attribute syntax
+   types allow for only lower-cased values, this attribute syntax type
+   conforms to the case-sensitive and case-insensitive rules specified
+   in [RFC2396].
+
+4.1.6 'uriScheme'
+
+   The 'uriScheme' attribute syntax is a sequence of characters
+   representing a URI scheme according to RFC 2396 [RFC2396].  Though
+   RFC 2396 requires that the values be case-insensitive, IPP requires
+
+
+
+
+deBry, et al.                 Experimental                     [Page 65]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   all lower case values in IPP attributes to simplify comparing by IPP
+   clients and Printer objects.  Standard values for this syntax type
+   are the following keywords:
+
+     'http':  for HTTP schemed URIs (e.g., "http:...")
+     'https':  for use with HTTPS schemed URIs (e.g., "https:...")
+        (not on IETF standards track)
+     'ftp': for FTP schemed URIs (e.g., "ftp:...")
+     'mailto': for SMTP schemed URIs (e.g., "mailto:...")
+     'file': for file schemed URIs (e.g., "file:...")
+
+   A Printer object MAY support any URI 'scheme' that has been
+   registered with IANA [IANA-MT]. The maximum length of URI 'scheme'
+   values used to represent IPP attribute values is 63 octets.
+
+4.1.7 'charset'
+
+   The 'charset' attribute syntax is a standard identifier for a
+   charset.  A charset is a coded character set and encoding scheme.
+   Charsets are used for labeling certain document contents and 'text'
+   and 'name' attribute values.  The syntax and semantics of this
+   attribute syntax are specified in RFC 2046 [RFC2046] and contained in
+   the IANA character-set Registry [IANA-CS] according to the IANA
+   procedures [RFC2278].  Though RFC 2046 requires that the values be
+   case-insensitive US-ASCII, IPP requires all lower case values in IPP
+   attributes to simplify comparing by IPP clients and Printer objects.
+   When a character-set in the IANA registry has more than one name
+   (alias), the name labeled as "(preferred MIME name)", if present,
+   MUST be used.
+
+   The maximum length of 'charset' values used to represent IPP
+   attribute values is 63 octets.
+
+   Some examples are:
+
+     'utf-8':  ISO 10646 Universal Multiple-Octet Coded Character Set
+        (UCS) represented as the UTF-8 [RFC2279] transfer encoding
+        scheme in which US-ASCII is a subset charset.
+     'us-ascii':  7-bit American Standard Code for Information
+        Interchange (ASCII), ANSI X3.4-1986 [ASCII].  That standard
+        defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the
+        control characters from conformant usage in MIME and IPP.
+     'iso-8859-1':  8-bit One-Byte Coded Character Set, Latin Alphabet
+        Nr 1 [ISO8859-1].  That standard defines a coded character set
+        that is used by Latin languages in the Western Hemisphere and
+        Western Europe.  US-ASCII is a subset charset.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 66]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'iso-10646-ucs-2':  ISO 10646 Universal Multiple-Octet Coded
+        Character Set (UCS) represented as two octets (UCS-2), with the
+        high order octet of each pair coming first (so-called Big Endian
+        integer).
+
+   Some attribute descriptions MAY place additional requirements on
+   charset values that may be used, such as REQUIRED values that MUST be
+   supported or additional restrictions, such as requiring that the
+   charset have US-ASCII as a subset charset.
+
+4.1.8 'naturalLanguage'
+
+   The 'naturalLanguage' attribute syntax is a standard identifier for a
+   natural language and optionally a country.  The values for this
+   syntax type are defined by RFC 1766 [RFC1766].  Though RFC 1766
+   requires that the values be case-insensitive US-ASCII, IPP requires
+   all lower case to simplify comparing by IPP clients and Printer
+   objects.  Examples include:
+
+     'en':  for English
+     'en-us': for US English
+     'fr': for French
+     'de':  for German
+
+   The maximum length of 'naturalLanguage' values used to represent IPP
+   attribute values is 63 octets.
+
+4.1.9 'mimeMediaType'
+
+   The 'mimeMediaType' attribute syntax is the Internet Media Type
+   (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and
+   registered according to the procedures of RFC 2048 [RFC2048] for
+   identifying a document format.  The value MAY include a charset
+   parameter, depending on the specification of the Media Type in the
+   IANA Registry [IANA-MT].  Although most other IPP syntax types allow
+   for only lower-cased values, this syntax type allows for mixed-case
+   values which are case-insensitive.
+
+   Examples are:
+
+     'text/html': An HTML document
+     'text/plain': A plain text document in US-ASCII (RFC 2046 indicates
+        that in the absence of the charset parameter MUST mean US-ASCII
+        rather than simply unspecified) [RFC2046].
+     'text/plain; charset=US-ASCII':  A plain text document in US-ASCII
+        [52, 56].
+     'text/plain; charset=ISO-8859-1':  A plain text document in ISO
+        8859-1 (Latin 1) [ISO8859-1].
+
+
+
+deBry, et al.                 Experimental                     [Page 67]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'text/plain; charset=utf-8':  A plain text document in ISO 10646
+        represented as UTF-8 [RFC2279]
+     'text/plain, charset=iso-10646-ucs-2':  A plain text document in
+        ISO 10646 represented in two octets (UCS-2) [ISO10646-1]
+     'application/postscript':  A PostScript document [RFC2046]
+     'application/vnd.hp-PCL':  A PCL document [IANA-MT] (charset escape
+        sequence embedded in the document data)
+     'application/octet-stream':  Auto-sense - see below
+
+   One special type is 'application/octet-stream'.  If the Printer
+   object supports this value, the Printer object MUST be capable of
+   auto-sensing the format of the document data.  If the Printer
+   object's default value attribute "document-format-default" is set to
+   'application/octet-stream', the Printer object not only supports
+   auto-sensing of the document format, but will depend on the result of
+   applying its auto-sensing when the client does not supply the
+   "document-format" attribute.  If the client supplies a document
+   format value, the Printer MUST rely on the supplied attribute, rather
+   than trust its auto-sensing algorithm.  To summarize:
+
+     1. If the client does not supply a document format value, the
+        Printer MUST rely on its default value setting (which may be '
+        application/octet-stream' indicating an auto-sensing mechanism).
+     2. If the client supplies a value other than 'application/octet-
+        stream', the client is supplying valid information about the
+        format of the document data and the Printer object MUST trust
+        the client supplied value more than the outcome of applying an
+        automatic format detection mechanism.  For example, the client
+        may be requesting the printing of a PostScript file as a '
+        text/plain' document.  The Printer object MUST print a text
+        representation of the PostScript commands rather than interpret
+        the stream of PostScript commands and print the result.
+     3. If the client supplies a value of 'application/octet-stream',
+        the client is indicating that the Printer object MUST use its
+        auto-sensing mechanism on the client supplied document data
+        whether auto-sensing is the Printer object's default or not.
+
+   Note:  Since the auto-sensing algorithm is probabilistic, if the
+   client requests both auto-sensing ("document-format" set to '
+   application/octet-stream') and true fidelity ("ipp-attribute-
+   fidelity" set to 'true'), the Printer object might not be able to
+   guarantee exactly what the end user intended (the auto-sensing
+   algorithm might mistake one document format for another ), but it is
+   able to guarantee that its auto-sensing mechanism be used.
+
+   The maximum length of a 'mimeMediaType' value to represent IPP
+   attribute values is 255 octets.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 68]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.1.10 'octetString'
+
+   The 'octetString' attribute syntax is a sequence of octets encoded in
+   a maximum of 1023 octets which is indicated in sub-section headers
+   using the notation: octetString(MAX).  This syntax type is used for
+   opaque data.
+
+4.1.11 'boolean'
+
+   The 'boolean' attribute syntax has only two values:  'true' and '
+   false'.
+
+4.1.12 'integer'
+
+   The 'integer' attribute syntax is an integer value that is in the
+   range from -2**31 (MIN) to 2**31 - 1 (MAX).  Each individual
+   attribute may specify the range constraint explicitly in sub-section
+   headers if the range is different from the full range of possible
+   integer values.  For example:  job-priority (integer(1:100)) for the
+   "job-priority" attribute.  However, the enforcement of that
+   additional constraint is up to the IPP objects, not the protocol.
+
+4.1.13 'rangeOfInteger'
+
+   The 'rangeOfInteger' attribute syntax is an ordered pair of integers
+   that defines an inclusive range of integer values.  The first integer
+   specifies the lower bound and the second specifies the upper bound.
+   If a range constraint is specified in the header description for an
+   attribute in this document whose attribute syntax is 'rangeOfInteger'
+   (i.e., 'X:Y' indicating X as a minimum value and Y as a maximum
+   value), then the constraint applies to both integers.
+
+4.1.14 'dateTime'
+
+   The 'dateTime' attribute syntax is a standard, fixed length, 11 octet
+   representation of the "DateAndTime" syntax as defined in RFC 2579
+   [RFC2579].  RFC 2579 also identifies an 8 octet representation of a
+   "DateAndTime" value, but IPP objects MUST use the 11 octet
+   representation.  A user interface will provide a mapping between
+   protocol dateTime values and displayable user-friendly words or
+   presentation values and phrases  which are localized to the natural
+   language and date format of the user.
+
+4.1.15 'resolution'
+
+   The 'resolution' attribute syntax specifies a two-dimensional
+   resolution in the indicated units.  It consists of 3 values: a cross
+   feed direction resolution (positive integer value), a feed direction
+
+
+
+deBry, et al.                 Experimental                     [Page 69]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   resolution (positive integer value), and a units value.  The
+   semantics of these three components are taken from the Printer MIB
+   [RFC1759] suggested values.  That is, the cross feed direction
+   component resolution component is the same as the
+   prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed
+   direction component resolution component is the same as the
+   prtMarkerAddressabilityFeedDir in the Printer MIB, and the units
+   component is the same as the prtMarkerAddressabilityUnit object in
+   the Printer MIB (namely, '3' indicates dots per inch and '4'
+   indicates dots per centimeter).  All three values MUST be present
+   even if the first two values are the same.  Example:  '300', '600', '
+   3' indicates a 300 dpi cross-feed direction resolution, a 600 dpi
+   feed direction resolution, since a '3' indicates dots per inch (dpi).
+
+4.1.16 '1setOf  X'
+
+   The '1setOf  X' attribute syntax is 1 or more values of attribute
+   syntax type X.  This syntax type is used for multi-valued attributes.
+   The syntax type is called '1setOf' rather than just 'setOf' as a
+   reminder that the set of values MUST NOT be empty (i.e., a set of
+   size 0).  Sets are normally unordered.  However each attribute
+   description of this type may specify that the values MUST be in a
+   certain order for that attribute.
+
+4.2 Job Template Attributes
+
+   Job Template attributes describe job processing behavior.  Support
+   for Job Template attributes by a Printer object is OPTIONAL (see
+   section 13.2.3 for a description of support for OPTIONAL attributes).
+   Also, clients OPTIONALLY supply Job Template attributes in create
+   requests.
+
+   Job Template attributes conform to the following rules.  For each Job
+   Template attribute called "xxx":
+
+     1. If the Printer object supports "xxx" then it MUST support both a
+        "xxx-default" attribute (unless there is a "No" in the table
+        below) and a "xxx-supported" attribute.  If the Printer object
+        doesn't support "xxx", then it MUST support neither an "xxx-
+        default" attribute nor an "xxx-supported" attribute, and it MUST
+        treat an attribute "xxx" supplied by a client as unsupported.
+        An attribute "xxx" may be supported for some document formats
+        and not supported for other document formats.  For example, it
+        is expected that a Printer object would only support
+        "orientation-requested" for some document formats (such as '
+        text/plain' or 'text/html') but not others (such as '
+        application/postscript').
+
+
+
+
+deBry, et al.                 Experimental                     [Page 70]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     2. "xxx" is OPTIONALLY supplied by the client in a create request.
+        If "xxx" is supplied, the client is indicating a desired job
+        processing behavior for this Job.  When "xxx" is not supplied,
+        the client is indicating that the Printer object apply its
+        default job processing behavior at job processing time if the
+        document content does not contain an embedded instruction
+        indicating an xxx-related behavior.
+
+        Note: Since an administrator MAY change the default value
+        attribute after a Job object has been submitted but before it
+        has been processed, the default value used by the Printer object
+        at job processing time may be different that the default value
+        in effect at job submission time.
+
+     3. The "xxx-supported" attribute is a Printer object attribute that
+        describes which job processing behaviors are supported by that
+        Printer object.  A client can query the Printer object to find
+        out what xxx-related behaviors are supported by inspecting the
+        returned values of the "xxx-supported" attribute.
+
+        Note: The "xxx" in each "xxx-supported" attribute name is
+        singular, even though an "xxx-supported" attribute usually has
+        more than one value, such as "job-sheet-supported", unless the
+        "xxx" Job Template attribute is plural, such as "finishings" or
+        "sides".  In such cases the "xxx-supported" attribute names are:
+        "finishings-supported" and "sides-supported".
+
+     4. The "xxx-default" default value attribute describes what will be
+        done at job processing time when no other job processing
+        information is supplied by the client (either explicitly as an
+        IPP attribute in the create request or implicitly as an embedded
+        instruction within the document data).
+
+   If an application wishes to present an end user with a list of
+   supported values from which to choose, the application SHOULD query
+   the Printer object for its supported value attributes.  The
+   application SHOULD also query the default value attributes.  If the
+   application then limits selectable values to only those value that
+   are supported, the application can guarantee that the values supplied
+   by the client in the create request all fall within the set of
+   supported values at the Printer.  When querying the Printer, the
+   client MAY enumerate each attribute by name in the Get-Printer-
+   Attributes Request, or the client MAY just name the "job-template"
+   group in order to get the complete set of supported attributes (both
+   supported and default attributes).
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 71]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   The "finishings" attribute is an example of a Job Template attribute.
+   It can take on a set of values such as 'staple', 'punch', and/or '
+   cover'.  A client can query the Printer object for the "finishings-
+   supported" attribute and the "finishings-default" attribute.  The
+   supported attribute contains a set of supported values.  The default
+   value attribute contains the finishing value(s) that will be used for
+   a new Job if the client does not supply a "finishings" attribute in
+   the create request and the document data does not contain any
+   corresponding finishing instructions.  If the client does supply the
+   "finishings" attribute in the create request, the IPP object
+   validates the value or values to make sure that they are a subset of
+   the supported values identified in the Printer object's "finishings-
+   supported" attribute.  See section 3.2.1.2.
+
+   The table below summarizes the names and relationships for all Job
+   Template attributes. The first column of the table (labeled "Job
+   Attribute") shows the name and syntax for each Job Template attribute
+   in the Job object. These are the attributes that can optionally be
+   supplied by the client in a create request.   The last two columns
+   (labeled "Printer: Default Value Attribute" and "Printer: Supported
+   Values Attribute") shows the name and syntax for each Job Template
+   attribute in the Printer object (the default value attribute and the
+   supported values attribute).  A "No" in the table means the Printer
+   MUST NOT support the attribute (that is, the attribute is simply not
+   applicable).  For brevity in the table, the 'text' and 'name' entries
+   do not show the maximum length for each attribute.
+
+     +===================+======================+======================+
+     | Job Attribute     |Printer: Default Value|  Printer: Supported  |
+     |                   |   Attribute          |   Values Attribute   |
+     +===================+======================+======================+
+     | job-priority      | job-priority-default |job-priority-supported|
+     | (integer 1:100)   | (integer 1:100)      |(integer 1:100)       |
+     +-------------------+----------------------+----------------------+
+     | job-hold-until    | job-hold-until-      |job-hold-until-       |
+     | (type3 keyword |  |  default             | supported            |
+     |    name)          |  (type3 keyword |    |(1setOf               |
+     |                   |    name)             | type3 keyword | name)|
+     +-------------------+----------------------+----------------------+
+     | job-sheets        | job-sheets-default   |job-sheets-supported  |
+     | (type3 keyword |  | (type3 keyword |     |(1setOf               |
+     |    name)          |    name)             | type3 keyword | name)|
+     +-------------------+----------------------+----------------------+
+     |multiple-document- |multiple-document-    |multiple-document-    |
+     | handling          | handling-default     |handling-supported    |
+     | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
+     +-------------------+----------------------+----------------------+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 72]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     +===================+======================+======================+
+     | Job Attribute     |Printer: Default Value|  Printer: Supported  |
+     |                   |   Attribute          |   Values Attribute   |
+     +===================+======================+======================+
+     | copies            | copies-default       | copies-supported     |
+     | (integer (1:MAX)) | (integer (1:MAX))    | (rangeOfInteger      |
+     |                   |                      |       (1:MAX))       |
+     +-------------------+----------------------+----------------------+
+     | finishings        | finishings-default   | finishings-supported |
+     |(1setOf type2 enum)|(1setOf type2 enum)   |(1setOf type2 enum)   |
+     +-------------------+----------------------+----------------------+
+     | page-ranges       | No                   | page-ranges-         |
+     | (1setOf           |                      | supported (boolean)  |
+     |   rangeOfInteger  |                      |                      |
+     |        (1:MAX))   |                      |                      |
+     +-------------------+----------------------+----------------------+
+     | sides             | sides-default        | sides-supported      |
+     | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
+     +-------------------+----------------------+----------------------+
+     | number-up         | number-up-default    | number-up-supported  |
+     | (integer (1:MAX)) | (integer (1:MAX))    |(1setOf integer       |
+     |                   |                      | (1:MAX) |            |
+     |                   |                      |  rangeOfInteger      |
+     |                   |                      |   (1:MAX))           |
+     +-------------------+----------------------+----------------------+
+     | orientation-      |orientation-requested-|orientation-requested-|
+     |  requested        |  default             |  supported           |
+     |   (type2 enum)    |  (type2 enum)        |  (1setOf type2 enum) |
+     +-------------------+----------------------+----------------------+
+     | media             | media-default        | media-supported      |
+     | (type3 keyword |  | (type3 keyword |     |(1setOf               |
+     |    name)          |    name)             | type3 keyword | name)|
+     |                   |                      |                      |
+     |                   |                      | media-ready          |
+     |                   |                      |(1setOf               |
+     |                   |                      | type3 keyword | name)|
+     +-------------------+----------------------+----------------------+
+     | printer-resolution| printer-resolution-  | printer-resolution-  |
+     | (resolution)      |  default             | supported            |
+     |                   | (resolution)         |(1setOf resolution)   |
+     +-------------------+----------------------+----------------------+
+     | print-quality     | print-quality-default| print-quality-       |
+     | (type2 enum)      | (type2 enum)         | supported            |
+     |                   |                      |(1setOf type2 enum)   |
+     +-------------------+----------------------+----------------------+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 73]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.2.1 job-priority (integer(1:100))
+
+   This attribute specifies a priority for scheduling the Job. A higher
+   value specifies a higher priority. The value 1 indicates the lowest
+   possible priority. The value 100 indicates the highest possible
+   priority.  Among those jobs that are ready to print, a Printer MUST
+   print all jobs with a priority value of n before printing those with
+   a priority value of n-1 for all n.
+
+   If the Printer object supports this attribute, it MUST always support
+   the full range from 1 to 100.  No administrative restrictions are
+   permitted.  This way an end-user can always make full use of the
+   entire range with any Printer object.  If privileged jobs are
+   implemented outside IPP/1.0, they MUST have priorities higher than
+   100, rather than restricting the range available to end-users.
+
+   If the client does not supply this attribute and this attribute is
+   supported by the Printer object, the Printer object MUST use the
+   value of the Printer object's "job-priority-default" at job
+   submission time (unlike most Job Template attributes that are used if
+   necessary at job processing time).
+
+   The syntax for the "job-priority-supported" is also integer(1:100).
+   This single integer value indicates the number of priority levels
+   supported.  The Printer object MUST take the value supplied by the
+   client and map it to the closest integer in a sequence of n integers
+   values that are evenly distributed over the range from 1 to 100 using
+   the formula:
+
+        roundToNearestInt((100x+50)/n)
+
+   where n is the value of "job-priority-supported" and x ranges from 0
+   through n-1.
+
+   For example, if n=1 the sequence of values is 50;  if n=2, the
+   sequence of values is:  25 and 75;  if n = 3, the sequence of values
+   is:  17, 50 and 83;  if n = 10, the sequence of values is: 5, 15, 25,
+   35, 45, 55, 65, 75, 85, and 95;  if n = 100, the sequence of values
+   is:  1, 2, 3, .  100.
+
+   If the value of the Printer object's "job-priority-supported" is 10
+   and the client supplies values in the range 1 to 10, the Printer
+   object maps them to 5, in the range 11 to 20, the Printer object maps
+   them to 15, etc.
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 74]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.2.2 job-hold-until (type3 keyword | name (MAX))
+
+   This attribute specifies the named time period during which the Job
+   MUST become a candidate for printing.
+
+   Standard keyword values for named time periods are:
+
+     'no-hold': immediately, if there are not other reasons to hold the
+        job
+     'day-time': during the day
+     'evening': evening
+     'night': night
+     'weekend': weekend
+     'second-shift': second-shift (after close of business)
+     'third-shift': third-shift (after midnight)
+
+   An administrator MUST associate allowable print times with a named
+   time period (by means outside IPP/1.0).  An administrator is
+   encouraged to pick names that suggest the type of time period. An
+   administrator MAY define additional values using the 'name' or '
+   keyword' attribute syntax, depending on implementation.
+
+   If the value of this attribute specifies a time period that is in the
+   future, the Printer MUST add the 'job-hold-until-specified' value to
+   the job's "job-state-reasons" attribute, move the job to the '
+   pending-held' state, and MUST NOT schedule the job for printing until
+   the specified time-period arrives.  When the specified time period
+   arrives, the Printer MUST remove the 'job-hold-until-specified' value
+   from the job's "job-state-reason" attribute and, if there are no
+   other job state reasons that keep the job in the 'pending-held'
+   state, the Printer MUST consider the job as a candidate for
+   processing by moving the job to the 'pending' state.
+
+   If this job attribute value is the named value 'no-hold', or the
+   specified time period has already started, the job MUST be a
+   candidate for processing immediately.
+
+   If the client does not supply this attribute and this attribute is
+   supported by the Printer object, the Printer object MUST use the
+   value of the Printer object's "job-hold-until-default" at job
+   submission time (unlike most Job Template attributes that are used if
+   necessary at job processing time).
+
+4.2.3 job-sheets (type3 keyword | name(MAX))
+
+   This attribute determines which job start/end sheet(s), if any, MUST
+   be printed with a job.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 75]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Standard keyword values are:
+
+     'none': no job sheet is printed
+     'standard': one or more site specific standard job sheets are
+        printed, e.g. a single start sheet or both start and end sheet
+        is printed
+
+   An administrator MAY define additional values using the 'name' or '
+   keyword' attribute syntax, depending on implementation.
+
+   Note: The effect of this attribute on jobs with multiple documents
+   MAY be affected by the "multiple-document-handling" job attribute
+   (section 4.2.4), depending on the job sheet semantics.
+
+4.2.4 multiple-document-handling (type2 keyword)
+
+   This attribute is relevant only if a job consists of two or more
+   documents. The attribute controls finishing operations and the
+   placement of one or more print-stream pages into impressions and onto
+   media sheets.  When the value of the "copies" attribute exceeds 1, it
+   also controls the order in which the copies that result from
+   processing the documents are produced. For the purposes of this
+   explanations, if "a" represents an instance of document data, then
+   the result of processing the data in document "a" is a sequence of
+   media sheets represented by "a(*)".
+
+   Standard keyword values are:
+
+     'single-document': If a Job object has multiple documents, say, the
+        document data is called a and b, then the result of processing
+        all the document data (a and then b) MUST be treated as a single
+        sequence of media sheets for finishing operations; that is,
+        finishing would be performed on the concatenation of the
+        sequences a(*),b(*).  The Printer object MUST NOT force the data
+        in each document instance to be formatted onto a new print-
+        stream page, nor to start a new impression on a new media sheet.
+        If more than one copy is made, the ordering of the sets of media
+        sheets resulting from processing the document data MUST be a(*),
+        b(*), a(*), b(*), ..., and the Printer object MUST force each
+        copy (a(*),b(*)) to start on a new media sheet.
+     'separate-documents-uncollated-copies': If a Job object has
+        multiple documents, say, the document data is called a and b,
+        then the result of processing the data in each document instance
+        MUST be treated as a single sequence of media sheets for
+        finishing operations; that is, the sets a(*) and b(*) would each
+        be finished separately. The Printer object MUST force each copy
+        of the result of processing the data in a single document to
+        start on a new media sheet. If more than one copy is made, the
+
+
+
+deBry, et al.                 Experimental                     [Page 76]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        ordering of the sets of media sheets resulting from processing
+        the document data MUST be a(*), a(*), ..., b(*), b(*) ... .
+     'separate-documents-collated-copies': If a Job object has multiple
+        documents, say, the document data is called a and b, then the
+        result of processing the data in each document instance MUST be
+        treated as a single sequence of media sheets for finishing
+        operations; that is, the sets a(*) and b(*) would each be
+        finished separately. The Printer object MUST force each copy of
+        the result of processing the data in a single document to start
+        on a new media sheet.  If more than one copy is made, the
+        ordering of the sets of media sheets resulting from processing
+        the document data MUST be a(*), b(*), a(*), b(*), ... .
+     'single-document-new-sheet':  Same as 'single-document', except
+        that the Printer object MUST ensure that the first impression of
+        each document instance in the job is placed on a new media
+        sheet.  This value allows multiple documents to be stapled
+        together with a single staple where each document starts on a
+        new sheet.
+
+   The 'single-document' value is the same as 'separate-documents-
+   collated-copies' with respect to ordering of print-stream pages, but
+   not media sheet generation, since 'single-document' will put the
+   first page of the next document on the back side of a sheet if an odd
+   number of pages have been produced so far for the job, while '
+   separate-documents-collated-copies' always forces the next document
+   or document copy on to a new sheet.  In addition, if the "finishings"
+   attribute specifies 'staple', then with 'single-document', documents
+   a and b are stapled together as a single document with no regard to
+   new sheets, with 'single-document-new-sheet', documents a and b are
+   stapled together as a single document, but document b starts on a new
+   sheet, but with 'separate-documents-uncollated-copies' and '
+   separate-documents-collated-copies', documents a and b are stapled
+   separately.
+
+   Note: None of these values provide means to produce uncollated sheets
+   within a document, i.e., where multiple copies of sheet n are
+   produced before sheet n+1 of the same document.
+
+   The relationship of this attribute and the other attributes that
+   control document processing is described in section 15.3.
+
+4.2.5 copies (integer(1:MAX))
+
+   This attribute specifies the number of copies to be printed.
+
+   On many devices the supported number of collated copies will be
+   limited by the number of physical output bins on the device, and may
+   be different from the number of uncollated copies which can be
+
+
+
+deBry, et al.                 Experimental                     [Page 77]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   supported.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.6 finishings (1setOf type2 enum)
+
+   This attribute identifies the finishing operations that the Printer
+   uses for each copy of each printed document in the Job. For Jobs with
+   multiple documents, the "multiple-document-handling" attribute
+   determines what constitutes a "copy" for purposes of finishing.
+
+   Standard enum values are:
+
+     Value  Symbolic Name and Description
+
+     '3'    'none':  Perform no finishing
+     '4'    'staple':  Bind the document(s) with one or more staples.
+                  The exact number and placement of the staples is
+                  site-defined.
+     '5'    'punch':  This value indicates that holes are required in
+                  the finished document. The exact number and placement
+                  of the holes is site-defined  The punch specification
+                  MAY be satisfied (in a site- and implementation-
+                  specific manner) either by drilling/punching, or by
+                  substituting pre-drilled media.
+     '6'    'cover':  This value is specified when it is desired to
+                  select a non-printed (or pre-printed) cover for the
+                  document.  This does not supplant the specification of
+                  a printed cover (on cover stock medium) by the
+                  document itself.
+     '7'    'bind':  This value indicates that a binding is to be
+                  applied to the document; the type and placement of the
+                  binding is site-defined."
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+   If the client supplies a value of 'none' along with any other
+   combination of values, it is the same as if only that other
+   combination of values had been supplied (that is the 'none' value has
+   no effect).
+
+
+
+deBry, et al.                 Experimental                     [Page 78]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX))
+
+   This attribute identifies the range(s) of print-stream pages that the
+   Printer object uses for each copy of each document which are to be
+   printed.  Nothing is printed for any pages identified that do not
+   exist in the document(s).  Ranges MUST be in ascending order, for
+   example: 1-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling
+   Printer object can process the job in a single pass.  If the ranges
+   are not ascending or are overlapping, the IPP object MUST reject the
+   request and return the 'client-error-bad-request' status code.  The
+   attribute is associated with print-stream pages not application-
+   numbered pages (for example, the page numbers found in the headers
+   and or footers for certain word processing applications).
+
+   For Jobs with multiple documents, the "multiple-document-handling"
+   attribute determines what constitutes a "copy" for purposes of the
+   specified page range(s).  When "multiple-document-handling" is '
+   single-document', the Printer object MUST apply each supplied page
+   range once to the concatenation of the print-stream pages.  For
+   example, if there are 8 documents of 10 pages each, the page-range '
+   41:60' prints the pages in the 5th and 6th documents as a single
+   document and none of the pages of the other documents are printed.
+   When "multiple-document-handling" is 'separate-documents-uncollated-
+   copies' or 'separate-documents-collated-copies', the Printer object
+   MUST apply each supplied page range repeatedly to each document copy.
+   For the same job, the page-range '1:3, 10:10' would print the first 3
+   pages and the 10th page of each of the 8 documents in the Job, as 8
+   separate documents.
+
+   In most cases, the exact pages to be printed will be generated by a
+   device driver and this attribute would not be required.  However,
+   when printing an archived document which has already been formatted,
+   the end user may elect to print just a subset of the pages contained
+   in the document.  In this case, if page-range = n.m is specified, the
+   first page to be printed will be page n. All subsequent pages of the
+   document will be printed through and including page m.
+
+   "page-ranges-supported" is a boolean value indicating whether or not
+   the printer is capable of supporting the printing of page ranges.
+   This capability may differ from one PDL to another. There is no
+   "page-ranges-default" attribute.  If the "page-ranges" attribute is
+   not supplied by the client, all pages of the document will be
+   printed.
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 79]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.8 sides (type2 keyword)
+
+   This attribute specifies how print-stream pages are to be imposed
+   upon the sides of an instance of a selected medium, i.e., an
+   impression.
+
+   The standard keyword values are:
+
+     'one-sided': imposes each consecutive print-stream page upon the
+        same side of consecutive media sheets.
+     'two-sided-long-edge': imposes each consecutive pair of print-
+        stream pages upon front and back sides of consecutive media
+        sheets, such that the orientation of each pair of print-stream
+        pages on the medium would be correct for the reader as if for
+        binding on the long edge.  This imposition is sometimes called '
+        duplex' or 'head-to-head'.
+     'two-sided-short-edge': imposes each consecutive pair of print-
+        stream pages upon front and back sides of consecutive media
+        sheets, such that the orientation of each pair of print-stream
+        pages on the medium would be correct for the reader as if for
+        binding on the short edge.  This imposition is sometimes called
+        'tumble' or 'head-to-toe'.
+
+   'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex'
+   all work the same for portrait or landscape.  However 'head-to-toe'
+   is 'tumble' in portrait but 'duplex' in landscape.  'head-to-head'
+   also switches between 'duplex' and 'tumble' when using portrait and
+   landscape modes.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.9 number-up (integer(1:MAX))
+
+   This attribute specifies the number of print-stream pages to impose
+   upon a single side of an instance of a selected medium.  For example,
+   if the value is:
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 80]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     Value  Description
+
+     '1'    the Printer MUST place one print-stream page on a single
+                  side of an instance of the selected medium (MAY add
+                  some sort of translation, scaling, or rotation).
+     '2'    the Printer MUST place two print-stream pages on a single
+                  side of an instance of the selected medium (MAY add
+                  some sort of translation, scaling, or rotation).
+     '4'    the Printer MUST place four print-stream pages on a single
+                  side of an instance of the selected medium (MAY add
+                  some sort of translation, scaling, or rotation).
+
+   This attribute primarily controls the translation, scaling and
+   rotation of print-stream pages.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.10 orientation-requested (type2 enum)
+
+   This attribute indicates the desired orientation for printed print-
+   stream pages; it does not describe the orientation of the client-
+   supplied print-stream pages.
+
+   For some document formats (such as 'application/postscript'), the
+   desired orientation of the print-stream pages is specified within the
+   document data.  This information is generated by a device driver
+   prior to the submission of the print job.  Other document formats
+   (such as 'text/plain') do not include the notion of desired
+   orientation within the document data.  In the latter case it is
+   possible for the Printer object to bind the desired orientation to
+   the document data after it has been submitted.  It is expected that a
+   Printer object would only support "orientations-requested" for some
+   document formats (e.g., 'text/plain' or 'text/html') but not others
+   (e.g., 'application/postscript').  This is no different than any
+   other Job Template attribute since section 4.2, item 1, points out
+   that a Printer object may support or not support any Job Template
+   attribute based on the document format supplied by the client.
+   However, a special mention is made here since it is very likely that
+   a Printer object will support "orientation-requested" for only a
+   subset of the supported document formats.
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 81]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Standard enum values are:
+
+     Value  Symbolic Name and Description
+
+     '3'    'portrait':  The content will be imaged across the short
+                  edge of the medium.
+     '4'    'landscape':  The content will be imaged across the long
+                  edge of the medium.  Landscape is defined to be a
+                  rotation of the print-stream page to be imaged by +90
+                  degrees with respect to the medium (i.e. anti-
+                  clockwise) from the portrait orientation.  Note:  The
+                  +90 direction was chosen because simple finishing on
+                  the long edge is the same edge whether portrait or
+                  landscape
+     '5'    'reverse-landscape':  The content will be imaged across the
+                  long edge of the medium.  Reverse-landscape is defined
+                  to be a rotation of the print-stream page to be imaged
+                  by - 90 degrees with respect to the medium (i.e.
+                  clockwise) from the portrait orientation.  Note: The '
+                  reverse-landscape' value was added because some
+                  applications rotate landscape -90 degrees from
+                  portrait, rather than +90 degrees.
+     '6'    'reverse-portrait':  The content will be imaged across the
+                  short edge of the medium.  Reverse-portrait is defined
+                  to be a rotation of the print-stream page to be imaged
+                  by 180 degrees with respect to the medium from the
+                  portrait orientation.  Note: The 'reverse-portrait'
+                  value was added for use with the "finishings"
+                  attribute in cases where the opposite edge is desired
+                  for finishing a portrait document on simple finishing
+                  devices that have only one finishing position.  Thus a
+                  'text'/plain' portrait document can be stapled "on the
+                  right" by a simple finishing device as is common use
+                  with some middle eastern languages such as Hebrew.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.11 media (type3 keyword | name(MAX))
+
+   This attribute identifies the medium that the Printer uses for all
+   impressions of the Job.
+
+   The values for "media" include medium-names, medium-sizes, input-
+   trays and electronic forms so that one attribute specifies the media.
+
+
+
+deBry, et al.                 Experimental                     [Page 82]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   If a Printer object supports a medium name as a value of this
+   attribute, such a medium name implicitly selects an input-tray that
+   contains the specified medium.  If a Printer object supports a medium
+   size as a value of this attribute, such a medium size implicitly
+   selects a medium name that in turn implicitly selects an input-tray
+   that contains the medium with the specified size.  If a Printer
+   object supports an input-tray as the value of this attribute, such an
+   input-tray implicitly selects the medium that is in that input-tray
+   at the time the job prints.  This case includes manual-feed input-
+   trays.  If a Printer object supports an electronic form as the value
+   of this attribute, such an electronic form implicitly selects a
+   medium-name that in turn implicitly selects an input-tray that
+   contains the medium specified by the electronic form.  The electronic
+   form also implicitly selects an image that the Printer MUST merge
+   with the document data as its prints each page.
+
+   Standard keyword values are (taken from ISO DPA and the Printer MIB)
+   and are listed in section 14. An administrator MAY define additional
+   values using the 'name' or 'keyword' attribute syntax, depending on
+   implementation.
+
+   There is also an additional Printer attribute named "media-ready"
+   which differs from "media-supported" in that legal values only
+   include the subset of "media-supported" values that are physically
+   loaded and ready for printing with no operator intervention required.
+   If an IPP object supports "media-supported", it NEED NOT support
+   "media-ready".
+
+   The relationship of this attribute and the other attributes that
+   control document processing is described in section 15.3.
+
+4.2.12 printer-resolution (resolution)
+
+   This attribute identifies the resolution that Printer uses for the
+   Job.
+
+4.2.13 print-quality (type2 enum)
+
+   This attribute specifies the print quality that the Printer uses for
+   the Job.
+
+   The standard enum values are:
+
+     Value  Symbolic Name and Description
+
+     '3'    'draft': lowest quality available on the printer
+     '4'    'normal': normal or intermediate quality on the printer
+     '5'    'high': highest quality available on the printer
+
+
+
+deBry, et al.                 Experimental                     [Page 83]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.3 Job Description Attributes
+
+   The attributes in this section form the attribute group called "job-
+   description".  The following table summarizes these attributes.  The
+   third column indicates whether the attribute is a REQUIRED attribute
+   that MUST be supported by Printer objects.  If it is not indicated as
+   REQUIRED, then it is OPTIONAL.  The maximum size in octets for 'text'
+   and 'name' attributes is indicated in parenthesizes.
+
+   +----------------------------+----------------------+----------------+
+   |      Attribute             |     Syntax           |   REQUIRED?    |
+   +----------------------------+----------------------+----------------+
+   | job-uri                    | uri                  |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+   | job-id                     | integer(1:MAX)       |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+   | job-printer-uri            | uri                  |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+   | job-more-info              | uri                  |                |
+   +----------------------------+----------------------+----------------+
+   | job-name                   | name (MAX)           |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+   | job-originating-user-name  | name (MAX)           |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+   | job-state                  | type1 enum           |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+   | job-state-reasons          | 1setOf type2 keyword |                |
+   +----------------------------+----------------------+----------------+
+   | job-state-message          | text (MAX)           |                |
+   +----------------------------+----------------------+----------------+
+   | number-of-documents        | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | output-device-assigned     | name (127)           |                |
+   +----------------------------+----------------------+----------------+
+   | time-at-creation           | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | time-at-processing         | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | time-at-completed          | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | number-of-intervening-jobs | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | job-message-from-operator  | text (127)           |                |
+   +----------------------------+----------------------+----------------+
+   | job-k-octets               | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | job-impressions            | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+
+
+
+deBry, et al.                 Experimental                     [Page 84]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   +----------------------------+----------------------+----------------+
+   |      Attribute             |     Syntax           |   REQUIRED?    |
+   +----------------------------+----------------------+----------------+
+   | job-media-sheets           | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | job-k-octets-processed     | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | job-impressions-completed  | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | job-media-sheets-completed | integer (0:MAX)      |                |
+   +----------------------------+----------------------+----------------+
+   | attributes-charset         | charset              |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+   | attributes-natural-language| naturalLanguage      |  REQUIRED      |
+   +----------------------------+----------------------+----------------+
+
+
+4.3.1 job-uri (uri)
+
+   This REQUIRED attribute contains the URI for the job.  The Printer
+   object, on receipt of a new job, generates a URI which identifies the
+   new Job.  The Printer object returns the value of the "job-uri"
+   attribute as part of the response to a create request.  The precise
+   format of a Job URI is implementation dependent.  If the Printer
+   object supports more than one URI and there is some relationship
+   between the newly formed Job URI and the Printer object's URI, the
+   Printer object uses the Printer URI supplied by the client in the
+   create request.  For example, if the create request comes in over a
+   secure channel, the new Job URI MUST use the same secure channel.
+   This can be guaranteed because the Printer object is responsible for
+   generating the Job URI and the Printer object is aware of its
+   security configuration and policy as well as the Printer URI used in
+   the create request.
+
+   For a description of this attribute and its relationship to "job-id"
+   and "job-printer-uri" attribute, see the discussion in section 2.4 on
+   "Object Identity".
+
+4.3.2 job-id (integer(1:MAX))
+
+   This REQUIRED attribute contains the ID of the job.  The Printer, on
+   receipt of a new job, generates an ID which identifies the new Job on
+   that Printer.  The Printer returns the value of the "job-id"
+   attribute as part of the response to a create request.  The 0 value
+   is not included to allow for compatibility with SNMP index values
+   which also cannot be 0.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 85]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   For a description of this attribute and its relationship to "job-uri"
+   and "job-printer-uri" attribute, see the discussion in section 2.4 on
+   "Object Identity".
+
+4.3.3 job-printer-uri (uri)
+
+   This REQUIRED attribute identifies the Printer object that created
+   this Job object.  When a Printer object creates a Job object, it
+   populates this attribute with the Printer object URI that was used in
+   the create request.  This attribute permits a client to identify the
+   Printer object that created this Job object when only the Job
+   object's URI is available to the client.  The client queries the
+   creating Printer object to determine which languages, charsets,
+   operations, are supported for this Job.
+
+   For a description of this attribute and its relationship to "job-uri"
+   and "job-id" attribute, see the discussion in section 2.4 on "Object
+   Identity".
+
+4.3.4 job-more-info (uri)
+
+   Similar to "printer-more-info", this attribute contains the URI
+   referencing some resource with more information about this Job
+   object, perhaps an HTML page containing information about the Job.
+
+4.3.5 job-name (name(MAX))
+
+   This REQUIRED attribute is the name of the job.  It is a name that is
+   more user friendly than the "job-uri" attribute value.  It does not
+   need to be unique between Jobs.  The Job's "job-name" attribute is
+   set to the value supplied by the client in the "job-name" operation
+   attribute in the create request (see Section 3.2.1.1).   If, however,
+   the "job-name" operation attribute is not supplied by the client in
+   the create request, the Printer object, on creation of the Job, MUST
+   generate a name.  The printer SHOULD generate the value of the Job's
+   "job-name" attribute from the first of the following sources that
+   produces a value: 1) the "document-name" operation attribute of the
+   first (or only) document, 2) the "document-URI" attribute of the
+   first (or only) document, or 3) any other piece of Job specific
+   and/or Document Content information.
+
+4.3.6 job-originating-user-name (name(MAX))
+
+   This REQUIRED attribute contains the name of the end user that
+   submitted the print job.  The Printer object sets this attribute to
+   the most authenticated printable name that it can obtain from the
+   authentication service over which the IPP operation was received.
+
+
+
+
+deBry, et al.                 Experimental                     [Page 86]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Only if such is not available, does the Printer object use the value
+   supplied by the client in the "requesting-user-name" operation
+   attribute of the create operation (see Section 8).
+
+   Note:  The Printer object needs to keep an internal originating user
+   id of some form, typically as a credential of a principal, with the
+   Job object.  Since such an internal attribute is implementation-
+   dependent and not of interest to clients, it is not specified as a
+   Job Description attribute.  This originating user id is used for
+   authorization checks (if any) on all subsequent operation.
+
+4.3.7 job-state (type1 enum)
+
+   This REQUIRED attribute identifies the current state of the job.
+   Even though the IPP protocol defines eight values for job states,
+   implementations only need to support those states which are
+   appropriate for the particular implementation.  In other words, a
+   Printer supports only those job states implemented by the output
+   device and available to the Printer object implementation.
+
+   Standard enum values are:
+
+     Values Symbolic Name and Description
+
+     '3'    'pending':  The job is a candidate to start processing, but
+                  is not yet processing.
+
+     '4'    'pending-held':  The job is not a candidate for processing
+                  for any number of reasons but will return to the '
+                  pending' state as soon as the reasons are no longer
+                  present.  The job's "job-state-reason" attribute MUST
+                  indicate why the job is no longer a candidate for
+                  processing.
+
+     '5'    'processing':  One or more of:
+
+                  1.  the job is using, or is attempting to use, one or
+                  more purely software processes that are analyzing,
+                  creating, or interpreting a PDL, etc.,
+                  2.  the job is using, or is attempting to use, one or
+                  more hardware devices that are interpreting a PDL,
+                  making marks on a medium, and/or performing finishing,
+                  such as stapling, etc.,
+                  3. the Printer object has made the job ready for
+                  printing, but the output device is not yet printing
+                  it, either because the job hasn't reached the output
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 87]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+                  device or because the job is queued in the output
+                  device or some other spooler, awaiting the output
+                  device to print it.
+
+                  When the job is in the 'processing' state, the entire
+                  job state includes the detailed status represented in
+                  the printer's "printer-state", "printer-state-
+                  reasons", and "printer-state-message" attributes.
+
+                  Implementations MAY, though they NEED NOT,  include
+                  additional values in the job's "job-state-reasons"
+                  attribute to indicate the progress of the job, such as
+                  adding the 'job-printing' value to indicate when the
+                  output device is actually making marks on paper and/or
+                  the 'processing-to-stop-point' value to indicate that
+                  the IPP object is in the process of canceling or
+                  aborting the job.  Most implementations won't bother
+                  with this nuance.
+
+     '6'    'processing-stopped':  The job has stopped while processing
+                  for any number of reasons and will return to the '
+                  processing' state as soon as the reasons are no longer
+                  present.
+
+                  The job's "job-state-reason" attribute MAY indicate
+                  why the job has stopped processing.  For example, if
+                  the output device is stopped, the 'printer-stopped'
+                  value MAY be included in the job's "job-state-reasons"
+                  attribute.
+
+                  Note:  When an output device is stopped, the device
+                  usually indicates its condition in human readable form
+                  locally at the device.  A client can obtain more
+                  complete device status remotely by querying the
+                  Printer object's "printer-state", "printer-state-
+                  reasons" and "printer-state-message" attributes.
+
+     '7'    'canceled':  The job has been canceled by a Cancel-Job
+                  operation and the Printer object has completed
+                  canceling the job and all job status attributes have
+                  reached their final values for the job.  While the
+                  Printer object is canceling the job, the job remains
+                  in its current state, but the job's "job-state-
+                  reasons" attribute SHOULD contain the 'processing-to-
+                  stop-point' value and one of the 'canceled-by-user', '
+                  canceled-by-operator', or 'canceled-at-device' value.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 88]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+                  When the job moves to the 'canceled' state, the '
+                  processing-to-stop-point' value, if present, MUST be
+                  removed, but the 'canceled-by-xxx', if present, MUST
+                  remain.
+
+     '8'    'aborted':  The job has been aborted by the system, usually
+                  while the job was in the 'processing' or 'processing-
+                  stopped' state and the Printer has completed aborting
+                  the job and all job status attributes have reached
+                  their final values for the job.  While the Printer
+                  object is aborting the job, the job remains in its
+                  current state, but the job's "job-state-reasons"
+                  attribute SHOULD contain the 'processing-to-stop-
+                  point' and 'aborted-by-system' values.  When the job
+                  moves to the 'aborted' state, the  'processing-to-
+                  stop-point' value, if present, MUST be removed, but
+                  the 'aborted-by-system' value, if present, MUST
+                  remain.
+
+     '9'    'completed':  The job has completed successfully or with
+                  warnings or errors after processing and all of the job
+                  media sheets have been successfully stacked in the
+                  appropriate output bin(s) and all job status
+                  attributes have reached their final values for the
+                  job.  The job's "job-state-reasons" attribute SHOULD
+                  contain one of:  'completed-successfully', '
+                  completed-with-warnings', or 'completed-with-errors'
+                  values.
+
+   The final value for this attribute MUST be one of: 'completed', '
+   canceled', or 'aborted' before the Printer removes the job
+   altogether.  The length of time that jobs remain in the 'canceled', '
+   aborted', and 'completed' states depends on implementation.
+
+   The following figure shows the normal job state transitions.
+
+                                                      +----> canceled
+                                                     /
+       +----> pending --------> processing ---------+------> completed
+       |         ^                   ^               \
+   --->+         |                   |                +----> aborted
+       |         v                   v               /
+       +----> pending-held    processing-stopped ---+
+
+   Normally a job progresses from left to right.  Other state
+   transitions are unlikely, but are not forbidden.  Not shown are the
+   transitions to the 'canceled' state from the 'pending', 'pending-
+   held', and 'processing-stopped' states.
+
+
+
+deBry, et al.                 Experimental                     [Page 89]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Jobs reach one of the three terminal states: 'completed', 'canceled',
+   or 'aborted', after the jobs have completed all activity, including
+   stacking output media, after the jobs have completed all activity,
+   and all job status attributes have reached their final values for the
+   job.
+
+   Note: As with all other IPP attributes, if the implementation can not
+   determine the correct value for this attribute, it SHOULD respond
+   with the out-of-band value 'unknown' (see section 4.1) rather than
+   try to guess at some possibly incorrect value and give the end user
+   the wrong impression about the state of the Job object.  For example,
+   if the implementation is just a gateway into some printing system
+   that does not provide detailed status about the print job, the IPP
+   Job object's state might literally be 'unknown'.
+
+4.3.8 job-state-reasons (1setOf  type2 keyword)
+
+   This attribute provides additional information about the job's
+   current state, i.e., information that augments the value of the job's
+   "job-state" attribute.
+
+   Implementation of these values is OPTIONAL, i.e., a Printer NEED NOT
+   implement them, even if (1) the output device supports the
+   functionality represented by the reason and (2) is available to the
+   Printer object implementation.  These values MAY be used with any job
+   state or states for which the reason makes sense.  Furthermore, when
+   implemented, the Printer MUST return these values when the reason
+   applies and MUST NOT return them when the reason no longer applies
+   whether the value of the Job's "job-state" attribute changed or not.
+   When the Job does not have any reasons for being in its current
+   state, the value of the Job's "job-state-reasons" attribute MUST be '
+   none'.
+
+   Note: While values cannot be added to the 'job-state' attribute
+   without impacting deployed clients that take actions upon receiving
+   "job-state" values, it is the intent that additional "job-state-
+   reasons" values can be defined and registered without impacting such
+   deployed clients.  In other words, the "job-state-reasons" attribute
+   is intended to be extensible.
+
+   The following standard keyword values are defined.  For ease of
+   understanding, the values are presented in the order in which the
+   reasons are likely to occur (if implemented), starting with the '
+   job-incoming' value:
+
+     'none':  There are no reasons for the job's current state.
+     'job-incoming':  The Create-Job operation has been accepted by the
+        Printer, but the Printer is expecting additional Send-Document
+
+
+
+deBry, et al.                 Experimental                     [Page 90]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        and/or Send-URI operations and/or is accessing/accepting
+        document data.
+     'submission-interrupted':  The job was not completely submitted for
+        some unforeseen reason, such as: (1) the Printer has crashed
+        before the job was closed by the client, (2) the Printer or the
+        document transfer method has crashed in some non-recoverable way
+        before the document data was entirely transferred to the
+        Printer, (3) the client crashed or failed to close the job
+        before the time-out period.  See section 4.4.28.
+     'job-outgoing':  The Printer is transmitting the job to the output
+        device.
+     'job-hold-until-specified':  The value of the job's "job-hold-
+        until" attribute was specified with a time period that is still
+        in the future.  The job MUST NOT be a candidate for processing
+        until this reason is removed and there are no other reasons to
+        hold the job.
+     'resources-are-not-ready':  At least one of the resources needed by
+        the job, such as media, fonts, resource objects, etc., is not
+        ready on any of the physical printer's for which the job is a
+        candidate.  This condition MAY be detected when the job is
+        accepted, or subsequently while the job is pending or
+        processing, depending on implementation.  The job may remain in
+        its current state or be moved to the 'pending-held' state,
+        depending on implementation and/or job scheduling policy.
+     'printer-stopped-partly':  The value of the Printer's "printer-
+        state-reasons" attribute contains the value 'stopped-partly'.
+     'printer-stopped':  The value of the Printer's "printer-state"
+        attribute is 'stopped'.
+     'job-interpreting': Job is in the 'processing' state, but more
+        specifically, the Printer is interpreting the document data.
+     'job-queued': Job is in the 'processing' state, but more
+        specifically, the Printer has queued the document data.
+     'job-transforming': Job is in the 'processing' state, but more
+        specifically, the Printer is interpreting document data and
+        producing another electronic representation.
+     'job-printing':  The output device is marking media. This value is
+        useful for Printers which spend a great deal of time processing
+        (1) when no marking is happening and then want to show that
+        marking is now happening or (2) when the job is in the process
+        of being canceled or aborted while the job remains in the '
+        processing' state, but the marking has not yet stopped so that
+        impression or sheet counts are still increasing for the job.
+     'job-canceled-by-user':  The job was canceled by the owner of the
+        job using the Cancel-Job request, i.e., by a user whose
+        authenticated identity is the same as the value of the
+        originating user that created the Job object, or by some other
+        authorized end-user, such as a member of the job owner's
+        security group.
+
+
+
+deBry, et al.                 Experimental                     [Page 91]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'job-canceled-by-operator':  The job was canceled by the operator
+        using the Cancel-Job request, i.e., by a user who has been
+        authenticated as having operator privileges (whether local or
+        remote).  If the security policy is to allow anyone to cancel
+        anyone's job, then this value may be used when the job is
+        canceled by other than the owner of the job.  For such a
+        security policy, in effect, everyone is an operator as far as
+        canceling jobs with IPP is concerned.
+     'job-canceled-at-device':  The job was canceled by an unidentified
+        local user, i.e., a user at a console at the device.
+     'aborted-by-system':  The job (1) is in the process of being
+        aborted, (2) has been aborted by the system and placed in the '
+        aborted' state, or (3) has been aborted by the system and placed
+        in the 'pending-held' state, so that a user or operator can
+        manually try the job again.
+     'processing-to-stop-point':  The requester has issued a Cancel-Job
+        operation or the Printer object has aborted the job, but is
+        still performing some actions on the job until a specified stop
+        point occurs or job termination/cleanup is completed.
+
+        This reason is recommended to be used in conjunction with the '
+        processing' job state to indicate that the Printer object is
+        still performing some actions on the job while the job remains
+        in the 'processing' state.  After all the job's job description
+        attributes have stopped incrementing, the Printer object moves
+        the job from the 'processing' state to the 'canceled' or '
+        aborted' job states.
+
+     'service-off-line':  The Printer is off-line and accepting no jobs.
+        All 'pending' jobs are put into the 'pending-held' state.  This
+        situation could be true if the service's or document transform's
+        input is impaired or broken.
+     'job-completed-successfully':  The job completed successfully.
+     'job-completed-with-warnings':  The job completed with warnings.
+     'job-completed-with-errors':  The job completed with errors (and
+        possibly warnings too).
+
+4.3.9 job-state-message (text(MAX))
+
+   This attribute specifies information about the "job-state" and "job-
+   state-reasons" attributes in human readable text.  If the Printer
+   object supports this attribute, the Printer object MUST be able to
+   generate this message in any of the natural languages identified by
+   the Printer's "generated-natural-language-supported" attribute (see
+   the "attributes-natural-language" operation attribute specified in
+   Section 3.1.4.1).
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 92]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Note:  the value SHOULD NOT contain additional information not
+   contained in the values of the "job-state" and "job-states-reasons"
+   attributes, such as interpreter error information.  Otherwise,
+   application programs might attempt to parse the (localized text).
+   For such additional information such as interpreter errors for
+   application program consumption, a new attribute with keyword values,
+   needs to be developed and registered.
+
+4.3.10 number-of-documents (integer(0:MAX))
+
+   This attribute indicates the number of documents in the job, i.e.,
+   the number of Send-Document, Send-URI, Print-Job, or Print-URI
+   operations that the Printer has accepted for this job, regardless of
+   whether the document data has reached the Printer object or not.
+
+   Implementations supporting the OPTIONAL Create-Job/Send-
+   Document/Send-URI operations SHOULD support this attribute so that
+   clients can query the number of documents in each job.
+
+4.3.11 output-device-assigned (name(127))
+
+   This attribute identifies the output device to which the Printer
+   object has assigned this job.  If an output device implements an
+   embedded Printer object, the Printer object NEED NOT set this
+   attribute.  If a print server implements a Printer object, the value
+   MAY be empty (zero-length string) or not returned until the Printer
+   object assigns an output device to the job.  This attribute is
+   particularly useful when a single Printer object support multiple
+   devices (so called "fan-out").
+
+4.3.12 time-at-creation (integer(0:MAX))
+
+   This attribute indicates the point in time at which the Job object
+   was created.  In order to populate this attribute, the Printer object
+   uses the value in its "printer-up-time" attribute at the time the Job
+   object is created.
+
+4.3.13 time-at-processing (integer(0:MAX))
+
+   This attribute indicates the point in time at which the Job object
+   began processing.  In order to populate this attribute, the Printer
+   object uses the value in its "printer-up-time" attribute at the time
+   the Job object is moved into the 'processing' state for the first
+   time.
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 93]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.3.14 time-at-completed (integer(0:MAX))
+
+   This attribute indicates the point in time at which the Job object
+   completed (or was cancelled or aborted).  In order to populate this
+   attribute, the Printer object uses the value in its "printer-up-time"
+   attribute at the time the Job object is moved into the 'completed' or
+   'canceled' or 'aborted' state.
+
+4.3.15 number-of-intervening-jobs (integer(0:MAX))
+
+   This attribute indicates the number of jobs that are "ahead" of this
+   job in the relative chronological order of expected time to complete
+   (i.e., the current scheduled order). For efficiency, it is only
+   necessary to calculate this value when an operation is performed that
+   requests this attribute.
+
+4.3.16 job-message-from-operator (text(127))
+
+   This attribute provides a message from an operator, system
+   administrator or "intelligent" process to indicate to the end user
+   the reasons for modification or other management action taken on a
+   job.
+
+4.3.17 job-k-octets (integer(0:MAX))
+
+   This attribute specifies the total size of the document(s) in K
+   octets, i.e., in units of 1024 octets requested to be processed in
+   the job.  The value MUST be rounded up, so that a job between 1 and
+   1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2,
+   etc.
+
+   This value MUST NOT include the multiplicative factors contributed by
+   the number of copies specified by the "copies" attribute, independent
+   of whether the device can process multiple copies without making
+   multiple passes over the job or document data and independent of
+   whether the output is collated or not.  Thus the value is independent
+   of the implementation and indicates the size of the document(s)
+   measured in K octets independent of the number of copies.
+
+   This value MUST also not include the multiplicative factor due to a
+   copies instruction embedded in the document data.  If the document
+   data actually includes replications of the document data, this value
+   will include such replication.  In other words, this value is always
+   the size of the source document data, rather than a measure of the
+   hardcopy output to be produced.
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 94]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Note: This attribute and the following two attributes ("job-
+   impressions" and "job-media-sheets") are not intended to be counters;
+   they are intended to be useful routing and scheduling information if
+   known.  For these three attributes, the Printer object may try to
+   compute the value if it is not supplied in the create request.  Even
+   if the client does supply a value for these three attributes in the
+   create request, the Printer object MAY choose to change the value if
+   the Printer object is able to compute a value which is more accurate
+   than the client supplied value.  The Printer object may be able to
+   determine the correct value for these three attributes either right
+   at job submission time or at any later point in time.
+
+4.3.18 job-impressions (integer(0:MAX))
+
+   This attribute specifies the total size in number of impressions of
+   the document(s) being submitted (see the definition of impression in
+   section 13.2.5).
+
+   As with "job-k-octets", this value MUST NOT include the
+   multiplicative factors contributed by the number of copies specified
+   by the "copies" attribute, independent of whether the device can
+   process multiple copies without making multiple passes over the job
+   or document data and independent of whether the output is collated or
+   not.  Thus the value is independent of the implementation and
+   reflects the size of the document(s) measured in impressions
+   independent of the number of copies.
+
+   As with "job-k-octets", this value MUST also not include the
+   multiplicative factor due to a copies instruction embedded in the
+   document data.  If the document data actually includes replications
+   of the document data, this value will include such replication.  In
+   other words, this value is always the number of impressions in the
+   source document data, rather than a measure of the number of
+   impressions to be produced by the job.
+
+   See the Note in the "job-k-octets" attribute that also applies to
+   this attribute.
+
+4.3.19 job-media-sheets (integer(0:MAX))
+
+   This attribute specifies the total number of media sheets to be
+   produced for this job.
+
+   Unlike the "job-k-octets" and the "job-impressions" attributes, this
+   value MUST include the multiplicative factors contributed by the
+   number of copies specified by the "copies" attribute and a 'number of
+   copies' instruction embedded in the document data, if any.  This
+   difference allows the system administrator to control the lower and
+
+
+
+deBry, et al.                 Experimental                     [Page 95]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   upper bounds of both (1) the size of the document(s) with "job-k-
+   octets-supported" and "job-impressions-supported" and (2) the size of
+   the job with "job-media-sheets-supported".
+
+   See the Note in the "job-k-octets" attribute that also applies to
+   this attribute.
+
+4.3.20 job-k-octets-processed (integer(0:MAX))
+
+   This attribute specifies the total number of octets processed in K
+   octets, i.e., in units of 1024 octets so far.  The value MUST be
+   rounded up, so that a job between 1 and 1024 octets inclusive MUST be
+   indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc.
+
+   For implementations where multiple copies are produced by the
+   interpreter with only a single pass over the data, the final value
+   MUST be equal to the value of the "job-k-octets" attribute.  For
+   implementations where multiple copies are produced by the interpreter
+   by processing the data for each copy, the final value MUST be a
+   multiple of the value of the "job-k-octets" attribute.
+
+   Note: This attribute and the following two attributes ("job-
+   impressions-completed" and "job-sheets-completed") are intended to be
+   counters. That is, the value for a job that has not started
+   processing MUST be 0.  When the job's "job-state" is 'processing' or
+   'processing-stopped', this value is intended to contain the amount of
+   the job that has been processed to the time at which the attributes
+   are requested.
+
+4.3.21 job-impressions-completed (integer(0:MAX))
+
+   This job attribute specifies the number of impressions completed for
+   the job so far.  For printing devices, the impressions completed
+   includes interpreting, marking, and stacking the output.
+
+   See the note in "job-k-octets-processed" which also applies to this
+   attribute.
+
+4.3.22 job-media-sheets-completed (integer(0:MAX))
+
+   This job attribute specifies the media-sheets completed marking and
+   stacking for the entire job so far whether those sheets have been
+   processed on one side or on both.
+
+   See the note in "job-k-octets-processed" which also applies to this
+   attribute.
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 96]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.3.23 attributes-charset (charset)
+
+   This REQUIRED attribute is populated using the value in the client
+   supplied "attributes-charset" attribute in the create request.  It
+   identifies the charset (coded character set and encoding method) used
+   by any Job attributes with attribute syntax 'text' and 'name' that
+   were supplied by the client in the create request.  See Section 3.1.4
+   for a complete description of the "attributes-charset" operation
+   attribute.
+
+   This attribute does not indicate the charset in which the 'text' and
+   'name' values are stored internally in the Job object.  The internal
+   charset is implementation-defined.  The IPP object MUST convert from
+   whatever the internal charset is to that being requested in an
+   operation as specified in Section 3.1.4.
+
+4.3.24 attributes-natural-language (naturalLanguage)
+
+   This REQUIRED attribute is populated using the value in the client
+   supplied "attributes-natural-language" attribute in the create
+   request.  It identifies the natural language used for any Job
+   attributes with attribute syntax 'text' and 'name' that were supplied
+   by the client in the create request.  See Section 3.1.4 for a
+   complete description of the "attributes-natural-language" operation
+   attribute.  See Sections 4.1.1.2 and 4.1.2.2 for how a Natural
+   Language Override may be supplied explicitly for each 'text' and '
+   name' attribute value that differs from the value identified by the
+   "attributes-natural-language" attribute.
+
+4.4 Printer Description Attributes
+
+   These attributes form the attribute group called "printer-
+   description".  The following table summarizes these attributes, their
+   syntax, and whether or not they are REQUIRED for a Printer object to
+   support.  If they are not indicated as REQUIRED, they are OPTIONAL.
+   The maximum size in octets for 'text' and 'name' attributes is
+   indicated in parenthesizes.
+
+   Note: How these attributes are set by an Administrator is outside the
+   scope of this specification.
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 97]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+  +----------------------------+----------------------+----------------+
+  |      Attribute             |     Syntax           |   REQUIRED?    |
+  +----------------------------+----------------------+----------------+
+  | printer-uri-supported      | 1setOf uri           |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | uri-security-supported     | 1setOf type2 keyword |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | printer-name               | name (127)           |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | printer-location           | text (127)           |                |
+  +----------------------------+----------------------+----------------+
+  | printer-info               | text (127)           |                |
+  +----------------------------+----------------------+----------------+
+  | printer-more-info          | uri                  |                |
+  +----------------------------+----------------------+----------------+
+  | printer-driver-installer   | uri                  |                |
+  +----------------------------+----------------------+----------------+
+  | printer-make-and-model     | text (127)           |                |
+  +----------------------------+----------------------+----------------+
+  | printer-more-info-         | uri                  |                |
+  | manufacturer               |                      |                |
+  +----------------------------+----------------------+----------------+
+  | printer-state              | type1 enum           |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | printer-state-reasons      | 1setOf type2 keyword |                |
+  +----------------------------+----------------------+----------------+
+  | printer-state-message      | text (MAX)           |                |
+  +----------------------------+----------------------+----------------+
+  | operations-supported       | 1setOf type2 enum    |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | charset-configured         | charset              |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | charset-supported          | 1setOf charset       |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | natural-language-configured| naturalLanguage      |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | generated-natural-language-| 1setOf               |  REQUIRED      |
+  | supported                  |   naturalLanguage    |                |
+  +----------------------------+----------------------+----------------+
+  | document-format-default    | mimeMediaType        |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | document-format-           | 1setOf               |  REQUIRED      |
+  |   supported                |   mimeMediaType      |                |
+  +----------------------------+----------------------+----------------+
+  | printer-is-accepting-jobs  | boolean              |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | queued-job-count           | integer (0:MAX)      |  RECOMMENDED   |
+  +----------------------------+----------------------+----------------+
+
+
+
+deBry, et al.                 Experimental                     [Page 98]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+  +----------------------------+----------------------+----------------+
+  |      Attribute             |     Syntax           |   REQUIRED?    |
+  +----------------------------+----------------------+----------------+
+  | printer-message-from-      | text (127)           |                |
+  | operator                   |                      |                |
+  +----------------------------+----------------------+----------------+
+  | color-supported            | boolean              |                |
+  +----------------------------+----------------------+----------------+
+  | reference-uri-schemes-     | 1setOf uriScheme     |                |
+  |   supported                |                      |                |
+  +----------------------------+----------------------+----------------+
+  | pdl-override-supported     | type2 keyword        |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | printer-up-time            | integer (1:MAX)      |  REQUIRED      |
+  +----------------------------+----------------------+----------------+
+  | printer-current-time       | dateTime             |                |
+  +----------------------------+----------------------+----------------+
+  | multiple-operation-time-out| integer (1:MAX)      |                |
+  +----------------------------+----------------------+----------------+
+  | compression-supported      | 1setOf type3 keyword |                |
+  +----------------------------+----------------------+----------------+
+  | job-k-octets-supported     | rangeOfInteger       |                |
+  |                            |    (0:MAX)           |                |
+  +----------------------------+----------------------+----------------+
+  | job-impressions-supported  | rangeOfInteger       |                |
+  |                            |    (0:MAX)           |                |
+  +----------------------------+----------------------+----------------+
+  | job-media-sheets-supported | rangeOfInteger       |                |
+  |                            |    (0:MAX)           |                |
+  +----------------------------+----------------------+----------------+
+
+4.4.1 printer-uri-supported (1setOf uri)
+
+   This REQUIRED Printer attribute contains at least one URI for the
+   Printer object.  It OPTIONALLY contains more than one URI for the
+   Printer object.    An administrator determines a Printer object's
+   URI(s) and configures this attribute to contain those URIs by some
+   means outside the scope of IPP/1.0.  The precise format of this URI
+   is implementation dependent and depends on the protocol.  See the
+   next section for a description "uri-security-supported" which is the
+   REQUIRED companion attribute to this "printer-uri-supported"
+   attribute.  See section 2.4 on Printer object identity and section
+   8.2 on security and URIs for more information.
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                     [Page 99]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.4.2 uri-security-supported (1setOf type2 keyword)
+
+   This REQUIRED Printer attribute MUST have the same cardinality
+   (contain the same number of values) as the "printer-uri-supported"
+   attribute.  This attribute identifies the security mechanisms used
+   for each URI listed in the "printer-uri-supported" attribute.  The "i
+   th" value in "uri-security-supported" corresponds to the "i th" value
+   in "printer-uri-supported" and it describes the security mechanisms
+   used for accessing the Printer object via that URI. The following
+   standard values are defined:
+
+     'none': There are no secure communication channel protocols in use
+        for the given URI.
+
+     'ssl3': SSL3 [SSL] is the secure communications channel protocol in
+        use for the given URI.
+
+   Consider the following example.  For a single Printer object, an
+   administrator configures the "printer-uri-supported" and "uri-
+   security-supported" attributes as follows:
+
+     "printer-uri-supported": 'http://acme.com/open-use-printer', '
+        http://acme.com/restricted-use-printer', '
+        http://acme.com/private-printer'
+     "uri-security-supported": 'none', 'none', 'ssl3'
+
+   In this case, one Printer object has three URIs.
+
+     - For the first URI, 'http://acme.com/open-use-printer', the value
+        'none' in "uri-security-supported" indicates that there is no
+        secure channel protocol configured to run under HTTP.  The name
+        implies that there is no Basic or Digest authentication being
+        used, but it is up to the client to determine that while using
+        HTTP underneath the IPP application protocol.
+     - For the second URI, 'http://acme.com/restricted-use-printer', the
+        value 'none' in "uri-security-supported" indicates that there is
+        no secure channel protocol configured to run under HTTP.  In
+        this case, although the name does imply that there is some sort
+        of Basic or Digest authentication being used within HTTP, it is
+        up to the client to determine that while using HTTP and by
+        processing any '401 Unauthorized' HTTP error messages.
+     - For the third URI, 'http://acme.com/private-printer', the value '
+        ssl3' in "uri-security-supported" indicates that SSL3 is being
+        used to secure the channel.  The client SHOULD be prepared to
+        use SSL3 framing to negotiate an acceptable ciphersuite to use
+        while communicating with the Printer object.  In this case, the
+        name implies the use of a secure communications channel, but the
+        fact is made explicit by the presence of the 'ssl3' value in
+
+
+
+deBry, et al.                 Experimental                    [Page 100]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        "uri-security-supported".  The client does not need to resort to
+        understanding which security it must use by following naming
+        conventions or by parsing the URI to determine which security
+        mechanisms are implied.
+
+   It is expected that many IPP Printer objects will be configured to
+   support only one channel (either configured to use SSL3 access or
+   not), and will therefore only ever have one URI listed in the
+   "printer-uri-supported" attribute.  No matter the configuration of
+   the Printer object (whether it has only one URI or more than one
+   URI), a client MUST supply only one URI in the target "printer-uri"
+   operation attribute.
+
+4.4.3 printer-name (name(127))
+
+   This REQUIRED Printer attribute contains the name of the Printer
+   object.  It is a name that is more end-user friendly than a URI. An
+   administrator determines a printer's name and sets this attribute to
+   that name. This name may be the last part of the printer's URI or it
+   may be unrelated.  In non-US-English locales, a name may contain
+   characters that are not allowed in a URI.
+
+4.4.4 printer-location (text(127))
+
+   This Printer attribute identifies the location of the device. This
+   could include things like: "in Room 123A, second floor of building
+   XYZ".
+
+4.4.5 printer-info (text(127))
+
+   This Printer attribute identifies the descriptive information about
+   this Printer object.  This could include things like: "This printer
+   can be used for printing color transparencies for HR presentations",
+   or "Out of courtesy for others, please print only small (1-5 page)
+   jobs at this printer", or even "This printer is going away on July 1,
+   1997, please find a new printer".
+
+4.4.6 printer-more-info (uri)
+
+   This Printer attribute contains a URI used to obtain more information
+   about this specific Printer object.  For example, this could be an
+   HTTP type URI referencing an HTML page accessible to a Web Browser.
+   The information obtained from this URI is intended for end user
+   consumption.  Features outside the scope of IPP can be accessed from
+   this URI.  The information is intended to be specific to this printer
+   instance and site specific services (e.g. job pricing, services
+   offered, end user assistance). The device manufacturer may initially
+   populate this attribute.
+
+
+
+deBry, et al.                 Experimental                    [Page 101]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+4.4.7 printer-driver-installer (uri)
+
+   This Printer attribute contains a URI to use to locate the driver
+   installer for this Printer object.   This attribute is intended for
+   consumption by automata.  The mechanics of print driver installation
+   is outside the scope of IPP.  The device manufacturer may initially
+   populate this attribute.
+
+4.4.8 printer-make-and-model (text(127))
+
+   This Printer attribute identifies the make and model of the device.
+   The device manufacturer may initially populate this attribute.
+
+4.4.9 printer-more-info-manufacturer (uri)
+
+   This Printer attribute contains a URI used to obtain more information
+   about this type of device.  The information obtained from this URI is
+   intended for end user consumption.  Features outside the scope of IPP
+   can be accessed from this URI (e.g., latest firmware, upgrades, print
+   drivers, optional features available, details on color support).  The
+   information is intended to be germane to this printer without regard
+   to site specific modifications or services. The device manufacturer
+   may initially populate this attribute.
+
+4.4.10 printer-state (type1 enum)
+
+   This REQUIRED Printer attribute identifies the current state of the
+   device.  The "printer-state reasons" attribute augments the
+   "printer-state" attribute to give more detailed information about the
+   Printer in the given printer state.
+
+   A Printer object need only update this attribute before responding to
+   an operation which requests the attribute; the Printer object NEED
+   NOT update this attribute continually, since asynchronous event
+   notification is not part of IPP/1.0.  A Printer NEED NOT implement
+   all values if they are not applicable to a given implementation.
+
+   The following standard enum values are defined:
+
+     Value  Symbolic Name and Description
+
+     '3'    'idle':  If a Printer receives a job (whose required
+                  resources are ready) while in this state, such a job
+                  MUST transit into the 'processing' state immediately.
+                  If the "printer-state-reasons" attribute contains any
+                  reasons, they MUST be reasons that would not prevent a
+                  job from transiting into the 'processing' state
+                  immediately, e.g., 'toner-low'. Note: if a Printer
+
+
+
+deBry, et al.                 Experimental                    [Page 102]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+                  controls more than one output device, the above
+                  definition implies that a Printer is 'idle' if at
+                  least one output device is idle.
+
+     '4'    'processing':  If a Printer receives a job (whose required
+                  resources are ready) while in this state, such a job
+                  MUST transit into the 'pending' state immediately.
+                  Such a job MUST transit into the 'processing' state
+                  only after jobs ahead of it complete.  If the
+                  "printer-state-reasons" attribute contains any
+                  reasons, they MUST be reasons that do not prevent the
+                  current job from printing, e.g.  'toner-low'.  Note:
+                  if a Printer controls more than one output device, the
+                  above definition implies that a Printer is '
+                  processing' if at least one output device is
+                  processing, and none is idle.
+
+     '5'    'stopped':  If a Printer receives a job (whose required
+                  resources are ready) while in this state, such a job
+                  MUST transit into the 'pending' state immediately.
+                  Such a job MUST transit into the 'processing' state
+                  only after some human fixes the problem that stopped
+                  the printer and after jobs ahead of it complete
+                  processing.  If supported, the "printer-state-reasons"
+                  attribute MUST contain at least one reason, e.g. '
+                  media-jam', which prevents it from either processing
+                  the current job or transitioning a 'pending' job to
+                  the 'processing' state.
+
+                  Note: if a Printer controls more than one output
+                  device, the above definition implies that a Printer is
+                  'stopped' only if all output devices are stopped.
+                  Also, it is tempting to define 'stopped' as when a
+                  sufficient number of output devices are stopped and
+                  leave it to an implementation to define the sufficient
+                  number.  But such a rule complicates the definition of
+                  'stopped' and 'processing'. For example, with this
+                  alternate definition of 'stopped', a job can move from
+                  'pending' to 'processing' without human intervention,
+                  even though the Printer is stopped.
+
+4.4.11 printer-state-reasons (1setOf type2 keyword)
+
+   This Printer attribute supplies additional detail about the device's
+   state.
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 103]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Each keyword value MAY have a suffix to indicate its level of
+   severity.  The three levels are: report (least severe), warning, and
+   error (most severe).
+
+     - '-report':  This suffix indicates that the reason is a "report".
+        An implementation may choose to omit some or all reports. Some
+        reports specify finer granularity about the printer state;
+        others serve as a precursor to a warning. A report MUST contain
+        nothing that could affect the printed output.
+     - '-warning': This suffix indicates that the reason is a "warning".
+        An implementation may choose to omit some or all warnings.
+        Warnings serve as a precursor to an error. A warning MUST
+        contain nothing that prevents a job from completing, though in
+        some cases the output may be of lower quality.
+     - '-error': This suffix indicates that the reason is an "error".
+        An implementation MUST include all errors. If this attribute
+        contains one or more errors, printer MUST be in the stopped
+        state.
+
+   If the implementation does not add any one of the three suffixes, all
+   parties MUST assume that the reason is an "error".
+
+   If a Printer object controls more than one output device, each value
+   of this attribute MAY apply to one or more of the output devices.  An
+   error on one output device that does not stop the Printer object as a
+   whole MAY appear as a warning in the Printer's "printer-state-reasons
+   attribute".  If the "printer-state" for such a Printer has a value of
+   'stopped', then there MUST be an error reason among the values in the
+   "printer-state-reasons" attribute.
+
+   The following standard keyword values are defined:
+
+     'other': The device has detected an error other than one listed in
+        this document.
+     'none': There are not reasons. This state reason is semantically
+        equivalent to "printer-state-reasons" without any value.
+     'media-needed': A tray has run out of media.
+     'media-jam': The device has a media jam.
+     'paused': Someone has paused the Printer object.  In this state, a
+        Printer MUST NOT produce printed output, but it MUST perform
+        other operations requested by a client.  If a Printer had been
+        printing a job when the Printer was paused, the Printer MUST
+        resume printing that job when the Printer is no longer paused
+        and leave no evidence in the printed output of such a pause.
+     'shutdown': Someone has removed a Printer object from service, and
+        the device may be powered down or physically removed.  In this
+        state, a Printer object MUST NOT produce printed output, and
+        unless the Printer object is realized by a print server that is
+
+
+
+deBry, et al.                 Experimental                    [Page 104]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        still active, the Printer object MUST perform no other
+        operations requested by a client, including returning this
+        value. If a Printer object had been printing a job when it was
+        shutdown, the Printer NEED NOT resume printing that job when the
+        Printer is no longer shutdown. If the Printer resumes printing
+        such a job, it may leave evidence in the printed output of such
+        a shutdown, e.g. the part printed before the shutdown may be
+        printed a second time after the shutdown.
+     'connecting-to-device': The Printer object has scheduled a job on
+        the output device and is in the process of connecting to a
+        shared network output device (and might not be able to actually
+        start printing the job for an arbitrarily long time depending on
+        the usage of the output device by other servers on the network).
+     'timed-out': The server was able to connect to the output device
+        (or is always connected), but was unable to get a response from
+        the output device.
+     'stopping': The Printer object is in the process of stopping the
+        device and will be stopped in a while. When the device is
+        stopped, the Printer object will change the Printer object's
+        state to 'stopped'.  The 'stopping-warning' reason is never an
+        error, even for a Printer with a single output device.  When an
+        output-device ceases accepting jobs, the Printer will have this
+        reason while the output device completes printing.
+     'stopped-partly': When a Printer object controls more than one
+        output device, this reason indicates that one or more output
+        devices are stopped.  If the reason is a report, fewer than half
+        of the output devices are stopped.  If the reason is a warning,
+        fewer than all of the output devices are stopped.
+     'toner-low': The device is low on toner.
+     'toner-empty': The device is out of toner.
+     'spool-area-full': The limit of persistent storage allocated for
+        spooling has been reached.
+     'cover-open': One or more covers on the device are open.
+     'interlock-open': One or more interlock devices on the printer are
+        unlocked.
+     'door-open': One or more doors on the device are open.
+     'input-tray-missing': One or more input trays are not in the
+        device.
+     'media-low': At least one input tray is low on media.
+     'media-empty': At least one input tray is empty.
+     'output-tray-missing': One or more output trays are not in the
+        device
+     'output-area-almost-full': One or more output area is almost full
+        (e.g. tray, stacker, collator).
+     'output-area-full': One or more output area is full. (e.g. tray,
+        stacker, collator)
+     'marker-supply-low': The device is low on at least one marker
+        supply.  (e.g. toner, ink, ribbon)
+
+
+
+deBry, et al.                 Experimental                    [Page 105]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'marker-supply-empty: The device is out of at least one marker
+        supply. (e.g. toner, ink, ribbon)
+     'marker-waste-almost-full': The device marker supply waste
+        receptacle is almost full.
+     'marker-waste-full': The device marker supply waste receptacle is
+        full.
+     'fuser-over-temp': The fuser temperature is above normal.
+     'fuser-under-temp': The fuser temperature is below normal.
+     'opc-near-eol': The optical photo conductor is near end of life.
+     'opc-life-over': The optical photo conductor is no longer
+        functioning.
+     'developer-low': The device is low on developer.
+     'developer-empty: The device is out of developer.
+     'interpreter-resource-unavailable': An interpreter resource is
+        unavailable (i.e. font, form)
+
+4.4.12 printer-state-message (text(MAX))
+
+   This Printer attribute specifies the additional information about the
+   printer state and printer state reasons in human readable text.  If
+   the Printer object supports this attribute, the Printer object MUST
+   be able to generate this message in any of the natural languages
+   identified by the Printer's "generated-natural-language-supported"
+   attribute (see the "attributes-natural-language" operation attribute
+   specified in Section 3.1.4.1).
+
+4.4.13 operations-supported (1setOf type2 enum)
+
+   This REQUIRED Printer attribute specifies the set of supported
+   operations for this Printer object and contained Job objects.  All
+   32-bit enum values for this attribute MUST NOT exceed 0x8FFF, since
+   these values are passed in two octets in each Protocol request
+   [RFC2565].
+
+   The following standard enum and "operation-id" (see section 3.1.2)
+   values are defined:
+
+     Value               Operation Name
+     -----------------   -------------------------------------
+
+     0x0000              reserved, not used
+     0x0001              reserved, not used
+     0x0002              Print-Job
+     0x0003              Print-URI
+     0x0004              Validate-Job
+     0x0005              Create-Job
+     0x0006              Send-Document
+     0x0007              Send-URI
+
+
+
+deBry, et al.                 Experimental                    [Page 106]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     0x0008              Cancel-Job
+     0x0009              Get-Job-Attributes
+     0x000A              Get-Jobs
+     0x000B              Get-Printer-Attributes
+     0x000C-0x3FFF       reserved for future operations
+     0x4000-0x8FFF       reserved for private extensions
+
+   This allows for certain vendors to implement private extensions that
+   are guaranteed to not conflict with future registered extensions.
+   However, there is no guarantee that two or more private extensions
+   will not conflict.
+
+4.4.14 charset-configured (charset)
+
+   This REQUIRED Printer attribute identifies the charset that the
+   Printer object has been configured to represent 'text' and 'name'
+   Printer attributes that are set by the operator, system
+   administrator, or manufacturer, i.e., for "printer-name" (name),
+   "printer-location" (text), "printer-info" (text), and "printer-make-
+   and-model" (text).  Therefore, the value of the Printer object's
+   "charset-configured" attribute MUST also be among the values of the
+   Printer object's "charset-supported" attribute.
+
+4.4.15 charset-supported (1setOf charset)
+
+   This REQUIRED Printer attribute identifies the set of charsets that
+   the Printer and contained Job objects support in attributes with
+   attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST
+   be present, since IPP objects MUST support the UTF-8 [RFC2279]
+   charset.  If a Printer object supports a charset, it means that for
+   all attributes of syntax 'text' and 'name' the IPP object MUST (1)
+   accept the charset in requests and return the charset in responses as
+   needed.
+
+   If more charsets than UTF-8 are supported, the IPP object MUST
+   perform charset conversion between the charsets as described in
+   Section 3.2.1.2.
+
+4.4.16 natural-language-configured (naturalLanguage)
+
+   This REQUIRED Printer attribute identifies the natural language that
+   the Printer object has been configured to represent 'text' and 'name'
+   Printer attributes that are set by the operator, system
+   administrator, or manufacturer, i.e., for "printer-name" (name),
+   "printer-location" (text), "printer-info" (text), and "printer-make-
+   and-model" (text).  When returning these Printer attributes, the
+   Printer object MAY return them in the configured natural language
+   specified by this attribute, instead of the natural language
+
+
+
+deBry, et al.                 Experimental                    [Page 107]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   requested by the client in the "attributes-natural-language"
+   operation attribute.  See Section 3.1.4.1 for the specification of
+   the OPTIONAL multiple natural language support.  Therefore, the value
+   of the Printer object's "natural-language-configured" attribute MUST
+   also be among the values of the Printer object's "generated-natural-
+   language-supported" attribute.
+
+4.4.17 generated-natural-language-supported (1setOf naturalLanguage)
+
+   This REQUIRED Printer attribute identifies the natural language(s)
+   that the Printer object and contained Job objects support in
+   attributes with attribute syntax 'text' and 'name'.  The natural
+   language(s) supported depends on implementation and/or configuration.
+   Unlike charsets, IPP objects MUST accept requests with any natural
+   language or any Natural Language Override whether the natural
+   language is supported or not.
+
+   If a Printer object supports a natural language, it means that for
+   any of the attributes for which the Printer or Job object generates
+   messages, i.e., for the "job-state-message" and "printer-state-
+   message" attributes and Operation Messages (see Section 3.1.5) in
+   operation responses, the Printer and Job objects MUST be able to
+   generate messages in any of the Printer's supported natural
+   languages.  See section 3.1.4 for the specification of 'text' and '
+   name' attributes in operation requests and responses.
+
+   Note: A Printer object that supports multiple natural languages,
+   often has separate catalogs of messages, one for each natural
+   language supported.
+
+4.4.18 document-format-default (mimeMediaType)
+
+   This REQUIRED Printer attribute identifies the document format that
+   the Printer object has been configured to assume if the client does
+   not supply a "document-format" operation attribute in any of the
+   operation requests that supply document data.  The standard values
+   for this attribute are Internet Media types (sometimes called MIME
+   types).  For further details see the description of the '
+   mimeMediaType' attribute syntax in Section 4.1.9.
+
+4.4.19 document-format-supported (1setOf mimeMediaType)
+
+   This REQUIRED Printer attribute identifies the set of document
+   formats that the Printer object and contained Job objects can
+   support. For further details see the description of the '
+   mimeMediaType' attribute syntax in Section 4.1.9.
+
+4.4.20 printer-is-accepting-jobs (boolean)
+
+
+
+deBry, et al.                 Experimental                    [Page 108]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   This REQUIRED Printer attribute indicates whether the printer is
+   currently able to accept jobs, i.e., is accepting Print-Job, Print-
+   URI, and Create-Job requests.  If the value is 'true', the printer is
+   accepting jobs.  If the value is 'false', the Printer object is
+   currently rejecting any jobs submitted to it.  In this case, the
+   Printer object returns the 'server-error-not-accepting-jobs' status
+   code.
+
+   Note: This value is independent of the "printer-state" and "printer-
+   state-reasons" attributes because its value does not affect the
+   current job; rather it affects future jobs.  This attribute may cause
+   the Printer to reject jobs when the "printer-state" is 'idle' or it
+   may cause the Printer object to accepts jobs when the "printer-state"
+   is 'stopped'.
+
+4.4.21 queued-job-count (integer(0:MAX))
+
+   This RECOMMENDED Printer attribute contains a count of the number of
+   jobs that are either 'pending', 'processing', 'pending-held', or '
+   processing-stopped' and is set by the Printer object.
+
+4.4.22 printer-message-from-operator (text(127))
+
+   This Printer attribute provides a message from an operator, system
+   administrator or "intelligent" process to indicate to the end user
+   information or status of the printer, such as why it is unavailable
+   or when it is expected to be available.
+
+4.4.23 color-supported (boolean)
+
+   This Printer attribute identifies whether the device is capable of
+   any type of color printing at all, including highlight color.  All
+   document instructions having to do with color are embedded within the
+   document PDL (none are external IPP attributes in IPP/1.0).
+
+   Note:  end-users are able to determine the nature and details of the
+   color support by querying the "printer-more-info-manufacturer"
+   Printer attribute.
+
+4.4.24 reference-uri-schemes-supported (1setOf uriScheme)
+
+   This Printer attribute specifies which URI schemes are supported for
+   use in the "document-uri" operation attribute of the Print-URI or
+   Send-URI operation.  If a Printer object supports these optional
+   operations, it MUST support the "reference-uri-schemes-supported"
+   Printer attribute with at least the following schemed URI value:
+
+     'ftp':  The Printer object will use an FTP 'get' operation as
+
+
+
+deBry, et al.                 Experimental                    [Page 109]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        defined in RFC 2228 [RFC2228] using FTP URLs as defined by
+        [RFC2396] and[RFC2316].
+
+   The Printer object MAY OPTIONALLY support other URI schemes (see
+   section 4.1.6).
+
+4.4.25 pdl-override-supported (type2 keyword)
+
+   This REQUIRED Printer attribute expresses the ability for a
+   particular Printer implementation to either attempt to override
+   document data instructions with IPP attributes or not.
+
+   This attribute takes on the following values:
+
+     - 'attempted': This value indicates that the Printer object
+       attempts to make the IPP attribute values take precedence over
+       embedded instructions in the document data, however there is no
+       guarantee.
+
+     - 'not-attempted': This value indicates that the Printer object
+       makes no attempt to make the IPP attribute values take precedence
+       over embedded instructions in the document data.
+
+   Section 15 contains a full description of how this attribute
+   interacts with and affects other IPP attributes, especially the
+   "ipp-attribute-fidelity" attribute.
+
+4.4.26 printer-up-time (integer(1:MAX))
+
+   This REQUIRED Printer attribute indicates the amount of time (in
+   seconds) that this instance of this Printer implementation has been
+   up and running.  This value is used to populate the Job attributes
+   "time-at-creation", "time-at-processing", and "time-at-completed".
+   These time values are all measured in seconds and all have meaning
+   only relative to this attribute, "printer-up-time".  The value is a
+   monotonically increasing value starting from 1 when the Printer
+   object is started-up (initialized, booted, etc.).
+
+   If the Printer object goes down at some value 'n', and comes back up,
+   the implementation MAY:
+
+     1. Know how long it has been down, and resume at some value greater
+        than 'n', or
+     2. Restart from 1.
+
+   In the first case, the Printer SHOULD not tweak any existing related
+   Job attributes ("time-at-creation", "time-at-processing", and "time-
+   at-completed").  In the second case, the Printer object SHOULD reset
+
+
+
+deBry, et al.                 Experimental                    [Page 110]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   those attributes to 0.  If a client queries a time-related Job
+   attribute and finds the value to be 0, the client MUST assume that
+   the Job was submitted in some life other than the Printer's current
+   life.
+
+4.4.27 printer-current-time (dateTime)
+
+   This Printer attribute indicates the current absolute wall-clock
+   time.  If an implementation supports this attribute, then a client
+   could calculate the absolute wall-clock time each Job's "time-at-
+   creation", "time-at-processing", and "time-at-completed" attributes
+   by using both "printer-up-time" and this attribute, "printer-
+   current-time".  If an implementation does not support this attribute,
+   a client can only calculate the relative time of certain events based
+   on the REQUIRED "printer-up-time" attribute.
+
+4.4.28 multiple-operation-time-out (integer(1:MAX))
+
+   This Printer attributes identifies the minimum time (in seconds) that
+   the Printer object waits for additional Send-Document or Send-URI
+   operations to follow a still-open multi-document Job object before
+   taking  any recovery actions, such as the ones indicated in section
+   3.3.1.
+
+   It is RECOMMENDED that vendors supply a value for this attribute that
+   is between 60 and 240 seconds.  An implementation MAY allow a system
+   administrator to set this attribute.  If so, the system administrator
+   MAY be able to set values outside this range.
+
+4.4.29 compression-supported (1setOf type3 keyword)
+
+   This Printer attribute identifies the set of supported compression
+   algorithms for document data.  Compression only applies to the
+   document data; compression does not apply to the encoding of the IPP
+   operation itself.  The supported values are used to validate the
+   client supplied "compression" operation attributes in Print-Job,
+   Send-Document, and Send-URI requests.
+
+   Standard values are :
+
+     'none': no compression is used.
+     'deflate':  ZIP public domain inflate/deflate) compression
+        technology
+     'gzip' GNU zip compression technology described in RFC 1952
+        [RFC1952].
+     'compress': UNIX compression technology
+
+4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX))
+
+
+
+deBry, et al.                 Experimental                    [Page 111]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   This Printer attribute specifies the upper and lower bounds of total
+   sizes of jobs in K octets, i.e., in units of 1024 octets. The
+   supported values are used to validate the client supplied "job-k-
+   octets" operation attributes in create requests.  The corresponding
+   job description attribute "job-k-octets" is defined in section
+   4.3.17.
+
+   4.4.31 job-impressions-supported (rangeOfInteger(0:MAX))
+
+   This Printer attribute specifies the upper and lower bounds for the
+   number of impressions per job. The supported values are used to
+   validate the client supplied "job-impressions" operation attributes
+   in create requests.  The corresponding job description attribute
+   "job-impressions" is defined in section 4.3.18.
+
+4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX))
+
+   This Printer attribute specifies the upper and lower bounds for the
+   number of media sheets per job. The supported values are used to
+   validate the client supplied "job-media-sheets" operation attributes
+   in create requests.  The corresponding Job attribute "job-media-
+   sheets" is defined in section 4.3.19.
+
+5. Conformance
+
+   This section describes conformance issues and requirements. This
+   document introduces model entities such as objects, operations,
+   attributes, attribute syntaxes, and attribute values.  These
+   conformance sections describe the conformance requirements which
+   apply to these model entities.
+
+5.1 Client Conformance Requirements
+
+   A conforming client MUST support all REQUIRED operations as defined
+   in this document.  For each attribute included in an operation
+   request, a conforming client MUST supply a value whose type and value
+   syntax conforms to the requirements of the Model document as
+   specified in Sections 3 and 4.  A conforming client MAY supply any
+   registered extensions and/or private extensions in an operation
+   request, as long as they meet the requirements in Section 6.
+
+   Otherwise, there are no conformance requirements placed on the user
+   interfaces provided by IPP clients or their applications.  For
+   example, one application might not allow an end user to submit
+   multiple documents per job, while another does.  One application
+   might first query a Printer object in order to supply a graphical
+   user interface (GUI) dialogue box with supported and default values
+   whereas a different implementation might not.
+
+
+
+deBry, et al.                 Experimental                    [Page 112]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   When sending a request, an IPP client NEED NOT supply any attributes
+   that are indicated as OPTIONALLY supplied by the client.
+
+   A client MUST be able to accept any of the attribute syntaxes defined
+   in Section 4.1, including their full range, that may be returned to
+   it in a response from a Printer object.  In particular for each
+   attribute that the client supports whose attribute syntax is 'text',
+   the client MUST accept and process both the 'textWithoutLanguage' and
+   'textWithLanguage' forms.  Similarly, for each attribute that the
+   client supports whose attribute syntax is 'name', the client MUST
+   accept and process both the 'nameWithoutLanguage' and '
+   nameWithLanguage' forms.  For presentation purposes, truncation of
+   long attribute values is not recommended.  A recommended approach
+   would be for the client implementation to allow the user to scroll
+   through long attribute values.
+
+   A query response may contain attribute groups, attributes, and values
+   that the client does not expect.  Therefore, a client implementation
+   MUST gracefully handle such responses and not refuse to inter-operate
+   with a conforming Printer that is returning extended registered or
+   private attributes and/or attribute values that conform to Section 6.
+   Clients may choose to ignore any parameters, attributes, or values
+   that they do not understand.
+
+5.2 IPP Object Conformance Requirements
+
+   This section specifies the conformance requirements for conforming
+   implementations with respect to objects, operations, and attributes.
+
+5.2.1 Objects
+
+   Conforming implementations MUST implement all of the model objects as
+   defined in this specification in the indicated sections:
+
+     Section 2.1 - Printer Object
+     Section 2.2 - Job Object
+
+5.2.2 Operations
+
+   Conforming IPP object implementations MUST implement all of the
+   REQUIRED model operations, including REQUIRED responses, as defined
+   in this specification in the indicated sections:
+
+     For a Printer object:
+        Print-Job (section 3.2.1)          REQUIRED
+        Print-URI (section 3.2.2)          OPTIONAL
+        Validate-Job (section 3.2.3)       REQUIRED
+        Create-Job (section 3.2.4)         OPTIONAL
+
+
+
+deBry, et al.                 Experimental                    [Page 113]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        Get-Printer-Attributes (section 3.2.5)  REQUIRED
+        Get-Jobs (section 3.2.6)           REQUIRED
+
+     For a Job object:
+        Send-Document (section 3.3.1)      OPTIONAL
+        Send-URI (section 3.3.2)           OPTIONAL
+        Cancel-Job (section 3.3.3)         REQUIRED
+        Get-Job-Attributes (section 3.3.4) REQUIRED
+
+   Conforming IPP objects MUST support all REQUIRED operation attributes
+   and all values of such attributes if so indicated in the description.
+   Conforming IPP objects MUST ignore all unsupported or unknown
+   operation attributes or operation attribute groups received in a
+   request, but MUST reject a request that contains a supported
+   operation attribute that contains an unsupported value.
+
+   The following section on object attributes specifies the support
+   required for object attributes.
+
+5.2.3 IPP Object Attributes
+
+   Conforming IPP objects MUST support all of the REQUIRED object
+   attributes, as defined in this specification in the indicated
+   sections.
+
+   If an object supports an attribute, it MUST support only those values
+   specified in this document or through the extension mechanism
+   described in section 5.2.4. It MAY support any non-empty subset of
+   these values.  That is, it MUST support at least one of the specified
+   values and at most all of them.
+
+5.2.4 Extensions
+
+   A conforming IPP object MAY support registered extensions and private
+   extensions, as long as they meet the requirements specified in
+   Section 6.
+
+   For each attribute included in an operation response, a conforming
+   IPP object MUST return a value whose type and value syntax conforms
+   to the requirement of the Model document as specified in Sections 3
+   and 4.
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 114]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+5.2.5 Attribute Syntaxes
+
+   An IPP object MUST be able to accept any of the attribute syntaxes
+   defined in Section 4.1, including their full range, in any operation
+   in which a client may supply attributes or the system administrator
+   may configure attributes (by means outside the scope of IPP/1.0).  In
+   particular for each attribute that the IPP object supports whose
+   attribute syntax is 'text', the IPP object MUST accept and process
+   both the 'textWithoutLanguage' and 'textWithLanguage' forms.
+   Similarly, for each attribute that the IPP object supports whose
+   attribute syntax is 'name', the IPP object MUST accept and process
+   both the 'nameWithoutLanguage' and 'nameWithLanguage' forms.
+   Furthermore, an IPP object MUST return attributes to the client in
+   operation responses that conform to the syntax specified in Section
+   4.1, including their full range if supplied previously by a client.
+
+5.3 Charset and Natural Language Requirements
+
+   All clients and IPP objects MUST support the 'utf-8' charset as
+   defined in section 4.1.7.
+
+   IPP objects MUST be able to accept any client request which correctly
+   uses the "attributes-natural-language" operation attribute or the
+   Natural Language Override mechanism on any individual attribute
+   whether or not the natural language is supported by the IPP object.
+   If an IPP object supports a natural language, then it MUST be able to
+   translate (perhaps by table lookup) all generated 'text' or 'name'
+   attribute values into one of the supported languages (see section
+   3.1.4).  That is, the IPP object that supports a natural language
+   NEED NOT be a general purpose translator of any arbitrary 'text' or '
+   name' value supplied by the client into that natural language.
+   However, the object MUST be able to translate (automatically
+   generate) any of its own attribute values and messages into that
+   natural language.
+
+5.4 Security Conformance Requirements
+
+   Conforming IPP Printer objects MAY support Secure Socket Layer
+   Version 3 (SSL3) [SSL] access, support access without SSL3 or support
+   both means of access.
+
+   Conforming IPP clients SHOULD support SSL3 access and non-SSL3
+   access.  Note: This client requirement to support both means that
+   conforming IPP clients will be able to inter-operate with any IPP
+   Printer object.
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 115]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   For a detailed discussion of security considerations and the IPP
+   application security profile required for SSL3 support, see section
+   8.
+
+6. IANA Considerations (registered and private extensions)
+
+   This section describes how IPP can be extended to allow the following
+   registered and private extensions to IPP:
+
+     1. keyword attribute values
+     2. enum attribute values
+     3. attributes
+     4. attribute syntaxes
+     5. operations
+     6. attribute groups
+     7. status codes
+
+   Extensions registered for use with IPP/1.0 are OPTIONAL for client
+   and IPP object conformance to the IPP/1.0 Model specification.
+
+   These extension procedures are aligned with the guidelines as set
+   forth by the IESG [RFC2434].  Section 11 describes how to propose new
+   registrations for consideration.  IANA will reject registration
+   proposals that leave out required information or do not follow the
+   appropriate format described in Section 11.  IPP/1.0 may also be
+   extended by an appropriate RFC that specifies any of the above
+   extensions.
+
+6.1 Typed 'keyword' and 'enum' Extensions
+
+   IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3
+   and 4.1.4).  This document uses prefixes to the 'keyword' and 'enum'
+   basic attribute syntax type in order to communicate extra information
+   to the reader through its name. This extra information is not
+   represented in the protocol because it is unimportant to a client or
+   Printer object.  The list below describes the prefixes and their
+   meaning.
+
+     "type1":  The IPP specification must be revised to add a new
+        keyword or a new enum.  No private keywords or enums are
+        allowed.
+
+     "type2":  Implementers can, at any time, add new keyword or enum
+        values by proposing the complete specification to IANA:
+
+        iana@iana.org
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 116]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        IANA will forward the registration proposal to the IPP
+        Designated Expert who will review the proposal with a mailing
+        list that the Designated Expert keeps for this purpose.
+        Initially, that list will be the mailing list used by the IPP
+        WG:
+
+             ipp@pwg.org
+
+        even after the IPP WG is disbanded as permitted by [RFC2434].
+        The IPP Designated Expert is appointed by the IESG Area Director
+        responsible for IPP, according to [RFC2434].
+
+        When a type2 keyword or enum is approved, the IPP Designated
+        Expert becomes the point of contact for any future maintenance
+        that might be required for that registration.
+
+     "type3":  Implementers can, at any time, add new keyword and enum
+        values by submitting the complete specification to IANA as for
+        type2 who will forward the proposal to the IPP Designated
+        Expert.  While no additional technical review is required, the
+        IPP Designated Expert may, at his/her discretion, forward the
+        proposal to the same mailing list as for type2 registrations for
+        advice and comment.
+
+        When a type3 keyword or enum is approved by the IPP Designated
+        Expert, the original proposer becomes the point of contact for
+        any future maintenance that might be required for that
+        registration.
+
+   For type2 and type3 keywords, the proposer includes the name of the
+   keyword in the registration proposal and the name is part of the
+   technical review.
+
+   After type2 and type3 enums specifications are approved, the IPP
+   Designated Expert in consultation with IANA assigns the next
+   available enum number for each enum value.
+
+   IANA will publish approved type2 and type3 keyword and enum
+   attributes value registration specifications in:
+
+        ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
+
+   where xxx is the attribute name that specifies the initial values and
+   yyy.txt is a descriptive file name that contains one or more enums or
+   keywords approved at the same time.  For example, if several
+   additional enums for stapling are approved for use with the
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 117]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   "finishings" attribute (and "finishings-default" and "finishings-
+   supported" attributes), IANA will publish the additional values in
+   the file:
+
+        ftp.isi.edu/iana/assignments/ipp/attribute-
+        values/finishings/stapling.txt
+
+   Note: Some attributes are defined to be: 'type3 keywords' | 'name'
+   which allows for attribute values to be extended by a site
+   administrator with administrator defined names.  Such names are not
+   registered with IANA.
+
+   By definition, each of the three types above assert some sort of
+   registry or review process in order for extensions to be considered
+   valid.  Each higher numbered level (1, 2, 3) tends to be decreasingly
+   less stringent than the previous level.   Therefore, any typeN value
+   MAY be registered using a process for some typeM where M is less than
+   N, however such registration is NOT REQUIRED.  For example, a type3
+   value MAY be registered in a type 1 manner (by being included in a
+   future version of an IPP specification), however, it is NOT REQUIRED.
+
+   This specification defines keyword and enum values for all of the
+   above types, including type3 keywords.
+
+   For private (unregistered) keyword extensions, implementers SHOULD
+   use keywords with a suitable distinguishing prefix, such as "xxx-"
+   where xxx is the (lowercase) fully qualified company name registered
+   with IANA for use in domain names [RFC1035].  For example, if the
+   company XYZ Corp.  had obtained the domain name "XYZ.com", then a
+   private keyword 'abc' would be: 'xyz.com-abc'.
+
+   Note: RFC 1035 [RFC1035] indicates that while upper and lower case
+   letters are allowed in domain names, no significance is attached to
+   the case.  That is, two names with the same spelling but different
+   case are to be treated as if identical.  Also, the labels in a domain
+   name must follow the rules for ARPANET host names:  They must start
+   with a letter, end with a letter or digit, and have as interior
+   characters only letters, digits, and hyphen.  Labels must be 63
+   characters or less.  Labels are separated by the "." character.
+
+   For private (unregistered) enum extension, implementers MUST use
+   values in the reserved integer range which is 2**30 to 2**31-1.
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 118]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+6.2 Attribute Extensibility
+
+   Attribute names are type2 keywords.  Therefore, new attributes may be
+   registered and have the same status as attributes in this document by
+   following the type2 extension rules.  For private (unregistered)
+   attribute extensions, implementers SHOULD use keywords with a
+   suitable distinguishing prefix as described in Section 6.1.
+
+   IANA will publish approved attribute registration specifications as
+   separate files:
+
+        ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt
+
+   where "xxx-yyy" is the new attribute name.
+
+   If a new Printer object attribute is defined and its values can be
+   affected by a specific document format, its specification needs to
+   contain the following sentence:
+
+     "The value of this attribute returned in a Get-Printer-Attributes
+     response MAY depend on the "document-format" attribute supplied
+     (see Section 3.2.5.1)."
+
+   If the specification does not, then its value in the Get-Printer-
+   Attributes response MUST NOT depend on the "document-format" supplied
+   in the request.  When a new Job Template attribute is registered, the
+   value of the Printer attributes MAY vary with "document-format"
+   supplied in the request without the specification having to indicate
+   so.
+
+6.3 Attribute Syntax Extensibility
+
+   Attribute syntaxes are like type2 enums.  Therefore, new attribute
+   syntaxes may be registered and have the same status as attribute
+   syntaxes in this document by following the type2 extension rules
+   described in Section 6.1.  The value codes that identify each of the
+   attribute syntaxes are assigned in the Encoding and Transport
+   specification [RFC2565], including a designated range for private,
+   experimental use.
+
+   For attribute syntaxes, the IPP Designated Expert in consultation
+   with IANA assigns the next attribute syntax code in the appropriate
+   range as specified in [RFC2565].  IANA will publish approved
+   attribute syntax registration specifications as separate files:
+
+        ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt
+
+   where 'xxx-yyy' is the new attribute syntax name.
+
+
+
+deBry, et al.                 Experimental                    [Page 119]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+6.4 Operation Extensibility
+
+   Operations may also be registered following the type2 procedures
+   described in Section 6.1, though major new operations will usually be
+   done by a new standards track RFC that augments this document.  For
+   private (unregistered) operation extensions, implementers MUST use
+   the range for the "operation-id" in requests specified in Section
+   4.4.13 "operations-supported" Printer attribute.
+
+   For operations, the IPP Designated Expert in consultation with IANA
+   assigns the next operation-id code as specified in Section 4.4.13.
+   IANA will publish approved operation registration specifications as
+   separate files:
+
+        ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt
+
+   where "Xxx-Yyy" is the new operation name.
+
+6.5 Attribute Groups
+
+   Attribute groups passed in requests and responses may be registered
+   following the type2 procedures described in Section 6.1.  The tags
+   that identify each of the attribute groups are assigned in [RFC2565].
+
+   For attribute groups, the IPP Designated Expert in consultation with
+   IANA assigns the next attribute group tag code in the appropriate
+   range as specified in [RFC2565].  IANA will publish approved
+   attribute group registration specifications as separate files:
+
+        ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
+        tag.txt
+
+   where 'xxx-yyy-tag' is the new attribute group tag name.
+
+6.6 Status Code Extensibility
+
+   Operation status codes may also be registered following the type2
+   procedures described in Section 6.1.  The values for status codes are
+   allocated in ranges as specified in Section 13 for each status code
+   class:
+
+     "informational" - Request received, continuing process
+     "successful" - The action was successfully received, understood,
+        and accepted
+     "redirection" - Further action must be taken in order to complete
+        the request
+     "client-error" - The request contains bad syntax or cannot be
+        fulfilled
+
+
+
+deBry, et al.                 Experimental                    [Page 120]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     "server-error" - The IPP object  failed to fulfill an apparently
+        valid request
+
+   For private (unregistered) operation status code extensions,
+   implementers MUST use the top of each range as specified in Section
+   13.
+
+   For operation status codes, the IPP Designated Expert in consultation
+   with IANA assigns the next status code in the appropriate class range
+   as specified in Section 13.  IANA will publish approved status code
+   registration specifications as separate files:
+
+        ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt
+
+   where "xxx-yyy" is the new operation status code keyword.
+
+6.7 Registration of MIME types/sub-types for document-formats
+
+   The "document-format" attribute's syntax is 'mimeMediaType'.  This
+   means that valid values are Internet Media Types (see Section 4.1.9).
+   RFC 2045 [RFC2045] defines the syntax for valid Internet media types.
+   IANA is the registry for all Internet media types.
+
+6.8 Registration of charsets for use in 'charset' attribute values
+
+   The "attributes-charset" attribute's syntax is 'charset'.  This means
+   that valid values are charsets names.  When a charset in the IANA
+   registry has more than one name (alias), the name labeled as
+   "(preferred MIME name)", if present, MUST be used (see Section
+   4.1.7).  IANA is the registry for charsets following the procedures
+   of [RFC2278].
+
+7. Internationalization Considerations
+
+   Some of the attributes have values that are text strings and names
+   which are intended for human understanding rather than machine
+   understanding (see the 'text' and 'name' attribute syntaxes in
+   Sections 4.1.1 and 4.1.2).
+
+   In each operation request, the client
+
+     - identifies the charset and natural language of the request which
+       affects each supplied 'text' and 'name' attribute value, and
+     - requests the charset and natural language for attributes returned
+       by the IPP object in operation responses (as described in Section
+       3.1.4.1).
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 121]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   In addition, the client MAY separately and individually identify the
+   Natural Language Override of a supplied 'text' or 'name' attribute
+   using the 'textWithLanguage' and 'nameWithLanguage' technique
+   described section 4.1.1.2 and 4.1.2.2 respectively.
+
+   All IPP objects MUST support the UTF-8 [RFC2279] charset in all '
+   text' and 'name' attributes supported.  If an IPP object supports
+   more than the UTF-8 charset, the object MUST convert between them in
+   order to return the requested charset to the client according to
+   Section 3.1.4.2.  If an IPP object supports more than one natural
+   language, the object SHOULD return 'text' and 'name' values in the
+   natural language requested where those values are generated by the
+   Printer (see Section 3.1.4.1).
+
+   For Printers that support multiple charsets and/or multiple natural
+   languages in 'text' and 'name' attributes, different jobs may have
+   been submitted in differing charsets and/or natural languages.  All
+   responses MUST be returned in the charset requested by the client.
+   However, the Get-Jobs operation uses the 'textWithLanguage' and '
+   nameWithLanguage' mechanism to identify the differing natural
+   languages with each job attribute returned.
+
+   The Printer object also has configured charset and natural language
+   attributes.   The client can query the Printer object to determine
+   the list of charsets and natural languages supported by the Printer
+   object and what the Printer object's configured values are.  See the
+   "charset-configured", "charset-supported", "natural-language-
+   configured", and "generated-natural-language-supported" Printer
+   description attributes for more details.
+
+   The "charset-supported" attributed identifies the supported charsets.
+   If a charset is supported, the IPP object MUST be capable of
+   converting to and from that charset into any other supported charset.
+   In many cases, an IPP object will support only one charset and it
+   MUST be the UTF-8 charset.
+
+   The "charset-configured" attribute identifies the one supported
+   charset which is the native charset given the current configuration
+   of the IPP object (administrator defined).
+
+   The "generated-natural-language-supported" attribute identifies the
+   set of supported natural languages for generated messages; it is not
+   related to the set of natural languages that must be accepted for
+   client supplied 'text' and 'name' attributes.  For client supplied '
+   text' and 'name' attributes, an IPP object MUST accept ALL supplied
+   natural languages.  Just because a Printer object is currently
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 122]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   configured to support 'en-us' natural language does not mean that the
+   Printer object should reject a job if the client supplies a job name
+   that is in 'fr-ca'.
+
+   The "natural-language-configured" attribute identifies the one
+   supported natural language for generated messages which is the native
+   natural language given the current configuration of the IPP object
+   (administrator defined).
+
+   Attributes of type 'text' and 'name' are populated from different
+   sources.  These attributes can be categorized into following groups
+   (depending on the source of the attribute):
+
+     1. Some attributes are supplied by the client (e.g., the client
+        supplied "job-name", "document-name", and "requesting-user-name"
+        operation attributes along with the corresponding Job object's
+        "job-name" and "job-originating-user-name" attributes).  The IPP
+        object MUST accept these attributes in any natural language no
+        matter what the set of supported languages for generated
+        messages
+     2. Some attributes are supplied by the system administrator (e.g.,
+        the Printer object's "printer-name" and "printer-location"
+        attributes).  These too can be in any natural language.  If the
+        natural language for these attributes is different than what a
+        client requests, then they must be reported using the Natural
+        Language Override mechanism.
+     3. Some attributes are supplied by the device manufacturer (e.g.,
+        the Printer object's "printer-make-and-model" attribute).  These
+        too can be in any natural language.  If the natural language for
+        these attributes is different than what a client requests, then
+        they must be reported using the Natural Language Override
+        mechanism.
+     4. Some attributes are supplied by the operator (e.g., the Job
+        object's "job-message-from-operator" attribute). These too can
+        be in any natural language.  If the natural language for these
+        attributes is different than what a client requests, then they
+        must be reported using the Natural Language Override mechanism.
+     5. Some attributes are generated by the IPP object (e.g., the Job
+        object's "job-state-message" attribute, the Printer object's
+        "printer-state-message" attribute, and the "status-message"
+        operation attribute).  These attributes can only be in one of
+        the "generated-natural-language-supported" natural languages.
+        If a client requests some natural language for these attributes
+        other than one of the supported values, the IPP object SHOULD
+        respond using the value of the "natural-language-configured"
+        attribute (using the Natural Language Override mechanism if
+        needed).
+
+
+
+
+deBry, et al.                 Experimental                    [Page 123]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   The 'text' and 'name' attributes specified in this version of this
+   document (additional ones will be registered according to the
+   procedures in Section 6) are:
+
+     Attributes                      Source
+     --------------------------      ----------
+     Operation Attributes
+        job-name (name)               client
+        document-name (name)          client
+        requesting-user-name (name)   client
+        status-message                Job or Printer object
+
+     Job Template Attributes:
+        job-hold-until)          client matches administrator-configured
+            (keyword | name
+        job-hold-until-default   client matches administrator-configured
+            (keyword | name)
+        job-hold-until-supported client matches administrator-configured
+            (keyword | name)
+        job-sheets               client matches administrator-configured
+            (keyword | name)
+        job-sheets-default       client matches administrator-configured
+            (keyword | name)
+        job-sheets-supported     client matches administrator-configured
+            (keyword | name)
+        media                    client matches administrator-configured
+            (keyword | name)
+        media-default            client matches administrator-configured
+            (keyword | name)
+        media-supported          client matches administrator-configured
+            (keyword | name)
+        media-ready              client matches administrator-configured
+            (keyword | name)
+
+     Job Description Attributes:
+        job-name (name)               client or Printer object
+        job-originating-user-name (name)   Printer object
+        job-state-message (text)      Job or Printer object
+        output-device-assigned (name(127)) administrator
+        job-message-from-operator (text(127))   operator
+
+     Printer Description Attributes:
+        printer-name (name(127))      administrator
+        printer-location (text(127))  administrator
+        printer-info (text(127))      administrator
+        printer-make-and-model (text(127)) administrator or manufacturer
+        printer-state-message (text)  Printer object
+        printer-message-from-operator (text(127))    operator
+
+
+
+deBry, et al.                 Experimental                    [Page 124]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+8. Security Considerations
+
+   Some IPP objects MAY be deployed over protocol stacks that support
+   Secure Socket Layer Version 3 (SSL3) [SSL].  Note:  SSL3 is not an
+   IETF standards track specification.  Other IPP objects MAY be
+   deployed over protocol stacks that do not support SSL3.  Some IPP
+   objects MAY be deployed over both types of protocol stacks.  Those
+   IPP objects that support SSL3, are capable of supporting mutual
+   authentication as well as privacy of messages via multiple encryption
+   schemes.  An important point about security related information for
+   SSL3 access to an IPP object, is that the security-related parameters
+   (authentication, encryption keys, etc.) are "out-of-band" to the
+   actual IPP protocol.
+
+   An IPP object that does not support SSL3 MAY elect to support a
+   transport layer that provides other security mechanisms.  For
+   example, in a mapping of IPP over HTTP/1.1 [RFC2565], if the IPP
+   object does not support SSL3, HTTP still allows for client
+   authentication using Digest Access Authentication (DAA) [RFC2069].
+
+   It is difficult to anticipate the security risks that might exist in
+   any given IPP environment. For example, if IPP is used within a given
+   corporation over a private network, the risks of exposing document
+   data may be low enough that the corporation will choose not to use
+   encryption on that data.  However, if the connection between the
+   client and the IPP object is over a public network, the client may
+   wish to protect the content of the information during transmission
+   through the network with encryption.
+
+   Furthermore, the value of the information being printed may vary from
+   one IPP environment to the next. Printing payroll checks, for
+   example, would have a different value than printing public
+   information from a file.  There is also the possibly of denial-of-
+   service attacks, but denial-of-service attacks against printing
+   resources are not well understood and there is no published
+   precedents regarding this scenario.
+
+   Once the authenticated identity of the requester has been supplied to
+   the IPP object, the object uses that identity to enforce any
+   authorization policy that might be in place.  For example, one site's
+   policy might be that only the job owner is allowed to cancel a job.
+   The details and mechanisms to set up a particular access control
+   policy are not part of IPP/1.0, and must be established via some
+   other type of administrative or access control framework.  However,
+   there are operation status codes that allow an IPP server to return
+   information back to a client about any potential access control
+   violations for an IPP object.
+
+
+
+
+deBry, et al.                 Experimental                    [Page 125]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   During a create operation, the client's identity is recorded in the
+   Job object in an implementation-defined attribute.  This information
+   can be used to verify a client's identity for subsequent operations
+   on that Job object in order to enforce any access control policy that
+   might be in effect.  See section 8.3 below for more details.
+
+   Since the security levels or the specific threats that any given IPP
+   system administrator may be concerned with cannot be anticipated, IPP
+   MUST be capable of operating with different security mechanisms and
+   security policies as required by the individual installation.
+   Security policies might vary from very strong, to very weak, to none
+   at all, and corresponding security mechanisms will be required. SSL3
+   supports the type of negotiated levels of security required by most,
+   if not all, potential IPP environments. IPP environments that require
+   no security can elect to deploy IPP objects that do not utilize the
+   optional SSL3 security mechanisms.
+
+8.1 Security Scenarios
+
+   The following sections describe specific security attacks for IPP
+   environments.  Where examples are provided they should be considered
+   illustrative of the environment and not an exhaustive set. Not all of
+   these environments will necessarily be addressed in initial
+   implementations of IPP.
+
+8.1.1 Client and Server in the Same Security Domain
+
+   This environment is typical of internal networks where traditional
+   office workers print the output of personal productivity applications
+   on shared work-group printers, or where batch applications print
+   their output on large production printers. Although the identity of
+   the user may be trusted in this environment, a user might want to
+   protect the content of a document against such attacks as
+   eavesdropping, replaying or tampering.
+
+8.1.2 Client and Server in Different Security Domains
+
+   Examples of this environment include printing a document created by
+   the client on a publicly available printer, such as at a commercial
+   print shop; or printing a document remotely on a business associate's
+   printer.  This latter operation is functionally equivalent to sending
+   the document to the business associate as a facsimile. Printing
+   sensitive information on a Printer in a different security domain
+   requires strong security measures. In this environment authentication
+   of the printer is required as well as protection against unauthorized
+   use of print resources. Since the document crosses security domains,
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 126]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   protection against eavesdropping and document tampering are also
+   required. It will also be important in this environment to protect
+   Printers against "spamming" and malicious document content.
+
+8.1.3 Print by Reference
+
+   When the document is not stored on the client, printing can be done
+   by reference. That is, the print request can contain a reference, or
+   pointer, to the document instead of the actual document itself.
+   Standard methods currently do not exist for remote entities to
+   "assume" the credentials of a client for forwarding requests to a 3rd
+   party. It is anticipated that Print-By-Reference will be used to
+   access "public" documents and that sophisticated methods for
+   authenticating "proxies" will not be specified for version 1 of IPP.
+
+8.2 URIs for SSL3 and non-SSL3 Access
+
+   As described earlier, an IPP object can support SSL3 access, non-SSL3
+   access, or both.  The "printer-uri-supported" attribute contains the
+   Printer object's URI(s).  Its companion attribute, "uri-security-
+   supported", identifies the security mechanism used for each URI
+   listed in the "printer-uri-supported" attribute.  For each Printer
+   operation request, a client MUST supply only one URI in the
+   "printer-uri" operation attribute.  In other words, even though the
+   Printer supports more than one URI, the client only interacts with
+   the Printer object using one if its URIs.  This duality is not needed
+   for Job objects, since the Printer objects is the factory for Job
+   objects, and the Printer object will generate the correct URI for new
+   Job objects depending on the Printer object's security configuration.
+
+8.3 The "requesting-user-name" (name(MAX)) Operation Attribute
+
+   Each operation MUST specify the user who is performing the operation
+   in both of the following two ways:
+
+     1) via the REQUIRED "requesting-user-name" operation attribute that
+        a client SHOULD supply in all operations. The client MUST obtain
+        the value for this attribute from an environmental or network
+        login name for the user, rather than allowing the user to supply
+        any value. If the client does not supply a value for
+        "requesting-user-name", the printer MUST assume that the client
+        is supplying some anonymous name, such as "anonymous".
+     2) via an authentication mechanism of the underlying transport
+        which may be configured to give no authentication information.
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 127]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   There are six cases to consider:
+
+     a) the authentication mechanism gives no information, and the
+        client doesn't specify  "requesting-user-name".
+     b) the authentication mechanism gives no information, but the
+        client specifies "requesting-user-name".
+     c) the authentication mechanism specifies a user which has no human
+        readable representation, and the client doesn't specify
+        "requesting-user-name".
+     d) the authentication mechanism specifies a user which has no human
+        readable representation, but the client specifies "requesting-
+        user-name".
+     e) the authentication mechanism specifies a user which has a human
+        readable representation. The Printer object ignores the
+        "requesting-user-name".
+     f) the authentication mechanism specifies a user who is trusted and
+        whose name means that the value of the "requesting-user-name",
+        which MUST be present, is treated as the authenticated name.
+
+   Note:  Case "f" is intended for a tightly coupled gateway and server
+   to work together so that the "user" name is able to be that of the
+   gateway client and not that of the gateway.  Because most, if not
+   all, system vendors will initially implement IPP via a gateway into
+   their existing print system, this mechanism is necessary unless the
+   authentication mechanism allows a gateway (client) to act on behalf
+   of some other client.
+
+   The user-name has two forms:
+
+     - one that is human readable: it is held in the REQUIRED "job-
+       originating-user-name" Job Description attribute which is set
+       during the job creation operations. It is used for presentation
+       only, such as returning in queries or printing on start sheets
+     - one for authorization: it is held in an undefined (by IPP) Job
+       object attribute which is set by the job creation operation.  It
+       is used to authorize other operations, such as Send-Document,
+       Send-URI, Cancel-Job, to determine the user when the "my-jobs"
+       attribute is specified with Get-Jobs, and to limit what
+       attributes and values to return with Get-Job-Attributes and Get-
+       Jobs.
+
+   The human readable user name:
+
+     - is the value of the "requesting-user-name" for cases b, d and f.
+     - comes from the authentication mechanism for case e
+     - is some anonymous name, such as "anonymous" for cases a and c.
+
+   The user name used for authorization:
+
+
+
+deBry, et al.                 Experimental                    [Page 128]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     - is the value of the "requesting-user-name" for cases b  and f.
+     - comes from the authentication mechanism for cases c, d and  e
+     - is some anonymous name, such as "anonymous" for case a.
+
+   The essence of these rules for resolving conflicting sources of
+   user-names is that a printer implementation is free to pick either
+   source as long as it achieves consistent results.  That is, if a user
+   uses the same path for a series of requests, the requests MUST appear
+   to come from the same user from the standpoint of both the human-
+   readable user name and the user name for authorization.  This rule
+   MUST continue to apply even if a request could be authenticated by
+   two or more mechanisms.  It doesn't matter which of  several
+   authentication mechanisms a Printer uses as long as it achieves
+   consistent results.  If a client uses more than one authentication
+   mechanism, it is recommended that an administrator make all
+   credentials resolve to the same user and user-name as much as
+   possible.
+
+8.4 Restricted Queries
+
+   In many IPP operations, a client supplies a list of attributes to be
+   returned in the response.  For security reasons, an IPP object may be
+   configured not to return all attributes (or all values) that a client
+   requests.  The job attributes returned MAY depend on whether the
+   requesting user is the same as the user that submitted the job. The
+   IPP object MAY even return none of the requested attributes. In such
+   cases, the status returned is the same as if the object had returned
+   all requested attributes.  The client cannot tell by such a response
+   whether the requested attribute was present or absent on the object.
+
+8.5 Queries on jobs submitted using non-IPP protocols
+
+   If the device that an IPP Printer is representing is able to accept
+   jobs using other job submission protocols in addition to IPP, it is
+   RECOMMENDED that such an implementation at least allow such "foreign"
+   jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as
+   'unknown'.  Such an implementation NEED NOT support all of the same
+   IPP job attributes as for IPP jobs.  The IPP object returns the '
+   unknown' out-of-band value for any requested attribute of a foreign
+   job that is supported for IPP jobs, but not for foreign jobs.
+
+   It is further RECOMMENDED, that the IPP Printer generate "job-id" and
+   "job-uri" values for such "foreign jobs", if possible, so that they
+   may be targets of other IPP operations, such as Get-Job-Attributes
+   and Cancel-Job.  Such an implementation also needs to deal with the
+   problem of authentication of such foreign jobs.  One approach would
+   be to treat all such foreign jobs as belonging to users other than
+   the user of the IPP client.  Another approach would be for the
+
+
+
+deBry, et al.                 Experimental                    [Page 129]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   foreign job to belong to 'anonymous'.  Only if the IPP client has
+   been authenticated as an operator or administrator of the IPP Printer
+   object, could the foreign jobs be queried by an IPP request.
+   Alternatively, if the security policy is to allow users to query
+   other users' jobs, then the foreign jobs would also be visible to an
+   end-user IPP client using Get-Jobs and Get-Job-Attributes.
+
+8.6 IPP Security Application Profile for SSL3
+
+   The IPP application profile for SSL3 follows the "Secure Socket
+   Layer" requirement as documented in the SSL3 specification [SSL].
+   For interoperability, the SSL3 cipher suites are:
+
+        SSL_RSA_WITH_RC4_128_MD5
+        SSL_RSA_WITH_3DES_EDE_CBC_SHA
+        SSL_RSA_WITH_DES_CBC_SHA
+        SSL_RSA_EXPORT_WITH_RC4_40_MD5
+        SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
+        SSL_RSA_WITH_NULL_MD5
+
+   Client implementations MUST NOT assume any other cipher suites are
+   supported by an IPP Printer object.
+
+   If a conforming IPP object supports SSL3, it MUST implement and
+   support the cipher suites listed above and MAY support additional
+   cipher suites.
+
+   A conforming IPP client SHOULD support SSL3 including the cipher
+   suites listed above.  A conforming IPP client MAY support additional
+   cipher suites.
+
+   It is possible that due to certain government export restrictions
+   some non-compliant versions of this extension could be deployed.
+   Implementations wishing to inter-operate with such non-compliant
+   versions MAY offer the SSL_RSA_EXPORT_WITH_RC4_40_MD5 and
+   SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 mechanisms.  However, since 40 bit
+   ciphers are known to be vulnerable to attack by current technology,
+   any client which actives a 40 bit cipher MUST NOT indicate to the
+   user that the connection is completely secure from eavesdropping.
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 130]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+9. References
+
+   [ASCII]      Coded Character Set - 7-bit American Standard Code for
+                Information Interchange (ASCII), ANSI X3.4-1986. This
+                standard is the specification of the US-ASCII charset.
+
+   [HTPP]       J. Barnett, K. Carter, R. DeBry,  "Initial Draft -
+                Hypertext Printing Protocol - HTPP/1.0", October 1996.
+                ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/
+                overview.ps.gz
+
+   [IANA-CS]    IANA Registry of Coded Character Sets:
+                ftp://ftp.isi.edu/in-notes/iana/assignments/character-
+                sets
+
+   [IANA-MT]    IANA Registry of Media Types:  ftp://ftp.isi.edu/in-
+                notes/iana/assignments/media-types/
+
+   [ipp-iig]    Hastings, T. and C. Manros, "Internet Printing
+                Protocol/1.0:  Implementer's Guide", Work in Progress.
+
+   [ISO10646-1] ISO/IEC 10646-1:1993, "Information technology --
+                Universal Multiple-Octet Coded Character Set (UCS) -
+                Part 1: Architecture and Basic Multilingual Plane,
+                JTC1/SC2."
+
+   [ISO8859-1]  ISO/IEC 8859-1:1987, "Information technology -- 8-bit
+                One-Byte Coded Character Set - Part 1: Latin Alphabet Nr
+                1", 1987, JTC1/SC2.
+
+   [ISO10175]   ISO/IEC 10175 Document Printing Application (DPA), June
+                1996.
+
+   [LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P.
+                Zehler, "LDPA - Lightweight Document Printing
+                Application", October 1996,
+                ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
+
+   [P1387.4]    Kirk, M. (Editor), POSIX System Administration - Part 4:
+                Printing Interfaces, POSIX 1387.4 D8, 1994.
+
+   [PSIS]       Herriot, R. (editor), X/Open A Printing System
+                Interoperability Specification (PSIS), August 1995.
+
+   [PWG]        Printer Working Group, http://www.pwg.org.
+
+   [RFC1035]    Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
+                SPECIFICATION", STD 13, RFC 1035, November 1987.
+
+
+
+deBry, et al.                 Experimental                    [Page 131]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   [RFC1759]    Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+                Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+   [RFC1766]    Alvestrand, H., "Tags for the Identification of
+                Languages", RFC 1766, March 1995.
+
+   [RFC1179]    McLaughlin, L. (Editor), "Line Printer Daemon Protocol",
+                RFC 1179, August 1990.
+
+   [RFC1952]    Deutsch, P., "GZIP file format specification version
+                4.3", RFC 1952, May 1996.
+
+   [RFC2045]    Freed, N. and N. Borenstein, " Multipurpose Internet
+                Mail Extensions (MIME) Part One: Format of Internet
+                Message Bodies", RFC 2045, November 1996.
+
+   [RFC2046]    Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+                Extensions (MIME) Part Two: Media Types", RFC 2046,
+                November 1996.
+
+   [RFC2048]    Freed, N., Klensin, J. and J. Postel, "Multipurpose
+                Internet Mail Extension (MIME) Part Four: Registration
+                Procedures", RFC 2048, November 1996.
+
+   [RFC2068]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T.
+                Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+                RFC 2068, January 1997.
+
+   [RFC2069]    Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+                Luotonen, A., Sink, E. and L. Stewart, "An Extension to
+                HTTP: Digest Access Authentication", RFC 2069, January
+                1997.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2228]    Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
+                2228, October 1997.
+
+   [RFC2277]    Alvestrand, H., "IETF Policy on Character Sets and
+                Languages" RFC 2277, January 1998.
+
+   [RFC2278]    Freed, N. and J. Postel:  "IANA Charset Registration
+                Procedures", BCP 19, RFC 2278, January 1998.
+
+   [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", RFC 2279, January 1998.
+
+
+
+
+deBry, et al.                 Experimental                    [Page 132]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   [RFC2316]    Bellovin, S., "Report of the IAB Security Architecture
+                Workshop", RFC 2316, April 1998.
+
+   [RFC2396]    Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+                Resource Identifiers (URI): Generic Syntax", RFC 2396,
+                August 1998.
+
+   [RFC2434]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+                IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+                October 1998.
+
+   [RFC2565]    Herriot, R., Butler, S., Moore, P. and R. Tuner
+                "Internet Printing Protocol/1.0: Encoding and
+                Transport", RFC 2565, April 1999.
+
+   [RFC2567]    Wright, D.,  "Design Goals for an Internet Printing
+                Protocol", RFC 2567, April 1999.
+
+   [RFC2568]    Zilles, S., "Rationale for the Structure and Model and
+                Protocol for the Internet Printing Protocol", RFC 2568,
+                April 1999.
+
+   [RFC2569]    Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+                "Mapping between LPD and IPP Protocols", RFC 2569, April
+                1999.
+
+   [RFC2579]    McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+                "Textual Conventions for SMIv2", STD 58, RFC 2579, April
+                1999.
+
+   [SSL]        Netscape, The SSL Protocol, Version 3, (Text version
+                3.02), November 1996.
+
+   [SWP]        P. Moore, B. Jahromi, S. Butler, "Simple Web Printing
+                SWP/1.0", May 7, 1997,
+                ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 133]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+10. Authors' Addresses
+
+   Scott A. Isaacson (Editor)
+   Novell, Inc.
+   122 E 1700 S
+   Provo, UT   84606
+
+   Phone: 801-861-7366
+   Fax:   801-861-2517
+   EMail: sisaacson@novell.com
+
+
+   Tom Hastings
+   Xerox Corporation
+   737 Hawaii St.
+   El Segundo, CA   90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Robert Herriot
+   Xerox Corporation
+   3400 Hillview Ave., Bldg #1
+   Palo Alto, CA 94304
+
+   Phone: 650-813-7696
+   Fax:  650-813-6860
+   EMail: robert.herriot@pahv.xerox.com
+
+
+   Roger deBry
+   Utah Valley State College
+   Orem, UT 84058
+
+   Phone: (801) 222-8000
+   EMail: debryro@uvsc.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 134]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Patrick Powell
+   Astart Technologies
+   9475 Chesapeake Dr., Suite D
+   San Diego, CA  95123
+
+   Phone: (619) 874-6543
+   Fax: (619) 279-8424
+   EMail: papowell@astart.com
+
+   IPP Mailing List:  ipp@pwg.org
+   IPP Mailing List Subscription: ipp-request@pwg.org
+   IPP Web Page:  http://www.pwg.org/ipp/
+
+   Implementers of this specification are encouraged to join IPP Mailing
+   List in order to participate in any discussions of clarification
+   issues and review of registration proposals for additional attributes
+   and values.
+
+   Other Participants:
+
+      Chuck Adams - Tektronix
+      Jeff Barnett - IBM
+      Ron Bergman - Dataproducts Corp.
+      Sylvan Butler - HP
+      Keith Carter - IBM Corporation
+      Jeff Copeland - QMS
+      Andy Davidson - Tektronix
+      Mabry Dozier - QMS
+      Lee Farrell - Canon Information Systems
+      Steve Gebert - IBM
+      Babek Jahromi - Microsoft
+      David Kellerman - Northlake Software
+      Rick Landau - Digital
+      Greg LeClair - Epson
+      Harry Lewis - IBM
+      Pete Loya - HP
+      Ray Lutz - Cognisys
+      Mike MacKay - Novell, Inc.
+      Daniel Manchala - Xerox
+      Carl-Uno Manros - Xerox
+      Jay Martin - Underscore
+      Larry Masinter - Xerox
+      Stan McConnell - Xerox
+      Ira McDonald - High North Inc.
+      Paul Moore - Microsoft
+      Tetsuya Morita - Ricoh
+      Yuichi Niwa - Ricoh
+      Pat Nogay - IBM
+
+
+
+deBry, et al.                 Experimental                    [Page 135]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+      Ron Norton - Printronics
+      Bob Pentecost - HP
+      Rob Rhoads - Intel
+      Xavier Riley - Xerox
+      David Roach - Unisys
+      Stuart Rowley - Kyocera
+      Hiroyuki Sato - Canon
+      Bob Setterbo - Adobe
+      Devon Taylor - Novell, Inc.
+      Mike Timperman - Lexmark
+      Randy Turner - Sharp
+      Atsushi Yuki - Kyocera
+      Rick Yardumian - Xerox
+      Lloyd Young - Lexmark
+      Bill Wagner - DPI
+      Jim Walker - DAZEL
+      Chris Wellens - Interworking Labs
+      Rob Whittle - Novell, Inc.
+      Don Wright - Lexmark
+      Peter Zehler - Xerox
+      Steve Zilles - Adobe
+
+11. Formats for IPP Registration Proposals
+
+   In order to propose an IPP extension for registration, the proposer
+   must submit an application to IANA by email to "iana@iana.org" or by
+   filling out the appropriate form on the IANA web pages
+   (http://www.iana.org).  This section specifies the required
+   information and the formats for proposing registrations of extensions
+   to IPP as provided in Section 6 for:
+
+     1. type2 'keyword' attribute values
+     2. type3 'keyword' attribute values
+     3. type2 'enum' attribute values
+     4. type3 'enum' attribute values
+     5. attributes
+     6. attribute syntaxes
+     7. operations
+     8. status codes
+
+11.1 Type2 keyword attribute values registration
+
+   Type of registration:  type2 keyword attribute value
+   Name of attribute to which this keyword specification is to be added:
+   Proposed keyword name of this keyword value:
+   Specification of this keyword value (follow the style of IPP Model
+   Section 4.1.2.3):
+   Name of proposer:
+
+
+
+deBry, et al.                 Experimental                    [Page 136]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type2 keywords, the Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.2 Type3 keyword attribute values registration
+
+   Type of registration:  type3 keyword attribute value
+   Name of attribute to which this keyword specification is to be added:
+   Proposed keyword name of this keyword value:
+   Specification of this keyword value (follow the style of IPP Model
+   Section 4.1.2.3):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type3 keywords, the proposer will be the point of contact
+   for the approved registration specification, if any maintenance of
+   the registration specification is needed.
+
+11.3 Type2 enum attribute values registration
+
+   Type of registration:  type2 enum attribute value
+   Name of attribute to which this enum specification is to be added:
+   Keyword symbolic name of this enum value:
+   Numeric value (to be assigned by the IPP Designated Expert in
+   consultation with IANA):
+   Specification of this enum value (follow the style of IPP Model
+   Section 4.1.4):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type2 enums, the Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.4 Type3 enum attribute values registration
+
+   Type of registration:  type3 enum attribute value
+   Name of attribute to which this enum specification is to be added:
+   Keyword symbolic name of this enum value:
+   Numeric value (to be assigned by the IPP Designated Expert in
+   consultation with IANA):
+   Specification of this enum value (follow the style of IPP Model
+   Section 4.1.4):
+
+
+
+deBry, et al.                 Experimental                    [Page 137]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type3 enums, the proposer will be the point of contact for
+   the approved registration specification, if any maintenance of the
+   registration specification is needed.
+
+11.5 Attribute registration
+
+   Type of registration:  attribute
+   Proposed keyword name of this attribute:
+   Types of attribute (Operation, Job Template, Job Description,
+   Printer Description):
+   Operations to be used with if the attribute is an operation
+   attribute:
+   Object (Job, Printer, etc. if bound to an object):
+   Attribute syntax(es) (include 1setOf and range as in Section 4.2):
+   If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
+   If this is a Printer attribute, MAY the value returned depend on
+   "document-format" (See Section 6.2):
+   If this is a Job Template attribute, how does its specification
+   depend on the value of the "multiple-document-handling" attribute:
+   Specification of this attribute (follow the style of IPP Model
+   Section 4.2):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For attributes, the IPP Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.6 Attribute Syntax registration
+
+   Type of registration:  attribute syntax
+   Proposed name of this attribute syntax:
+   Type of attribute syntax (integer, octetString, character-string,
+   see [RFC2565]):
+   Numeric value (to be assigned by the IPP Designated Expert in
+   consultation with IANA):
+   Specification of this attribute (follow the style of IPP Model
+   Section 4.1):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 138]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Note:  For attribute syntaxes, the IPP Designated Expert will be the
+   point of contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.7 Operation registration
+
+   Type of registration:  operation
+   Proposed name of this operation:
+   Numeric operation-id value (to be assigned by the IPP Designated
+   Expert in consultation with IANA):
+   Object Target (Job, Printer, etc. that operation is upon):
+   Specification of this attribute (follow the style of IPP Model
+   Section 3):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For operations, the IPP Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.8 Attribute Group registration
+
+   Type of registration:  attribute group
+   Proposed name of this attribute group:
+   Numeric tag according to [RFC2565] (to be assigned by the IPP
+   Designated Expert in consultation with IANA):
+   Operation requests and group number for each operation in which the
+   attribute group occurs:
+   Operation responses and group number for each operation in which the
+   attribute group occurs:
+   Specification of this attribute group (follow the style of IPP Model
+   Section 3):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For attribute groups, the IPP Designated Expert will be the
+   point of contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.9 Status code registration
+
+   Type of registration:  status code
+   Keyword symbolic name of this status code value:
+   Numeric value (to be assigned by the IPP Designated Expert in
+   consultation with IANA):
+   Operations that this status code may be used with:
+
+
+
+deBry, et al.                 Experimental                    [Page 139]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   Specification of this status code (follow the style of IPP Model
+   Section 14 APPENDIX B:  Status Codes and Suggested Status Code
+   Messages):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For status codes, the Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 140]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+12. APPENDIX A: Terminology
+
+   This specification uses the terminology defined in this section.
+
+12.1 Conformance Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and  "OPTIONAL" in this document are to be
+   interpreted as described in RFC 2119 [RFC2119].
+
+12.1.1 NEED NOT
+
+   This term is not included in RFC 2119.  The verb "NEED NOT" indicates
+   an action that the subject of the sentence does not have to implement
+   in order to claim conformance to the standard.  The verb "NEED NOT"
+   is used instead of "MAY NOT" since "MAY NOT" sounds like a
+   prohibition.
+
+12.2 Model Terminology
+
+12.2.1 Keyword
+
+   Keywords are used within this document as identifiers of semantic
+   entities within the abstract model (see section 4.1.2.3).  Attribute
+   names, some attribute values, attribute syntaxes, and attribute group
+   names are represented as keywords.
+
+12.2.2 Attributes
+
+   An attribute is an item of information that is associated with an
+   instance of an IPP object.  An attribute consists of an attribute
+   name and one or more attribute values.  Each attribute has a specific
+   attribute syntax.  All object attributes are defined in section 4 and
+   all operation attributes are defined in section 3.
+
+   Job Template Attributes are described in section 4.2. The client
+   optionally supplies Job Template attributes in a create request
+   (operation requests that create Job objects).  The Printer object has
+   associated attributes which define supported and default values for
+   the Printer.
+
+12.2.2.1 Attribute Name
+
+   Each attribute is uniquely identified in this document by its
+   attribute name.  An attribute name is a keyword.  The keyword
+   attribute name is given in the section header describing that
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 141]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   attribute.  In running text in this document, attribute names are
+   indicated inside double quotation marks (") where the quotation marks
+   are not part of the keyword itself.
+
+12.2.2.2 Attribute Group Name
+
+   Related attributes are grouped into named groups.  The name of the
+   group is a keyword.  The group name may be used in place of naming
+   all the attributes in the group explicitly.  Attribute groups are
+   defined in section 3.
+
+12.2.2.3 Attribute Value
+
+   Each attribute has one or more values.  Attribute values are
+   represented in the syntax type specified for that attribute. In
+   running text in this document, attribute values are indicated inside
+   single quotation marks ('), whether their attribute syntax is
+   keyword, integer, text, etc.  where the quotation marks are not part
+   of the value itself.
+
+12.2.2.4 Attribute Syntax
+
+   Each attribute is defined using an explicit syntax type.  In this
+   document, each syntax type is defined as a keyword with specific
+   meaning.  The Encoding and Transport document [RFC2565] indicates the
+   actual "on-the-wire" encoding rules for each syntax type.  Attribute
+   syntax types are defined in section 4.1.
+
+12.2.3 Supports
+
+   By definition, a Printer object supports an attribute only if that
+   Printer object responds with the corresponding attribute populated
+   with some value(s) in a response to a query for that attribute.  A
+   Printer object supports an attribute value if the value is one of the
+   Printer object's "supported values" attributes.  The device behind a
+   Printer object may exhibit a behavior that corresponds to some IPP
+   attribute, but if the Printer object, when queried for that
+   attribute, doesn't respond with the attribute, then as far as IPP is
+   concerned, that implementation does not support that feature. If the
+   Printer object's "xxx-supported" attribute is not populated with a
+   particular value (even if that value is a legal value for that
+   attribute), then that Printer object does not support that particular
+   value.
+
+   A conforming implementation MUST support all REQUIRED attributes.
+   However, even for REQUIRED attributes, conformance to IPP does not
+   mandate that all implementations support all possible values
+   representing all possible job processing behaviors and features.  For
+
+
+
+deBry, et al.                 Experimental                    [Page 142]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   example, if a given instance of a Printer supports only certain
+   document formats, then that Printer responds with the "document-
+   format-supported" attribute populated with a set of values, possibly
+   only one, taken from the entire set of possible values defined for
+   that attribute. This limited set of values represents the Printer's
+   set of supported document formats.  Supporting an attribute and some
+   set of values for that attribute enables IPP end users to be aware of
+   and make use of those features associated with that attribute and
+   those values.  If an implementation chooses to not support an
+   attribute or some specific value, then IPP end users would have no
+   ability to make use of that feature within the context of IPP itself.
+   However, due to existing practice and legacy systems which are not
+   IPP aware, there might be some other mechanism outside the scope of
+   IPP to control or request the "unsupported" feature (such as embedded
+   instructions within the document data itself).
+
+   For example, consider the "finishings-supported" attribute.
+
+     1) If a Printer object is not physically capable of stapling, the
+        "finishings-supported" attribute MUST NOT be populated with the
+        value of 'staple'.
+     2) A Printer object is physically capable of stapling, however an
+        implementation chooses not to support stapling in the IPP
+        "finishings" attribute.  In this case, 'staple' MUST NOT be a
+        value in the "finishings-supported" Printer object attribute.
+        Without support for the value 'staple', an IPP end user would
+        have no means within the protocol itself to request that a Job
+        be stapled.  However, an existing document data formatter might
+        be able to request that the document be stapled directly with an
+        embedded instruction within the document data.  In this case,
+        the IPP implementation does not "support" stapling, however the
+        end user is still able to have some control over the stapling of
+        the completed job.
+     3) A Printer object is physically capable of stapling, and an
+        implementation chooses to support stapling in the IPP
+        "finishings" attribute. In this case, 'staple' MUST be a value
+        in the "finishings-supported" Printer object attribute. Doing
+        so, would enable end users to be aware of and make use of the
+        stapling feature using IPP attributes.
+
+   Even though support for Job Template attributes by a Printer object
+   is OPTIONAL, it is RECOMMENDED that if the device behind a Printer
+   object is capable of realizing any feature or function that
+   corresponds to an IPP attribute and some associated value, then that
+   implementation SHOULD support that IPP attribute and value.
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 143]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   The set of values in any of the supported value attributes is set
+   (populated) by some administrative process or automatic sensing
+   mechanism that is outside the scope of IPP.  For administrative
+   policy and control reasons, an administrator may choose to make only
+   a subset of possible values visible to the end user.  In this case,
+   the real output device behind the IPP Printer abstraction may be
+   capable of a certain feature, however an administrator is specifying
+   that access to that feature not be exposed to the end user through
+   the IPP protocol.  Also, since a Printer object may represent a
+   logical print device (not just a physical device) the actual process
+   for supporting a value is undefined and left up to the
+   implementation.  However, if a Printer object supports a value, some
+   manual human action may be needed to realize the semantic action
+   associated with the value, but no end user action is required.
+
+   For example, if one of the values in the "finishings-supported"
+   attribute is 'staple', the actual process might be an automatic
+   staple action by a physical device controlled by some command sent to
+   the device.  Or, the actual process of stapling might be a manual
+   action by an operator at an operator attended Printer object.
+
+   For another example of how supported attributes function, consider a
+   system administrator who desires to control all print jobs so that no
+   job sheets are printed in order to conserve paper.  To force no job
+   sheets, the system administrator sets the only supported value for
+   the "job-sheets-supported" attribute to 'none'.  In this case, if a
+   client requests anything except 'none', the create request is
+   rejected or the "job-sheets" value is ignored (depending on the value
+   of "ipp-attribute-fidelity").  To force the use of job start/end
+   sheets on all jobs, the administrator does not include the value '
+   none' in the "job-sheets-supported" attribute.  In this case, if a
+   client requests 'none', the create request is rejected or the "job-
+   sheets" value is ignored (again depending on the value of "ipp-
+   attribute-fidelity").
+
+12.2.4 print-stream page
+
+   A "print-stream page" is a page according to the definition of pages
+   in the language used to express the document data.
+
+12.2.5 impression
+
+   An "impression" is the image (possibly many print-stream pages in
+   different configurations) imposed onto a single media page.
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 144]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+13. APPENDIX B:  Status Codes and Suggested Status Code Messages
+
+   This section defines status code enum keywords and values that are
+   used to provide semantic information on the results of an operation
+   request.  Each operation response MUST include a status code.  The
+   response MAY also contain a status message that provides a short
+   textual description of the status.  The status code is intended for
+   use by automata, and the status message is intended for the human end
+   user.  Since the status message is an OPTIONAL component of the
+   operation response, an IPP application (i.e., a browser, GUI, print
+   driver or gateway) is NOT REQUIRED to examine or display the status
+   message, since it MAY not be returned to the application.
+
+   The prefix of the status keyword defines the class of response as
+   follows:
+
+     "informational" - Request received, continuing process
+     "successful" - The action was successfully received, understood,
+        and accepted
+     "redirection" - Further action must be taken in order to complete
+        the request
+     "client-error" - The request contains bad syntax or cannot be
+        fulfilled
+     "server-error" - The IPP object  failed to fulfill an apparently
+        valid request
+
+   As with type2 enums, IPP status codes are extensible.  IPP clients
+   are NOT REQUIRED to understand the meaning of all registered status
+   codes, though such understanding is obviously desirable.  However,
+   IPP clients MUST understand the class of any status code, as
+   indicated by the prefix, and treat any unrecognized response as being
+   equivalent to the first status code of that class, with the exception
+   that an unrecognized response MUST NOT be cached.  For example, if an
+   unrecognized status code of "client-error-xxx-yyy" 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 "client-
+   error-bad-request" status code.  In such cases, IPP applications
+   SHOULD present the OPTIONAL message (if present) to the end user
+   since the message is likely to contain human readable information
+   which will help to explain the unusual status.  The name of the enum
+   is the suggested status message for US English.
+
+   The status code values range from 0x0000 to 0x7FFF.  The value ranges
+   for each status code class are as follows:
+
+     "successful" - 0x0000 to 0x00FF
+     "informational" - 0x0100 to 0x01FF
+     "redirection" - 0x0200 to 0x02FF
+
+
+
+deBry, et al.                 Experimental                    [Page 145]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     "client-error" - 0x0400 to 0x04FF
+     "server-error" - 0x0500 to 0x05FF
+
+   The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0
+   to 5) is reserved for private use within each status code class.
+   Values 0x0600 to 0x7FFF are reserved for future assignment and MUST
+   NOT be used.
+
+13.1 Status Codes
+
+   Each status code is described below. Section 13.1.5.9 contains a
+   table that indicates which status codes apply to which operations.
+   The Implementer's Guide [ipp-iig] describe the suggested steps for
+   processing IPP attributes for all operations, including returning
+   status codes.
+
+13.1.1 Informational
+
+   This class of status code indicates a provisional response and is to
+   be used for informational purposes only.
+
+   There are no status codes defined in IPP/1.0 for this class of status
+   code.
+
+13.1.2 Successful Status Codes
+
+   This class of status code indicates that the client's request was
+   successfully received, understood, and accepted.
+
+13.1.2.1 successful-ok (0x0000)
+
+   The request has succeeded and no request attributes were substituted
+   or ignored.  In the case of a response to a create request, the '
+   successful-ok' status code indicates that the request was
+   successfully received and validated, and that the Job object has been
+   created; it does not indicate that the job has been processed.  The
+   transition of the Job object into the 'completed' state is the only
+   indicator that the job has been printed.
+
+13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)
+
+   The request has succeeded, but some supplied (1) attributes were
+   ignored or (2) unsupported values were substituted with supported
+   values or were ignored in order to perform the operation without
+   rejecting it.  Unsupported attributes, attribute syntaxes, or values
+   MUST be returned in the Unsupported Attributes group of the response
+   for all operations.  There is an exception to this rule for the query
+   operations:  Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes
+
+
+
+deBry, et al.                 Experimental                    [Page 146]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   for the "requested-attributes" operation attribute only.  When the
+   supplied values of the "requested-attributes" operation attribute are
+   requesting attributes that are not supported, the IPP object MAY, but
+   is NOT REQUIRED to, return the "requested-attributes" attribute in
+   the Unsupported Attribute response group (with the unsupported values
+   only).  See section 3.2.1.2.
+
+13.1.2.3 successful-ok-conflicting-attributes (0x0002)
+
+   The request has succeeded, but some supplied attribute values
+   conflicted with the values of other supplied attributes.  These
+   conflicting values were either (1) substituted with (supported)
+   values or (2) the attributes were removed in order to process the job
+   without rejecting it.  Attributes or values which conflict with other
+   attributes and have been substituted or ignored MUST be returned in
+   the Unsupported Attributes group of the response for all operations
+   as supplied by the client.  See section 3.2.1.2.
+
+13.1.3 Redirection Status Codes
+
+   This class of status code indicates that further action needs to be
+   taken to fulfill the request.
+
+   There are no status codes defined in IPP/1.0 for this class of status
+   code.
+
+13.1.4 Client Error Status Codes
+
+   This class of status code is intended for cases in which the client
+   seems to have erred.  The IPP object SHOULD return a message
+   containing an explanation of the error situation and whether it is a
+   temporary or permanent condition.
+
+13.1.4.1 client-error-bad-request (0x0400)
+
+   The request could not be understood by the IPP object due to
+   malformed syntax (such as the value of a fixed length attribute whose
+   length does not match the prescribed length for that attribute - see
+   the Implementer's Guide [ipp-iig] ).  The IPP application SHOULD NOT
+   repeat the request without modifications.
+
+13.1.4.2 client-error-forbidden (0x0401)
+
+   The IPP object understood the request, but is refusing to fulfill it.
+   Additional authentication information or authorization credentials
+   will not help and the request SHOULD NOT be repeated.  This status
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 147]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   code is commonly used when the IPP object does not wish to reveal
+   exactly why the request has been refused or when no other response is
+   applicable.
+
+13.1.4.3 client-error-not-authenticated (0x0402)
+
+   The request requires user authentication.  The IPP client may repeat
+   the request with suitable authentication information. If the request
+   already included authentication information, then this status code
+   indicates that authorization has been refused for those credentials.
+   If this response contains the same challenge as the prior response,
+   and the user agent has already attempted authentication at least
+   once, then the response message may contain relevant diagnostic
+   information.  This status codes reveals more information than
+   "client-error-forbidden".
+
+13.1.4.4 client-error-not-authorized (0x0403)
+
+   The requester is not authorized to perform the request.  Additional
+   authentication information or authorization credentials will not help
+   and the request SHOULD NOT be repeated.  This status code is used
+   when the IPP object wishes to reveal that the authentication
+   information is understandable, however, the requester is explicitly
+   not authorized to perform the request.  This status codes reveals
+   more information than "client-error-forbidden" and "client-error-
+   not-authenticated".
+
+13.1.4.5 client-error-not-possible (0x0404)
+
+   This status code is used when the request is for something that can
+   not happen.  For example, there might be a request to cancel a job
+   that has already been canceled or aborted by the system.  The IPP
+   client SHOULD NOT repeat the request.
+
+13.1.4.6 client-error-timeout (0x0405)
+
+   The client did not produce a request within the time that the IPP
+   object was prepared to wait.  For example, a client issued a Create-
+   Job operation and then, after a long period of time, issued a Send-
+   Document operation and this error status code was returned in
+   response to the Send-Document request  (see section 3.3.1).  The IPP
+   object might have been forced to clean up resources that had been
+   held for the waiting additional Documents.  The IPP object was forced
+   to close the Job since the client took too long.  The client SHOULD
+   NOT repeat the request without modifications.
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 148]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+13.1.4.7 client-error-not-found (0x0406)
+
+   The IPP object has not found anything matching the request URI.  No
+   indication is given of whether the condition is temporary or
+   permanent.  For example, a client with an old reference to a Job (a
+   URI) tries to cancel the Job, however in the mean time the Job might
+   have been completed and all record of it at the Printer has been
+   deleted.  This status code, 'client-error-not-found' is returned
+   indicating that the referenced Job can not be found.  This error
+   status code is also used when a client supplies a URI as a reference
+   to the document data in either a Print-URI or Send-URI operation, but
+   the document can not be found.
+
+   In practice, an IPP application should avoid a not found situation by
+   first querying and presenting a list of valid Printer URIs and Job
+   URIs to the end-user.
+
+13.1.4.8 client-error-gone (0x0407)
+
+   The requested object is no longer available and no forwarding address
+   is known.  This condition should be considered permanent.  Clients
+   with link editing capabilities should delete references to the
+   request URI after user approval.  If the IPP object does not know or
+   has no facility to determine, whether or not the condition is
+   permanent, the status code "client-error-not-found" should be used
+   instead.
+
+   This response is primarily intended to assist the task of maintenance
+   by notifying the recipient that the resource is intentionally
+   unavailable and that the IPP object administrator desires that remote
+   links to that resource be removed. 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 IPP
+   object administrator.
+
+13.1.4.9 client-error-request-entity-too-large (0x0408)
+
+   The IPP object is refusing to process a request because the request
+   entity is larger than the IPP object is willing or able to process.
+   An IPP Printer returns this status code when it limits the size of
+   print jobs and it receives a print job that exceeds that limit or
+   when the attributes are so many that their encoding causes the
+   request entity to exceed IPP object capacity.
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 149]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+13.1.4.10 client-error-request-value-too-long (0x0409)
+
+   The IPP object is refusing to service the request because one or more
+   of the client-supplied attributes has a variable length value that is
+   longer than the maximum length specified for that attribute.  The IPP
+   object might not have sufficient resources (memory, buffers, etc.) to
+   process (even temporarily), interpret, and/or ignore a value larger
+   than the maximum length.  Another use of this error code is when the
+   IPP object supports the processing of a large value that is less than
+   the maximum length, but during the processing of the request as a
+   whole, the object may pass the value onto some other system component
+   which is not able to accept the large value.  For more details, see
+   the Implementer's Guide [ipp-iig] .
+
+   Note:  For attribute values that are URIs, this rare condition is
+   only likely to occur when a client has improperly submitted a request
+   with long query information (e.g. an IPP application allows an end-
+   user to enter an invalid URI), when the client has descended into a
+   URI "black hole" of redirection (e.g., a redirected URI prefix that
+   points to a suffix of itself), or when the IPP object is under attack
+   by a client attempting to exploit security holes present in some IPP
+   objects using fixed-length buffers for reading or manipulating the
+   Request-URI.
+
+13.1.4.11 client-error-document-format-not-supported (0x040A)
+
+   The IPP object is refusing to service the request because the
+   document data is in a format, as specified in the "document-format"
+   operation attribute, that is not supported by the Printer object.
+   This error is returned independent of the client-supplied "ipp-
+   attribute-fidelity".  The Printer object MUST return this status
+   code, even if there are other attributes that are not supported as
+   well, since this error is a bigger problem than with Job Template
+   attributes.
+
+13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
+
+   In a create request, if the Printer object does not support one or
+   more attributes, attribute syntaxes, or attribute values supplied in
+   the request and the client supplied the "ipp-attributes-fidelity"
+   operation attribute with the 'true' value, the Printer object MUST
+   return this status code.  For example, if the request indicates '
+   iso-a4' media, but that media type is not supported by the Printer
+   object.  Or, if the client supplies an optional attribute and the
+   attribute itself is not even supported by the Printer.  If the "ipp-
+   attribute-fidelity" attribute is 'false', the Printer MUST ignore or
+   substitute values for unsupported attributes and values rather than
+   reject the request and return this status code.
+
+
+
+deBry, et al.                 Experimental                    [Page 150]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   For any operation where a client requests attributes (such as a Get-
+   Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if
+   the IPP object does not support one or more of the requested
+   attributes, the IPP object simply ignores the unsupported requested
+   attributes and processes the request as if they had not been
+   supplied, rather than returning this status code.  In this case, the
+   IPP object MUST return the 'successful-ok-ignored-or-substituted-
+   attributes' status code and MAY return the unsupported attributes as
+   values of the "requested-attributes" in the Unsupported Attributes
+   Group (see section 13.1.2.2).
+
+13.1.4.13 client-error-uri-scheme-not-supported (0x040C)
+
+   The type of the client supplied URI in a Print-URI or a Send-URI
+   operation is not supported.
+
+13.1.4.14 client-error-charset-not-supported (0x040D)
+
+   For any operation, if the IPP Printer does not support the charset
+   supplied by the client in the "attributes-charset" operation
+   attribute, the Printer MUST reject the operation and return this
+   status and any 'text' or 'name' attributes using the 'utf-8' charset
+   (see Section 3.1.4.1).
+
+13.1.4.15 client-error-conflicting-attributes (0x040E)
+
+   The request is rejected because some attribute values conflicted with
+   the values of other attributes which this specification does not
+   permit to be substituted or ignored.
+
+13.1.5 Server Error Status Codes
+
+   This class of status codes indicates cases in which the IPP object is
+   aware that it has erred or is incapable of performing the request.
+   The IPP object SHOULD include a message containing an explanation of
+   the error situation, and whether it is a temporary or permanent
+   condition.
+
+13.1.5.1 server-error-internal-error (0x0500)
+
+   The IPP object encountered an unexpected condition that prevented it
+   from fulfilling the request.  This error status code differs from
+   "server-error-temporary-error" in that it implies a more permanent
+   type of internal error.  It also differs from "server-error-device-
+   error" in that it implies an unexpected condition (unlike a paper-jam
+   or out-of-toner problem which is undesirable but expected).  This
+   error status code indicates that probably some knowledgeable human
+   intervention is required.
+
+
+
+deBry, et al.                 Experimental                    [Page 151]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+13.1.5.2 server-error-operation-not-supported (0x0501)
+
+   The IPP object does not support the functionality required to fulfill
+   the request. This is the appropriate response when the IPP object
+   does not recognize an operation or is not capable of supporting it.
+
+13.1.5.3 server-error-service-unavailable (0x0502)
+
+   The IPP object is currently unable to handle the request due to a
+   temporary overloading or maintenance of the IPP object.  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 the message.  If no delay is given, the IPP application
+   should handle the response as it would for a "server-error-
+   temporary-error" response.  If the condition is more permanent, the
+   error status codes "client-error-gone" or "client-error-not-found"
+   could be used.
+
+13.1.5.4 server-error-version-not-supported (0x0503)
+
+   The IPP object does not support, or refuses to support, the IPP
+   protocol version that was used in the request message.  The IPP
+   object is indicating that it is unable or unwilling to complete the
+   request using the same version as supplied in the request other than
+   with this error message. The response should contain a Message
+   describing why that version is not supported and what other versions
+   are supported by that IPP object.
+
+   A conforming IPP/1.0 client MUST specify the valid version ('1.0') on
+   each request.  A conforming IPP/1.0 object MUST NOT return this
+   status code to a conforming IPP/1.0 client.  An IPP object MUST
+   return this status code to a non-conforming IPP client.  The response
+   MUST identify in the "version-number" operation attribute the closest
+   version number that the IPP object does support.
+
+13.1.5.5 server-error-device-error (0x0504)
+
+   A printer error, such as a paper jam, occurs while the IPP object
+   processes a Print or Send operation.  The response contains the true
+   Job Status (the values of the "job-state" and "job-state-reasons"
+   attributes).  Additional information can be returned in the optional
+   "job-state-message" attribute value or in the OPTIONAL status message
+   that describes the error in more detail.  This error status code is
+   only returned in situations where the Printer is unable to accept the
+   create request because of such a device error.  For example, if the
+   Printer is unable to spool, and can only accept one job at a time,
+   the reason it might reject a create request is that the printer
+   currently has a paper jam.  In many cases however, where the Printer
+
+
+
+deBry, et al.                 Experimental                    [Page 152]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   object can accept the request even though the Printer has some error
+   condition, the 'successful-ok' status code will be returned.  In such
+   a case, the client would look at the returned Job Object Attributes
+   or later query the Printer to determine its state and state reasons.
+
+13.1.5.6 server-error-temporary-error (0x0505)
+
+   A temporary error such as a buffer full write error, a memory
+   overflow (i.e. the document data exceeds the memory of the Printer),
+   or a disk full condition, occurs while the IPP Printer processes an
+   operation.  The client MAY try the unmodified request again at some
+   later point in time with an expectation that the temporary internal
+   error condition may have been cleared.  Alternatively, as an
+   implementation option, a Printer object MAY delay the response until
+   the temporary condition is cleared so that no error is returned.
+
+13.1.5.7 server-error-not-accepting-jobs (0x0506)
+
+   A temporary error indicating that the Printer is not currently
+   accepting jobs, because the administrator has set the value of the
+   Printer's "printer-is-not-accepting-jobs" attribute to 'false' (by
+   means outside of IPP/1.0).
+
+13.1.5.8 server-error-busy (0x0507)
+
+   A temporary error indicating that the Printer is too busy processing
+   jobs and/or other requests. The client SHOULD try the unmodified
+   request again at some later point in time with an expectation that
+   the temporary busy condition will have been cleared.
+
+13.1.5.9 server-error-job-canceled (0x0508)
+
+   An error indicating that the job has been canceled by an operator or
+   the system while the client was transmitting the data to the IPP
+   Printer.  If a job-id and job-uri had been created, then they are
+   returned in the Print-Job, Send-Document, or Send-URI response as
+   usual; otherwise, no job-id and job-uri are returned in the response.
+
+13.2 Status Codes for IPP Operations
+
+   PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document
+   SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and
+   Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 153]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+                                                  IPP Operations
+   IPP Status Keyword                       PJ PU CJ SD SU V GA GJ C
+   ------------------                       -- -- -- -- -- - -- -- -
+   successful-ok                            x  x  x  x  x  x x  x  x
+   successful-ok-ignored-or-substituted-    x  x  x  x  x  x x  x  x
+        attributes
+   successful-ok-conflicting-attributes     x  x  x  x  x  x x  x  x
+   client-error-bad-request                 x  x  x  x  x  x x  x  x
+   client-error-forbidden                   x  x  x  x  x  x x  x  x
+   client-error-not-authenticated           x  x  x  x  x  x x  x  x
+   client-error-not-authorized              x  x  x  x  x  x x  x  x
+   client-error-not-possible                x  x  x  x  x  x x  x  x
+   client-error-timeout                           x  x
+   client-error-not-found                   x  x  x  x  x  x x  x  x
+   client-error-gone                        x  x  x  x  x  x x  x  x
+   client-error-request-entity-too-large    x  x  x  x  x  x x  x  x
+   client-error-request-value-too-long      x  x  x  x  x  x x  x  x
+   client-error-document-format-not-        x  x     x  x  x x
+        supported
+   client-error-attributes-or-values-not-   x  x  x  x  x  x x  x  x
+        supported
+   client-error-uri-scheme-not-supported       x        x
+   client-error-charset-not-supported       x  x  x  x  x  x x  x  x
+   client-error-conflicting-attributes      x  x  x  x  x  x x  x  x
+   server-error-internal-error              x  x  x  x  x  x x  x  x
+   server-error-operation-not-supported        x  x  x  x
+   server-error-service-unavailable         x  x  x  x  x  x x  x  x
+   server-error-version-not-supported       x  x  x  x  x  x x  x  x
+   server-error-device-error                x  x  x  x  x
+   server-error-temporary-error             x  x  x  x  x
+   server-error-not-accepting-jobs          x  x  x        x
+   server-error-busy                        x  x  x  x  x  x x  x  x
+   server-error-job-canceled                x        x
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 154]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+14. APPENDIX C:  "media" keyword values
+
+   Standard keyword values are taken from several sources.
+
+   Standard values are defined (taken from DPA[ISO10175] and the Printer
+   MIB[RFC1759]):
+
+     'default': The default medium for the output device
+     'iso-a4-white': Specifies the ISO A4 white medium
+     'iso-a4-colored': Specifies the ISO A4 colored medium
+     'iso-a4-transparent' Specifies the ISO A4 transparent medium
+     'iso-a3-white': Specifies the ISO A3 white medium
+     'iso-a3-colored': Specifies the ISO A3 colored medium
+     'iso-a5-white': Specifies the ISO A5 white medium
+     'iso-a5-colored': Specifies the ISO A5 colored medium
+     'iso-b4-white': Specifies the ISO B4 white medium
+     'iso-b4-colored': Specifies the ISO B4 colored medium
+     'iso-b5-white': Specifies the ISO B5 white medium
+     'iso-b5-colored': Specifies the ISO B5 colored medium
+     'jis-b4-white': Specifies the JIS B4 white medium
+     'jis-b4-colored': Specifies the JIS B4 colored medium
+     'jis-b5-white': Specifies the JIS B5 white medium
+     'jis-b5-colored': Specifies the JIS B5 colored medium
+
+   The following standard values are defined for North American media:
+
+     'na-letter-white': Specifies the North American letter white medium
+     'na-letter-colored': Specifies the North American letter colored
+        medium
+     'na-letter-transparent': Specifies the North American letter
+        transparent medium
+     'na-legal-white': Specifies the North American legal white medium
+     'na-legal-colored': Specifies the North American legal colored
+        medium
+
+   The following standard values are defined for envelopes:
+
+     'iso-b4-envelope': Specifies the ISO B4 envelope medium
+     'iso-b5-envelope': Specifies the ISO B5 envelope medium
+     'iso-c3-envelope': Specifies the ISO C3 envelope medium
+     'iso-c4-envelope': Specifies the ISO C4 envelope medium
+     'iso-c5-envelope': Specifies the ISO C5 envelope medium
+     'iso-c6-envelope': Specifies the ISO C6 envelope medium
+     'iso-designated-long-envelope': Specifies the ISO Designated Long
+        envelope medium
+     'na-10x13-envelope': Specifies the North American 10x13 envelope
+        medium
+
+
+
+
+deBry, et al.                 Experimental                    [Page 155]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'na-9x12-envelope': Specifies the North American 9x12 envelope
+        medium
+     'monarch-envelope': Specifies the Monarch envelope
+     'na-number-10-envelope': Specifies the North American number 10
+        business envelope medium
+     'na-7x9-envelope': Specifies the North American 7x9 inch envelope
+     'na-9x11-envelope': Specifies the North American 9x11 inch envelope
+     'na-10x14-envelope': Specifies the North American 10x14 inch
+        envelope
+     'na-number-9-envelope': Specifies the North American number 9
+        business envelope
+     'na-6x9-envelope': Specifies the North American 6x9 inch envelope
+     'na-10x15-envelope': Specifies the North American 10x15 inch
+        envelope
+
+   The following standard values are defined for the less commonly used
+   media (white-only):
+
+     'executive-white': Specifies the white executive medium
+     'folio-white': Specifies the folio white medium
+     'invoice-white': Specifies the white invoice medium
+     'ledger-white': Specifies the white ledger medium
+     'quarto-white': Specified the white quarto medium
+     'iso-a0-white': Specifies the ISO A0 white medium
+     'iso-a1-white': Specifies the ISO A1 white medium
+     'iso-a2-white': Specifies the ISO A2 white medium
+     'iso-a6-white': Specifies the ISO A6 white medium
+     'iso-a7-white': Specifies the ISO A7 white medium
+     'iso-a8-white': Specifies the ISO A8 white medium
+     'iso-a9-white': Specifies the ISO A9 white medium
+     'iso-10-white': Specifies the ISO A10 white medium
+     'iso-b0-white': Specifies the ISO B0 white medium
+     'iso-b1-white': Specifies the ISO B1 white medium
+     'iso-b2-white': Specifies the ISO B2 white medium
+     'iso-b3-white': Specifies the ISO B3 white medium
+     'iso-b6-white': Specifies the ISO B6 white medium
+     'iso-b7-white': Specifies the ISO B7 white medium
+     'iso-b8-white': Specifies the ISO B8 white medium
+     'iso-b9-white': Specifies the ISO B9 white medium
+     'iso-b10-white': Specifies the ISO B10 white medium
+     'jis-b0-white': Specifies the JIS B0 white medium
+     'jis-b1-white': Specifies the JIS B1 white medium
+     'jis-b2-white': Specifies the JIS B2 white medium
+     'jis-b3-white': Specifies the JIS B3 white medium
+     'jis-b6-white': Specifies the JIS B6 white medium
+     'jis-b7-white': Specifies the JIS B7 white medium
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 156]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'jis-b8-white': Specifies the JIS B8 white medium
+     'jis-b9-white': Specifies the JIS B9 white medium
+     'jis-b10-white': Specifies the JIS B10 white medium
+
+
+   The following standard values are defined for engineering media:
+
+     'a': Specifies the engineering A size medium
+     'b': Specifies the engineering B size medium
+     'c': Specifies the engineering C size medium
+     'd': Specifies the engineering D size medium
+     'e': Specifies the engineering E size medium
+
+
+   The following standard values are defined for input-trays (from ISO
+   DPA and the Printer MIB):
+
+     'top': The top input tray in the printer.
+     'middle': The middle input tray in the printer.
+     'bottom': The bottom input tray in the printer.
+     'envelope': The envelope input tray in the printer.
+     'manual': The manual feed input tray in the printer.
+     'large-capacity': The large capacity input tray in the printer.
+     'main': The main input tray
+     'side': The side input tray
+
+
+   The following standard values are defined for media sizes (from ISO
+   DPA):
+
+     'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined
+        in ISO 216
+     'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
+        ISO 216
+     'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
+        ISO 216
+     'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
+        ISO 216
+     'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
+        ISO 216
+     'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
+        ISO 216
+     'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
+        ISO 216
+     'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
+        ISO 216
+     'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in
+        ISO 216
+
+
+
+deBry, et al.                 Experimental                    [Page 157]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in
+        ISO 216
+     'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
+        ISO 216
+     'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined
+        in ISO 216
+     'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined
+        in ISO 216
+     'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
+        ISO 216
+     'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
+        ISO 216
+     'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
+        ISO 216
+     'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
+        ISO 216
+     'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
+        ISO 216
+     'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
+        ISO 216
+     'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in
+        ISO 216
+     'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in
+        ISO 216
+     'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
+        ISO 216
+     'na-letter': Specifies the North American letter size: 8.5 inches by
+        11 inches
+     'na-legal': Specifies the North American legal size: 8.5 inches by
+        14 inches
+     'executive': Specifies the executive size (7.25 X 10.5 in)
+     'folio': Specifies the folio size (8.5 X 13 in)
+     'invoice': Specifies the invoice size (5.5 X 8.5 in)
+     'ledger': Specifies the ledger size (11 X 17 in)
+     'quarto': Specifies the quarto size (8.5 X 10.83 in)
+     'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
+        ISO 269
+     'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
+        ISO 269
+     'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
+        ISO 269
+     'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
+        ISO 269
+     'iso-designated-long': Specifies the ISO Designated Long size: 110
+        mm by 220 mm as defined in ISO 269
+     'na-10x13-envelope': Specifies the North American 10x13 size: 10
+        inches by 13 inches
+
+
+
+
+deBry, et al.                 Experimental                    [Page 158]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     'na-9x12-envelope': Specifies the North American 9x12 size: 9
+        inches by 12 inches
+     'na-number-10-envelope': Specifies the North American number 10
+        business envelope size: 4.125 inches by 9.5 inches
+     'na-7x9-envelope': Specifies the North American 7x9 inch envelope
+        size
+     'na-9x11-envelope': Specifies the North American 9x11 inch envelope
+        size
+     'na-10x14-envelope': Specifies the North American 10x14 inch
+        envelope size
+     'na-number-9-envelope': Specifies the North American number 9
+        business envelope size
+     'na-6x9-envelope': Specifies the North American 6x9 envelope size
+     'na-10x15-envelope': Specifies the North American 10x15 envelope
+        size
+     'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
+        in)
+     'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
+     'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
+     'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
+     'jis-b3': Specifies the JIS B3 size: 364mm x 515mm
+     'jis-b4': Specifies the JIS B4 size: 257mm x 364mm
+     'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
+     'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
+     'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
+     'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
+     'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
+     'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 159]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+15. APPENDIX D: Processing IPP Attributes
+
+   When submitting a print job to a Printer object, the IPP model allows
+   a client to supply operation and Job Template attributes along with
+   the document data.  These Job Template attributes in the create
+   request affect the rendering, production and finishing of the
+   documents in the job.  Similar types of instructions may also be
+   contained in the document to be printed, that is, embedded within the
+   print data itself.  In addition, the Printer has a set of attributes
+   that describe what rendering and finishing options which are
+   supported by that Printer.  This model, which allows for flexibility
+   and power, also introduces the potential that at job submission time,
+   these client-supplied attributes may conflict with either:
+
+     - what the implementation is capable of realizing (i.e., what the
+       Printer supports), as well as
+     - the instructions embedded within the print data itself.
+
+   The following sections describe how these two types of conflicts are
+   handled in the IPP model.
+
+15.1 Fidelity
+
+   If there is a conflict between what the client requests and what a
+   Printer object supports, the client may request one of two possible
+   conflict handling mechanisms:
+
+     1) either reject the job since the job can not be processed exactly
+        as specified, or
+     2) allow the Printer to make any changes necessary to proceed with
+        processing the Job the best it can.
+
+   In the first case the client is indicating to the Printer object:
+   "Print the job exactly as specified with no exceptions, and if that
+   can't be done, don't even bother printing the job at all." In the
+   second case, the client is indicating to the Printer object: "It is
+   more important to make sure the job is printed rather than be
+   processed exactly as specified; just make sure the job is printed
+   even if client supplied attributes need to be changed or ignored."
+
+   The IPP model accounts for this situation by introducing an "ipp-
+   attribute-fidelity" attribute.
+
+   In a create request, "ipp-attribute-fidelity" is a boolean operation
+   attribute that is OPTIONALLY supplied by the client.  The value '
+   true' indicates that total fidelity to client supplied Job Template
+   attributes and values is required.  The client is requesting that the
+   Job be printed exactly as specified, and if that is not possible then
+
+
+
+deBry, et al.                 Experimental                    [Page 160]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   the job MUST be rejected rather than processed incorrectly.  The
+   value 'false' indicates that a reasonable attempt to print the Job is
+   acceptable.  If a Printer does not support some of the client
+   supplied Job Template attributes or values, the Printer MUST ignore
+   them or substitute any supported value for unsupported values,
+   respectively.  The Printer may choose to substitute the default value
+   associated with that attribute, or use some other supported value
+   that is similar to the unsupported requested value.  For example, if
+   a client supplies a "media" value of 'na-letter', the Printer may
+   choose to substitute 'iso-a4' rather than a default value of '
+   envelope'. If the client does not supply the "ipp-attribute-fidelity"
+   attribute, the Printer assumes a value of 'false'.
+
+   Each Printer implementation MUST support both types of "fidelity"
+   printing (that is whether the client supplies a value of 'true' or '
+   false'):
+
+     - If the client supplies 'false' or does not supply the attribute,
+       the Printer object MUST always accept the request by ignoring
+       unsupported Job Template attributes and by substituting
+       unsupported values of supported Job Template attributes with
+       supported values.
+     - If the client supplies 'true', the Printer object MUST reject the
+       request if the client supplies unsupported Job Template
+       attributes.
+
+   Since a client can always query a Printer to find out exactly what is
+   and is not supported, "ipp-attribute-fidelity" set to 'false' is
+   useful when:
+
+     1) The End-User uses a command line interface to request attributes
+        that might not be supported.
+     2) In a GUI context, if the End User expects the job might be moved
+        to another printer and prefers a sub-optimal result to nothing
+        at all.
+     3) The End User just wants something reasonable in lieu of nothing
+        at all.
+
+15.2 Page Description Language (PDL) Override
+
+   If there is a conflict between the value of an IPP Job Template
+   attribute and a corresponding instruction in the document data, the
+   value of the IPP attribute SHOULD take precedence over the document
+   instruction.  Consider the case where a previously formatted file of
+   document data is sent to an IPP Printer.  In this case, if the client
+   supplies any attributes at job submission time, the client desires
+   that those attributes override the embedded instructions.  Consider
+   the case were a previously formatted document has embedded in it
+
+
+
+deBry, et al.                 Experimental                    [Page 161]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   commands to load 'iso-a4' media.  However, the document is passed to
+   an end user that only has access to a printer with 'na-letter' media
+   loaded.  That end user most likely wants to submit that document to
+   an IPP Printer with the "media" Job Template attribute set to 'na-
+   letter'.  The job submission attribute should take precedence over
+   the embedded PDL instruction.  However, until companies that supply
+   document data interpreters allow a way for external IPP attributes to
+   take precedence over embedded job production instructions, a Printer
+   might not be able to support the semantics that IPP attributes
+   override the embedded instructions.
+
+   The IPP model accounts for this situation by introducing a "pdl-
+   override-supported" attribute that describes the Printer objects
+   capabilities to override instructions embedded in the PDL data
+   stream.  The value of the "pdl-override-supported" attribute is
+   configured by means outside IPP/1.0.
+
+   This REQUIRED Printer attribute takes on the following values:
+
+     - 'attempted': This value indicates that the Printer object
+       attempts to make the IPP attribute values take precedence over
+       embedded instructions in the document data, however there is no
+       guarantee.
+     - 'not-attempted': This value indicates that the Printer object
+       makes no attempt to make the IPP attribute values take precedence
+       over embedded instructions in the document data.
+
+   At job processing time, an implementation that supports the value of
+   'attempted' might do one of several different actions:
+
+     1) Generate an output device specific command sequence to realize
+        the feature represented by the IPP attribute value.
+     2) Parse the document data itself and replace the conflicting
+        embedded instruction with a new embedded instruction that
+        matches the intent of the IPP attribute value.
+     3) Indicate to the Printer that external supplied attributes take
+        precedence over embedded instructions and then pass the external
+        IPP attribute values to the document data interpreter.
+     4) Anything else that allows for the semantics that IPP attributes
+        override embedded document data instructions.
+
+   Since 'attempted' does not offer any type of guarantee, even though a
+   given Printer object might not do a very "good" job of attempting to
+   ensure that IPP attributes take a higher precedence over instructions
+   embedded in the document data, it would still be a conforming
+   implementation.
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 162]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   At job processing time, an implementation that supports the value of
+   'not-attempted' might do one of the following actions:
+
+     1) Simply pre-pend the document data with the PDL instruction that
+        corresponds to the client-supplied PDL attribute, such that if
+        the document data also has the same PDL instruction, it will
+        override what the Printer object pre-pended.  In other words,
+        this implementation is using the same implementation semantics
+        for the client-supplied IPP attributes as for the Printer object
+        defaults.
+     2) Parse the document data and replace the conflicting embedded
+        instruction with a new embedded instruction that approximates,
+        but does not match, the semantic intent of the IPP attribute
+        value.
+
+   Note:  The "ipp-attribute-fidelity" attribute applies to the
+   Printer's ability to either accept or reject other unsupported Job
+   Template attributes.  In other words, if "ipp-attribute-fidelity" is
+   set to 'true', a Job is accepted if and only if the client supplied
+   Job Template attributes and values are supported by the Printer.
+   Whether these attributes actually affect the processing of the Job
+   when the document data contains embedded instructions depends on the
+   ability of the Printer to override the instructions embedded in the
+   document data with the semantics of the IPP attributes.  If the
+   document data attributes can be overridden ("pdl-override-supported"
+   set to 'attempted'), the Printer makes an attempt to use the IPP
+   attributes when processing the Job. If the document data attributes
+   can not be overridden ("pdl-override-supported" set to 'not-
+   attempted'), the Printer makes no attempt to override the embedded
+   document data instructions with the IPP attributes when processing
+   the Job, and hence, the IPP attributes may fail to affect the Job
+   processing and output when the corresponding instruction is embedded
+   in the document data.
+
+15.3 Using Job Template Attributes During Document Processing.
+
+   The Printer object uses some of the Job object's Job Template
+   attributes during the processing of the document data associated with
+   that job.  These include, but are not limited to, "orientation",
+   "number-up", "sides", "media", and "copies".  The processing of each
+   document in a Job Object MUST follow the steps below. These steps are
+   intended only to identify when and how attributes are to be used in
+   processing document data and any alternative steps that accomplishes
+   the same effect can be used to implement this specification.
+
+     1. Using the client supplied "document-format" attribute or some
+        form of document format detection algorithm (if the value of
+        "document- format" is not specific enough), determine whether or
+
+
+
+deBry, et al.                 Experimental                    [Page 163]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+        not the document data has already been formatted for printing.
+        If the document data has been formatted, then go to step 2.
+        Otherwise, the document data MUST be formatted. The formatting
+        detection algorithm is implementation defined and is not
+        specified by this specification. The formatting of the document
+        data uses the "orientation-requested" attribute to determine how
+        the formatted print data should be placed on a print-stream
+        page, see section 4.2.10 for the details.
+
+     2. The document data is in the form of a print-stream in a known
+        media type. The "page-ranges" attribute is used to select, as
+        specified in section 4.2.7, a sub-sequence of the pages in the
+        print-stream that are to be processed and images.
+
+     3. The input to this step is a sequence of print-stream pages. This
+        step is controlled by the "number-up" attribute. If the value of
+        "number-up" is N, then during the processing of the print-stream
+        pages, each N print-stream pages are positioned, as specified in
+        section 4.2.9, to create a single impression. If a given
+        document does not have N more print-stream pages, then the
+        completion of the impression is controlled by the "multiple-
+        document-handling" attribute as described in section 4.2.4; when
+        the value of this attribute is 'single-document' or 'single-
+        document-new-sheet', the print-stream pages of document data
+        from subsequent documents is used to complete the impression.
+
+        The size(scaling), position(translation) and rotation of the
+        print-stream pages on the impression is implementation defined.
+        Note that during this process the print-stream pages may be
+        rendered to a form suitable for placing on the impression; this
+        rendering is controlled by the values of the "printer-
+        resolution" and "print- quality" attributes as described in
+        sections 4.2.12 and 4.2.13. In the case N=1, the impression is
+        nearly the same as the print-stream page; the differences would
+        only be in the size, position and rotation of the print-stream
+        page and/or any decoration, such as a frame to the page, that is
+        added by the implementation.
+
+     4. The collection of impressions is placed, in sequence, onto sides
+        of the media sheets. This placement is controlled by the "sides"
+        attribute and the orientation of the print-stream page, as
+        described in section 4.2.8. The orientation of the print-stream
+        pages affects the orientation of the impression; for example, if
+        "number-up" equals 2, then, typically, two portrait print-stream
+        pages become one landscape impression. Note that the placement
+        of impressions onto media sheets is also controlled by the
+        "multiple-document-handling" attribute as described in section
+        4.2.4.
+
+
+
+deBry, et al.                 Experimental                    [Page 164]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+     5. The "copies" and "multiple-document-handling" attributes are
+        used to determine how many copies of each media instance are
+        created and in what order. See sections 4.2.5 and 4.2.4 for the
+        details.
+
+     6. When the correct number of copies are created, the media
+        instances are finished according to the values of the
+        "finishings" attribute as described in 4.2.6. Note that
+        sometimes finishing operations may require manual intervention
+        to perform the finishing operations on the copies, especially
+        uncollated copies. This specification allows any or all of the
+        processing steps to be performed automatically or manually at
+        the discretion of the Printer object.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 165]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+16. APPENDIX E: Generic Directory Schema
+
+   This section defines a generic schema for an entry in a directory
+   service.  A directory service is a means by which service users can
+   locate service providers.  In IPP environments, this means that IPP
+   Printers can be registered (either automatically or with the help of
+   an administrator) as entries of type printer in the directory using
+   an implementation specific mechanism such as entry attributes, entry
+   type fields, specific branches, etc.  IPP clients can search or
+   browse for entries of type printer.  Clients use the directory
+   service to find entries based on naming, organizational contexts, or
+   filtered searches on attribute values of entries.  For example, a
+   client can find all printers in the "Local Department" context.
+   Authentication and authorization are also often part of a directory
+   service so that an administrator can place limits on end users so
+   that they are only allowed to find entries to which they have certain
+   access rights.  IPP itself does not require any specific directory
+   service protocol or provider.
+
+   Note: Some directory implementations allow for the notion of
+   "aliasing".  That is, one directory entry object can appear as
+   multiple directory entry object with different names for each object.
+   In each case, each alias refers to the same directory entry object
+   which refers to a single IPP Printer object.
+
+   The generic schema is a subset of IPP Printer Job Template and
+   Printer Description attributes (sections 4.2 and 4.4).  These
+   attributes are identified as either RECOMMENDED or OPTIONAL for the
+   directory entry itself.  This conformance labeling is NOT the same
+   conformance labeling applied to the attributes of IPP Printers
+   objects.  The conformance labeling in this Appendix is intended to
+   apply to directory templates and to IPP Printer implementations that
+   subscribe by adding one or more entries to a directory.  RECOMMENDED
+   attributes SHOULD be associated with each directory entry.  OPTIONAL
+   attributes MAY be associated with the directory entry (if known or
+   supported).  In addition, all directory entry attributes SHOULD
+   reflect the current attribute values for the corresponding Printer
+   object.
+
+   The names of attributes in directory schema and entries SHOULD be the
+   same as the IPP Printer attribute names as shown.
+
+   In order to bridge between the directory service and the IPP Printer
+   object, one of the RECOMMENDED directory entry attributes is the
+   Printer object's "printer-uri-supported" attribute.  The IPP client
+   queries the "printer-uri-supported" attribute in the directory entry
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 166]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   and then addresses the IPP Printer object using one of its URIs.  The
+   "uri-security-supported" attribute identifies the protocol (if any)
+   used to secure a channel.
+
+   The following attributes define the generic schema for directory
+   entries of type PRINTER:
+
+     printer-uri-supported           RECOMMENDED    Section 4.4.1
+     uri-security-supported          RECOMMENDED    Section 4.4.2
+     printer-name                    RECOMMENDED    Section 4.4.3
+     printer-location                RECOMMENDED    Section 4.4.4
+     printer-info                    OPTIONAL       Section 4.4.5
+     printer-more-info               OPTIONAL       Section 4.4.6
+     printer-make-and-model          RECOMMENDED    Section 4.4.8
+     charset-supported               OPTIONAL       Section 4.4.15
+     generated-natural-language-
+        supported                    OPTIONAL       Section 4.4.17
+     document-format-supported       RECOMMENDED    Section 4.4.19
+     color-supported                 RECOMMENDED    Section 4.4.23
+     finishings-supported            OPTIONAL       Section 4.2.6
+     number-up-supported             OPTIONAL       Section 4.2.7
+     sides-supported                 RECOMMENDED    Section 4.2.8
+     media-supported                 RECOMMENDED    Section 4.2.11
+     printer-resolution-supported    OPTIONAL       Section 4.2.12
+     print-quality-supported         OPTIONAL       Section 4.2.13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 167]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+17. APPENDIX F:  Change History for the IPP Model and Semantics document
+
+   The following substantive changes and major clarifications have been
+   made to this document from the June 30, 1998 version based on the
+   interoperability testing that took place September 23-25 1998 and
+   subsequent mailing list and meeting discussions.  They are listed in
+   the order of occurrence in the document.  These changes are the ones
+   that might affect implementations.  Clarifications that are unlikely
+   to affect implementations are not listed.  The issue numbers refer to
+   the IPP Issues List which is available in the following directory:
+
+        ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/
+
+   Section   Description
+
+   global    Replaced TLS references with SSL3 references as agreed with
+             our Area Director on 11/12/1998.
+
+   global    Removed the indications that some of these IPP documents
+             are informational, since the intent is now to publish all
+             IPP/1.0 documents as informational as agreed with our Area
+             Director on 11/12/1998.
+
+   3.1.2,    Clarify that the IPP object SHOULD NOT validate the
+   16.3.3    range of the request-id being 1 to 2**31-1, but accepts
+   [now ipp- and returns any value.  Clients MUST still keep in the
+   iig]      range 1 to 2**31 though.  If the request is terminated
+             before the complete "request-id" is received, the IPP
+             object rejects the request and returns a response with a
+             "request-id" of 0  (Issue 1.36).
+
+   3.1.4.1,  Clarified that when a client submits a request in a
+   13.1.4.14 charset that is not supported, the IPP object SHOULD
+             return any 'text' or 'name' attributes in the 'utf-8'
+             charset, if it returns any, since clients and IPP
+             objects MUST support 'utf-8'.  (Issue 1.19)
+
+   3.1.4.1   Clarified Section 3.1.4.1 Request Operation Attributes
+             that a client MAY use the attribute level natural
+             language override (text/nameWithLanguage) redundantly in
+             a request.  (Issue 1.46)
+
+   3.1.4.2   Clarified Section 3.1.4.2 Response Operation Attributes
+             that an IPP object MAY use the attribute level natural
+             language override (text/nameWithLanguage) redundantly in
+             a response.  (Issue 1.46)
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 168]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   3.1.6     Clarified section 3.1.6:  If the Printer object supports
+             the "status-message" operation attribute, it NEED NOT
+             return a status message for the following error status
+             codes:  'client-error-bad-request', 'client-error-
+             charset-not-supported', 'server-error-internal-error',
+             'server-error-operation-not-supported', and 'server-
+             error-version-not-supported'.
+
+   3.2.1.1   Clarified that if a client is not supplying any Job
+             Template attributes in a request, the client SHOULD omit
+             Group 2 rather than sending an empty group.  However, a
+             Printer object MUST be able to accept an empty group.
+             This makes [RFC2566] agree with [RFC2565].  (Issue 1.16)
+
+   3.2.1.2,  Clarified that if an IPP object is not returning any
+   3.2.5.2,  Unsupported Attributes in a response, the IPP object
+   3.2.6.2,  SHOULD omit Group 2 rather than sending an empty group.
+   3.3.1.2,  However, a client MUST be able to accept an empty group.
+   3.3.3.2,  This makes [RFC2566] agree with [RFC2565].  (Issue 1.17)
+   3.3.4.2
+
+   3.2.1.2,  Clarified that an IPP object MUST treat an unsupported
+   13.1.2.2, attribute syntax supplied in a request in the same way
+   13.1.4.12 as an unsupported value.  The IPP object MUST return the
+             attribute, the attribute syntax, and the value in the
+             Unsupported Attributes group.  (Issue 1.26)
+
+   3.2.5.2,  Clarified for Get-Printer-Attributes, Get-Jobs, and Get-
+   3.2.6.2,  Job-Attributes that an IPP object MUST return
+   3.3.4.2,  'successful-ok-ignored-or-substituted-attributes' (0x1),
+
+   13.1.2.1, rather than 'successful-ok' (0x0), when a client
+   13.1.2.2, supplies unsupported attributes as values of the
+   13.1.4.12 'requested-attributes' operation attribute.  (Issue
+             1.24)
+             Also clarified that the response NEED NOT contain the
+             "requested-attributes" operation attribute with any
+             supplied values (attribute keywords) that were requested
+             by the client but are not supported by the IPP object.
+             (Issue 1.18)
+
+   3.2.6.2   Deleted the job-level natural language override (NLO)
+   4.1.1.2   from Section 3.2.6.2 Get-Jobs Response so that all
+   4.3.24    operation responses are the same with respect to NLO.
+             (Issue 1.47)
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 169]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   3.3.1     Clarified that an IPP Printer that supports the Create-
+             Job operation MUST handle the situation when a client
+             does not supply Send-Document or Send-URI operations
+             within a one- to four-minute time period.  Also
+             clarified that a client MUST send documents in a multi-
+             document job without undue or unbounded delay.  (Issue
+             1.28)
+
+   3.3.3     Clarified that the IPP object MUST reject a Cancel-Job
+             request if the job is in 'completed', 'canceled', or
+             'aborted' job states.  (Issue 1.12)
+
+   4.1.2.3   Added this new sub-section:  it specifies that
+             nameWithoutLanguage plus the implicit natural language
+             matches nameWithLanguage, if the values and natural
+             languages are the same.  Also added that keyword never
+             matches nameWithLanguage or nameWithoutLanguage.
+             Clarified that if both have countries, that the
+             countries SHOULD match as well.  If either do not, then
+             the country field SHOULD be ignored.  (Issues 1.33 and
+             1.34)
+
+   4.1.5     Clarified regarding the case-insensitivity of URLs to
+             refer only to the RFCs that define them.  (Issue 1.10)
+
+   4.1.11    Clarified that 'boolean' is not a full-sized integer.
+             (Issue 1.38)
+
+   4.1.15    Clarified that 'resolution' is not three full-sized
+             integers.  (Issue 1.20)
+
+   4.2.*     Clarified that standard values are keywords or enums,
+             not names.  (Issue 1.49).
+
+   4.2.4     Added the 'single-document-new-sheet' value to Section
+             4.2.4 multiple-document-handling.  (Issue 1.54)
+
+   4.4.18,   Clarified that the "document-format-default" and
+   4.4.19    "document-format-supported" Printer Description
+             attributes are REQUIRED to agree with the table.  (Issue
+             1.4)
+
+   4.4.21    Changed "queued-job-count" from OPTIONAL to RECOMMENDED.
+             (Issue 1.14)
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 170]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   4.4.28    Clarified that the implementation supplied value for the
+             "multiple-operation-time-out" attribute SHOULD be
+             between 30 and 240 seconds, though the implementation
+             MAY allow the administrator to set values, and MAY allow
+             values outside this range.  (Issue 1.28)
+
+   5.1,      Clarified Client Conformance that if a client supports
+   5.2.5     an attribute of 'text' attribute syntax, that it MUST
+             support both the textWithoutLanguage and the
+             textWithLanguage forms.  Same for 'name' attribute
+             syntax.  Same for an IPP object (Issue 1.48)
+
+   6.5,      Added new section to allow Attribute Groups to be
+   12.8      registered as extensions for being passed in operation
+             requests and responses.  (Issue 1.25)
+
+   7.        Updated the table of text and name attributes to agree
+             with Section 4.2.
+
+   8.5       Added a new section RECOMMENDING that the Get-Jobs
+             SHOULD return non-IPP jobs whether or not assigning them
+             a job-id and job-uri.  Also RECOMMENDED generating, if
+             possible, job-id and job-uri and supporting other IPP
+             operations on foreign jobs as an implementer option.
+             (Issue 1.32)
+
+   9.        Updated document references.
+
+   13.1.4.14 Clarified 'client-error-charset-not-supported' that
+             'utf-8' must be used for any 'text' or 'name' attributes
+             returned in the error response (Issue 1.19).
+
+   13.1.5.9  Added a new error code 'server-error-job-canceled'
+             (0x0508) to be returned if a job is canceled by another
+             client or aborted by the IPP object while the first
+             client is still sending the document data.  (Issue 1.29)
+
+   15.3,     Moved these sections recommending operation processing
+   15.4      steps to the new Implementer's Guide (informational).
+             There indicated that all of the error checks are not
+             required, so an IPP object MAY be forgiving and accept
+             non-conforming requests.  However, a conforming client
+             MUST supply requests that would pass all of the error
+             checks indicated.  (Issue 1.21)
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 171]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+   16        Changed directory schema attributes from REQUIRED to
+             RECOMMENDED.  Changed some of the OPTIONAL to
+             RECOMMENDED to agree with the SLP template.  Changed the
+             "charset-supported" and "natural-language-supported"
+             from REQUIRED to OPTIONAL.  Recommended that the names
+             be the same in a directory entry as the IPP attribute
+             names. (Issue 1.53)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 172]
+
+RFC 2566              IPP/1.0: Model and Semantics            April 1999
+
+
+18.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al.                 Experimental                    [Page 173]
+
diff --git a/standards/rfc2567.txt b/standards/rfc2567.txt
new file mode 100644
index 000000000..d5ef440be
--- /dev/null
+++ b/standards/rfc2567.txt
@@ -0,0 +1,2411 @@
+
+
+
+
+
+
+Network Working Group                                       F.D. Wright
+Request for Comments: 2567                        Lexmark International
+Category: Experimental                                       April 1999
+
+
+             Design Goals for an Internet Printing Protocol
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+IESG Note
+
+   This document defines an Experimental protocol for the Internet
+   community.  The IESG expects that a revised version of this protocol
+   will be published as Proposed Standard protocol.  The Proposed
+   Standard, when published, is expected to change from the protocol
+   defined in this memo.  In particular, it is expected that the
+   standards-track version of the protocol will incorporate strong
+   authentication and privacy features, and that an "ipp:" URL type will
+   be defined which supports those security measures.  Other changes to
+   the protocol are also possible.  Implementers are warned that future
+   versions of this protocol may not interoperate with the version of
+   IPP defined in this document, or if they do interoperate, that some
+   protocol features may not be available.
+
+   The IESG encourages experimentation with this protocol, especially in
+   combination with Transport Layer Security (TLS) [RFC2246], to help
+   determine how TLS may effectively be used as a security layer for
+   IPP.
+
+Abstract
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies.  This document takes a broad
+   look at distributed printing functionality, and it enumerates real-
+   life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+
+
+
+Wright                        Experimental                      [Page 1]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   administrators.  The design goals document calls out a subset of end
+   user requirements that are satisfied in IPP/1.0. Operator and
+   administrator requirements are out of scope for version 1.0.
+
+   The full set of IPP documents includes:
+
+   Design Goals for an Internet Printing Protocol (this document)
+   Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol [RFC2568]
+   Internet Printing Protocol/1.0: Model and Semantics [RFC2568]
+   Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
+   Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
+   Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specifications, and gives background and rationale for the
+   IETF working group's major decisions.
+
+   The "Internet Printing Protocol/1.0: Model and Semantics" document
+   describes a simplified model consisting of abstract objects, their
+   attributes, and their operations that is independent of encoding and
+   transport.  The model consists of a Printer and a Job object.  The
+   Job optionally supports multiple documents.  IPP 1.0 semantics allow
+   end-users and operators to query printer capabilities, submit print
+   jobs, inquire about the status of print jobs and printers, and cancel
+   print jobs.  This document also addresses security,
+   internationalization, and directory issues.
+
+   The "Internet Printing Protocol/1.0: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1.  It defines the encoding rules
+   for a new Internet media type called "application/ipp".
+
+   The "Internet Printing Protocol/1.0: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.0 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+
+
+
+
+Wright                        Experimental                      [Page 2]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+TABLE OF CONTENTS
+
+   1. INTRODUCTION.....................................................4
+   2. TERMINOLOGY......................................................4
+   3. DESIGN GOALS.....................................................6
+   3.1. End-user.......................................................6
+   3.1.1. Finding or locating a printer................................6
+   3.1.2. Create an instance of the printer............................7
+   3.1.3. Viewing the status and capabilities of a printer.............7
+   3.1.4. Submitting a print job.......................................8
+   3.1.5. Viewing the status of a submitted print job..................9
+   3.1.6. Canceling a Print Job........................................9
+   3.2. Operator (NOT REQUIRED FOR V1.0)...............................9
+   3.2.1. Alerting.....................................................9
+   3.2.2. Changing Print and Job Status...............................10
+   3.3. Administrator (NOT REQUIRED FOR v1.0).........................10
+   4. OBJECTIVES OF THE PROTOCOL......................................10
+   4.1. SECURITY CONSIDERATIONS.......................................11
+   4.2. Interaction with LPD (RFC1179)................................12
+   4.3. Extensibility.................................................12
+   4.4. Firewalls.....................................................13
+   4.5. Internationalization..........................................13
+   5. IPP SCENARIOS...................................................13
+   5.1. Printer Discovery.............................................14
+   5.2. Driver Installation...........................................15
+   5.3. Submitting a Print Job........................................15
+   5.4. Getting Status/Capabilities...................................16
+   5.5. Asynchronous Notification.....................................17
+   5.6. Job Canceling.................................................17
+   6. Security Considerations.........................................18
+   7. REFERENCES......................................................18
+   8. ACKNOWLEDGMENTS.................................................19
+   9. AUTHOR'S ADDRESS................................................19
+   10. APPENDIX - DETAILED SCENARIOS..................................20
+   10.1. Printer discovery within an enterprise.......................20
+   10.2. Printer discovery across enterprises.........................21
+   10.3. Printer discovery on the Internet -logical operations........21
+   10.4. Printer discovery on the Internet - authentication...........22
+   10.5. Driver Download..............................................23
+   10.6. Submitting a print job as a file.............................24
+   10.7. Submitting a print job with two documents....................24
+   10.8. Submitting a print job as a file, printing fails.............25
+   10.9. Submitting a print job with authentication, PRIVACY and
+         payment......................................................26
+   10.10. Submitting a print job with decryption error................27
+   10.11. Submitting a print job with authentication..................28
+   10.12. Submitting a print job generated dynamically................29
+   10.13. Submitting a print job with a Printer jam - CANCELED........29
+
+
+
+Wright                        Experimental                      [Page 3]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   10.14. Submitting a print job with a Printer jam - recovered.......30
+   10.15. Submitting a print job with server pull.....................31
+   10.16. Submitting a print job with referenced resources............32
+   10.17. Getting Capabilities........................................33
+   10.17.1. Submission Attributes.....................................33
+   10.17.2. Printer Capabilities......................................33
+   10.18. Getting Status..............................................34
+   10.18.1. Printer State/Status......................................34
+   10.18.2. Job Status................................................34
+   10.18.3. Status of All My Jobs.....................................34
+   10.19. Asynchronous Notification...................................35
+   10.19.1. Job Completion............................................35
+   10.19.2. Job Complete with Data....................................35
+   10.19.3. Print Job Fails...........................................35
+   10.20. Cancel a job................................................36
+   10.21. End to end Scenario - within an enterprise..................36
+   10.22. End to end Scenario - across enterprises....................37
+   10.23. End to End Scenario - on the internet.......................40
+   11. Full Copyright Statement.......................................43
+
+1. INTRODUCTION
+
+   The IPP protocol is heavily influenced by the printing model
+   introduced in the Document Printing Application (DPA) [ISO10175]
+   standard.  Although DPA specifies both end user and administrative
+   features, IPP version 1.0 (IPP/1.0) focuses only on end user
+   functionality.
+
+2. TERMINOLOGY
+
+   Internet Printing for the purposes of this document is the
+   application of Internet tools, programs, servers and networks to
+   allow end-users to print to a remote printer using, after initial
+   setup or configuration, the same methods, operations and paradigms as
+   would be used for a locally attached or a local area network attached
+   printer.  This could include the use of HTTP servers and browsers and
+   other applications for providing static, dynamic and interactive
+   printer locating services, user installation, selection,
+   configuration, print job submission, printer capability inquiry and
+   status inquiry of remote printers and jobs.
+
+   For the purposes of this document, a WEB Browser is software
+   available from a number of sources including but not limited to the
+   following:  Microsoft Internet Explorer, NCSA Mosaic, Netscape
+   Navigator, Sun Hot Java!.  The major task of these products is to use
+   the Hypertext Transport Protocol (HTTP) to retrieve, interpret and
+   display Hypertext Markup Language (HTML).  These products are often a
+   part of a complete Internet Printing system because they are often
+
+
+
+Wright                        Experimental                      [Page 4]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   used as a means of obtaining the status of or more information about
+   the printing system; however, they may not be present in all
+   implementations.
+
+   Throughout this document, 'printer' shall be interpreted to include
+   any device which is capable of marking on a piece of media using any
+   available technology.  These design goals do not include support for
+   multi-tiered printing solutions involving servers (single or
+   multiple) logically in front of the actual printing device yet all
+   such configurations shall be supported but shall appear to the end-
+   user as only a single device.
+
+   Throughout this document 'driver' refers to the code installed in
+   some client operating system to generate the print data stream for
+   the intended printer. Some computing environments may not include a
+   separate printer driver.  Rather, the generation of the proper print
+   data stream is accomplished in an application on that computer. How
+   such a computer environment or application is updated to support a
+   new printer now made available using IPP is outside the scope of IPP.
+   The actual details for installing a printer driver are operating
+   system dependent and are also outside the scope of IPP. See also
+   section 4.1 (SECURITY CONSIDERATIONS) for security implications of
+   driver download and installation.
+
+   The IPP protocol will support the following physical configurations:
+
+   - An IPP client talking to an IPP Printer object imbedded in a
+     single, physical output device.
+   - An IPP Client talking to a server containing one or more IPP
+     Printer objects. Each Printer object is associated with exactly one
+     physical output device supported by the server. The protocol
+     between the server and the output devices is undefined.
+   - An IPP Client talking to an IPP Printer object in a server. The
+     Printer object is associated with one or more physical output
+     devices, but the client only sees the Printer object, which is an
+     abstraction and represents all of the associated physical output
+     devices. The protocol between the server and the physical output
+     devices is undefined.
+
+   Throughout this document, certain design goals will be identified as
+   not being a part of version 1.0 (or V1.0) of the protocol or as being
+   satisfied by means outside of IPP.  IPP is assumed to be one part, an
+   enabler, of a complete Internet Printing solution.  For example
+   printer instance creation is not performed by but is enabled by the
+   protocol.  Globally, none of the operator or administrators wants and
+   needs are included in the design goals for version 1.0.  Some of the
+   end-user wants and needs may also be excluded from version 1.0 and
+   will be so noted in the description of them.  Subsequent versions of
+
+
+
+Wright                        Experimental                      [Page 5]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   the protocol (e.g. V2.0) may include support for these initially
+   excluded wants and needs.
+
+3. DESIGN GOALS
+
+   The next three sections identify the design goals for an Internet
+   printing protocol from three roles assumed by humans: end-user,
+   operator, and administrator.  The goals defined here are only those
+   that need to be addressed by an Internet printing protocol.  Other
+   wants and needs, such as that the operator needs physical access to
+   the printer (e.g. to be able to load paper or clear jams) are not
+   covered by this document.  Section 5 contains scenarios which provide
+   more detailed examples of the entire process including discovery,
+   status, printing and end-of-job reporting.
+
+3.1. END-USER
+
+   An end-user of a printer accepting jobs through the Internet is one
+   of the roles in which humans act.  The end-user is the person that
+   will submit a job to be printed on the printer.
+
+   The wants and needs of the end-user are broken down into six
+   categories: finding/locating a printer, creating a local instance of
+   a printer, viewing printer status, viewing printer capabilities,
+   submitting a print job, viewing print job status, altering the
+   attributes of a print job.
+
+3.1.1. Finding or locating a printer.
+
+   End-users want to be able to find and locate printers to which they
+   are authorized to print.  They want to be able to perform this
+   function using a standard WEB browser or other application.  Multiple
+   criteria can be applied to find the printers needed.  These criteria
+   include but are not limited to:
+
+   - by name (Printer 1, Joes-color-printer, etc.)
+   - by geographic location (bldg 1, Kentucky, etc.)
+   - by capability or attribute (color, duplex, legal paper, etc.)
+
+   Additionally, while it is outside of scope of IPP, end-users want to
+   be able to limit the scope of their searching to:
+
+   - inside a functional sub-domain
+   - include only a particular domain (lexmark.com)
+   - exclude specified domains
+
+
+
+
+
+
+Wright                        Experimental                      [Page 6]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   While an Internet printing protocol may not of itself include this
+   function, IPP must define and enable a directory schema which will
+   provide the necessary information for a directory service
+   implementation to consistently represent printers by their IPP
+   attributes.
+
+3.1.2. Create an instance of the printer.
+
+   After finding the desired printer, an end-user needs to be able to
+   create a local instance of that printer within the end-user operating
+   system or desktop.  This local instance will vary depending upon the
+   printing paradigm of the operating system.  For example, some UNIX
+   users will only want a queue or a reference to a remote printer
+   created on their machine while other UNIX users and Windows NT users
+   will want the queue and also the necessary icons and registry entries
+   to be created and initialized.  Where required, drivers may need to
+   be downloaded from some repository and installed on the computer.
+   All necessary decompressing, unpacking, and other installation
+   actions should occur without end-user interaction or intervention
+   excepting initial approval by the end-user.  Once the local instance
+   of the printer has been installed, it shall appear to the end-user of
+   the operating system and to the applications running there as any
+   other printer (local, local area network connected, or network
+   operating system connected) on the end-user desktop or environment.
+   IPP's role in this goal is simply to enable the creation of the
+   printer instance providing information such as where to locate a
+   printer driver for this printer, as an attribute of an IPP Printer.
+
+3.1.3. Viewing the status and capabilities of a printer.
+
+   Before using a selected printer or, in fact at any time, the end-user
+   needs the ability to verify the characteristics and status of both
+   printers and jobs queued for that printer.  When checking the
+   characteristics of a printer, the end-user typically wants to be able
+   to determine the capability of the device, e.g.:
+
+   - supported media, commonly paper, by size and type
+   - paper handling capability, e.g. duplex, collating, finishing
+   - color capability
+
+   When checking the status of the printer and its print jobs, the end-
+   user typically wants to be able to determine:
+
+   - is the printer on-line?
+   - what are the defaults to be used for printing?
+   - how many jobs are queued for the printer?
+   - how are job priorities assigned? (outside the scope of IPP)
+
+
+
+
+Wright                        Experimental                      [Page 7]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+3.1.4. Submitting a print job.
+
+   Once the desired printer has been located and installed, the end-user
+   wants to print to that printer from normal applications using
+   standard methods.  These normal applications include such programs as
+   word processors, spreadsheets, data-base applications, WEB browsers,
+   production printing applications, etc.  Additionally, the end-user
+   may want to print a file already existing on the end-user's computer
+   -- "simple push".  In addition to printing from an application and
+   simple push, the end-user needs to have the ability to submit a print
+   job by reference.  Printing by reference is defined to mean as
+   submitting a job by providing a reference to an existing document.
+   The reference, a URI, will be resolved before the actual print
+   process occurs.  Submitting a job by reference relieves the user from
+   downloading the document from the remote server and then sending it
+   via IPP to the printer.  This saves both time and network bandwidth.
+
+   Some means shall be provided to determine if the format of a job
+   matches the capability of the printer.  This can be done by one of
+   the following (all of which are outside of scope of the IPP
+   protocol):
+
+      - the end-user selects the correct printer driver
+      - the printer automatically selects the proper interpreter
+      - the end-user uses some other manual procedure.
+
+   A standard action shall be defined should the job's requirements not
+   match the capabilities of the printer.
+
+   Because the end-user does not want to know the details of the
+   underlying printing process, the protocol must support job-to-printer
+   capability matching (all implementations are not necessarily required
+   to implement this function.)  This matching capability requires
+   knowing both the printer's capabilities and attributes and those
+   capabilities and attributes required by the job.  Actions taken when
+   a print job requires capabilities or attributes that are not
+   available on the printer vary and can include but are not limited to:
+
+   - rejecting the print job
+   - redirecting the print job to another printer (Not in V1.0)
+   - printing the job, accepting differences in the appearance
+
+   Print jobs will also be submitted by background or batch applications
+   without human intervention.
+
+   End-users need the ability to set certain print job parameters at the
+   time the job is submitted.  These parameters include but are not
+   limited to:
+
+
+
+Wright                        Experimental                      [Page 8]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   - number of copies
+   - single or two sided printing
+   - finishing
+   - job priority
+
+3.1.5. Viewing the status of a submitted print job.
+
+   After a job has been submitted to a printer, the end-user needs a way
+   to view the status of that job (i.e. job waiting, job printing, job
+   done) and to determine where the job is in the print queue.
+
+   In addition to the need to inquire about the status of a print job,
+   automatic notification of the completion of that job is also
+   required.
+
+   Notification means are not defined by the protocol but the protocol
+   must provide a means of enabling and disabling the notification.
+
+3.1.6. Canceling a Print Job
+
+   While a job is waiting to be printed or has been started but not yet
+   completed, the original creator/submitter of the print job (i.e. the
+   end-user) shall be able to cancel the job entirely (job is waiting)
+   or the remaining portion of it (job is printing.)  Altering the print
+   job itself is not a V1.0 design goal.
+
+3.2. OPERATOR (NOT REQUIRED FOR V1.0)
+
+   An operator of a printer accepting jobs through the Internet is one
+   of the roles in which humans act.  The operator has the
+   responsibility of monitoring the status of the printer as well as
+   managing and controlling the jobs at the device.  These
+   responsibilities include but are not limited to the replenishing of
+   supplies (ink, toner, paper, etc.), the clearing of minor errors
+   (paper jams, etc.) and the re-prioritization of end-user jobs.
+   Operator wants and needs will not be addressed by V1.0 of the
+   protocol.
+
+   The wants and needs of the operator include all those of the end-user
+   but may include additional privileges.  For example, an operator may
+   be able to view all print jobs on a printer while the end-user might
+   only be able to see his own jobs.
+
+3.2.1. Alerting.
+
+   One of the required operator functions is having the ability to
+   discover or to be alerted to changes in the status of a printer
+   particularly those changes that cause a printer to stop printing and
+
+
+
+Wright                        Experimental                      [Page 9]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   to be able to correct those problems.  As such, an Internet printing
+   protocol shall be able to alert a designated operator or operators to
+   these conditions such as 'out of paper', 'out of ink', etc.
+   Additionally. the operator shall be able to, asynchronous to other
+   printer activity, inquire as to a printer's or a job's status.
+
+3.2.2. Changing Print and Job Status.
+
+   Another of the required operator functions is the ability to affect
+   changes to printer and job status remotely.  For example, the
+   operator will need to be able to re-prioritize or cancel any print
+   jobs on a printer to which the operator has authority.
+
+3.3. ADMINISTRATOR (NOT REQUIRED FOR V1.0)
+
+   An administrator of a printer accepting jobs through the Internet is
+   one of the roles in which humans act.  The administrator has the
+   responsibility of creating the printer instances and controlling the
+   authorization of other end-users and operators.  Administrator wants
+   and needs will not be addressed by V1.0 of the protocol.
+
+   The wants and needs of the administrator include all those of the
+   end-user and, in some environments, some or all of those of the
+   operator.  Minimally, the administrator must also have the tools,
+   programs, utilities and supporting protocols available to be able to:
+
+   - create an instance of a printer
+   - create, edit and maintain the list of authorized end-users
+   - create, edit and maintain the list of authorized operators
+   - create, edit and maintain the list of authorized
+     administrators
+   - create, customize, change or otherwise alter the manner in
+     which the status capabilities and other information about printers
+     and jobs are presented
+   - create, customize, or change other printer or job features
+   - administrate billing or other charge-back mechanisms
+   - create sets of defaults
+   - create sets of capabilities
+
+   The administrator must have the capability to perform all the above
+   tasks locally or remotely to the printer.
+
+4. OBJECTIVES OF THE PROTOCOL
+
+   The protocol to be defined by an Internet printing working group will
+   address the wants and needs of the end-user (V1.0).  It will not, at
+   least initially, address the operator or administrator wants and
+   needs (V2.0).
+
+
+
+Wright                        Experimental                     [Page 10]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   The protocol defined shall be independent of the operating system of
+   both the client and the server.  Generally, any platform capable of
+   supporting a WEB Browser should be capable of being a client.
+   Generally, any platform providing a WEB/HTTP server and printing
+   services should be capable of being a server.  Usage of the WEB
+   Browser and Server is not required for IPP; the operating system,
+   operating system extensions or other applications may provide IPP
+   functionality directly.
+
+   In many environments such as Windows 95, Windows NT and OS/2, the
+   print data is created and transmitted to the printer on the fly
+   rather than being created, spooled and then transmitted to the
+   printer (a typical UNIX method.)  The Internet Printing Protocol must
+   properly handle either methodology and make this transparent to the
+   end-user.
+
+4.1. SECURITY CONSIDERATIONS
+
+   It is required that the Internet Printing Protocol be able to operate
+   within a secure environment. Wherever reasonable, IPP ought to make
+   use of existing security protocols and services. IPP will not invent
+   new security features when the design goals described in this
+   document can be met by existing protocols and services. Examples of
+   such services include Secure Socket Layer Version 3 (SSL3) [SSL] and
+   HTTP Digest Access Authentication [RFC2069].  Note: SSL3 is not on
+   the IETF standards track.
+
+   Since we cannot anticipate the security levels or the specific
+   threats that any given IPP print administrator may be concerned with,
+   IPP must be capable of operating with different security mechanisms
+   and policies as required by the individual installation. The initial
+   security needs of IPP are derived from two primary considerations.
+   First, the printing environments described in this document take into
+   account that the client, the Printer, and the document to be printed
+   may each exist in different security domains. When objects are in
+   different security domains the design goals for authentication and
+   message protection may be much stronger than when they are all in the
+   same domain.
+
+   Secondly, the sensitivity and value of the content being printed will
+   vary from one instance of a print job to another. For example, a
+   publicly available document does not need the same level of
+   protection as a payroll document does.  Message protection design
+   goals include data origin authentication, privacy, integrity, and
+   non-repudiation.
+
+
+
+
+
+
+Wright                        Experimental                     [Page 11]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   In many environments (e.g. Windows, OS/2) a printer driver may be
+   needed to create the proper datastream for printer.  This document
+   discusses downloading such a new driver from a variety of sources.
+   Downloading and installing any software, including drivers) on a
+   computer exposes that computer to a number of security risks
+   including but not limited to:
+
+      - defective software
+      - malicious software (e.g. Trojan horses)
+      - inappropriate software (i.e. software doing something
+        deemed unreasonable by the user.)
+
+   As such, proper security considerations and actions need to be taken
+   by the user and/or a system administrator to prevent the compromising
+   of the computer.  Administrators should configure downloading
+   mechanism for printer drivers in such a way as to be able to verify
+   the source of driver software and encrypt or otherwise protect that
+   software during download.
+
+   Examples including security considerations can be found in sections 5
+   (IPP SCENARIOS) and 10 (APPENDIX - DETAILED SCENARIOS) later in this
+   document.
+
+4.2. INTERACTION WITH LPD (RFC1179)
+
+   Many versions of UNIX and in fact other operating systems provide a
+   means of printing as described in [RFC1179] (Line Printer Daemon
+   Protocol.)  This document describes the file formats for the control
+   and data files as well as the messages used by the protocol.  Because
+   of the simplistic approach taken by this protocol, many manufacturers
+   have include proprietary enhancements and extensions to 'lpd.'
+   Because of this divergence and due to other design goals described in
+   this document, there is no requirement for backward compatibility or
+   interoperability with 'lpd'.  However, a mapping of LPD functionality
+   and IPP functionality shall be provided so as to enable a gateway
+   between LPD and IPP.
+
+4.3. EXTENSIBILITY
+
+   The Internet Printing Protocol shall be extensible by several means
+   that facilitate interoperability and prevent implementation
+   collisions:
+
+      - by providing a process whereby implementers can submit proposals
+      for registration of new attributes and new enumerated values for
+      existing attributes.
+
+
+
+
+
+Wright                        Experimental                     [Page 12]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+         * that require review and approval.  The Internet Assigned
+         Number Authority (IANA) will be the repository for such
+         accepted registration proposals after review.
+
+         * that do not require review and approval.  IANA will be the
+         repository for such registrations.
+
+      - by providing syntax in the protocol so that implementers may add
+      private (i.e. unregistered) attributes and  enumerated attribute
+      values.
+
+      - by providing versioning and negotiation so as to enable future
+      implementations of IPP to interoperate with implementations of
+      version 1.0 of IPP.
+
+4.4. FIREWALLS
+
+   As stated in section 3 Design Goals, Internet printing shall, by
+   definition, support printing from one enterprise to another.  As
+   such, the Internet printing protocol must be capable of passing
+   through firewalls and/or proxy servers (where enabled by the firewall
+   administrator) preferably without modification to the existing
+   firewall technology.
+
+4.5. INTERNATIONALIZATION
+
+   Users of Internet printing will come from all over the world.  As
+   such, where appropriate, internationalization and localization will
+   be enabled for the protocol.
+
+5. IPP SCENARIOS
+
+   Each of the scenarios in this section describes a specific IPP
+   operation, such as submitting a print job. Section 10 contains
+   several detailed flows for each scenario to provide additional
+   detail.  The examples should not be considered exhaustive, but
+   illustrative of the functions and features required in the protocol.
+   Flows are intended to be protocol neutral. It is not assumed that all
+   of the functions and features described in these scenarios will
+   necessarily be supported directly by IPP or in version 1.0 of IPP.
+
+   See the IPP Model and Semantics document for details on
+   configurations of clients, servers and firewalls.
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 13]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+5.1. PRINTER DISCOVERY
+
+   Client                                               Directory Service
+   Service
+
+    +----------------------------------------------------------- >
+       give me information on printers with these characteristics
+
+
+    < -----------------------------------------------------------+
+        Information on Printers matching these characteristics
+
+   The objective of printer discovery is to locate printers that meet
+   the client's wants and needs. The Directory Service should provide
+   enough information for the client to make an initial choice. The
+   client may have to connect to each individual Printer offered to get
+   more detail.  Not all information available from the Directory
+   Service is obtained using IPP; some information may be
+   administratively provided.
+
+   The actual protocol used between client and Directory or Name Service
+   is considered outside the scope of IPP. Printer Discover is included
+   in the scenarios to provide design goals for the directory schema for
+   IPP Printers and to further define Printer attributes.
+
+   Characteristics that might be considered when locating a Printer
+   include:
+
+   - capabilities of the Printer, e.g. PDLs supported
+   - physical location, e.g. in building 010
+   - driver required and location
+   - cost per page to print (outside the scope of IPP)
+   - whether or not printer is access controlled
+   - whether or not usage requires client authentication
+   - whether or not Printer can be authenticated
+   - whether or not payment is required for printing (outside the scope
+     of IPP)
+   - maximum job size (spool size) (outside the scope of IPP)
+   - whether or not Printer support compression (outside the scope of
+     IPP)
+   - whether or not Printer supports encryption
+   - administrative limits on this Printer
+      - maximum number of copies per job
+      - maximum number of pages per job
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 14]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   Responses could additionally include:
+
+   - how to get more information
+      - web page
+      - telephone number
+      - help desk
+
+5.2. DRIVER INSTALLATION
+
+   Client                                               Printer
+
+    +----------------------------------------------------------- >
+       Where can I find a driver & software to install it?
+
+
+    < -----------------------------------------------------------+
+        URIs for drivers and install software
+
+   Driver here refers to the code installed in some client operating
+   system to generate the print data stream for the intended printer.
+   The actual details for installing a printer driver are operating
+   system dependent and are also outside the scope of IPP.  However, an
+   IPP printer or a directory service advertising an IPP Printer should
+   be capable of telling a client what drivers are available and/or
+   required, where they can be found, and provide pointers to
+   installation instructions, installation code or initialization
+   strings required to install the driver.  See section 4.1 (SECURITY
+   CONSIDERATIONS) for security implications of driver download and
+   installation.
+
+5.3. SUBMITTING A PRINT JOB
+
+   Client                                               IPP Printer
+
+    +----------------------------------------------------------- >
+       Here is a Print Job
+        - Job attributes
+        - Print data
+
+
+    < -----------------------------------------------------------+
+        Response
+
+   The protocol must support these sources of client data:
+
+   - Print data is a file submitted with the job
+   - Print data is generated on the fly by an application
+   - Print data is a file referenced by a URI
+
+
+
+Wright                        Experimental                     [Page 15]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   The protocol must handle overrun conditions in the printer and must
+   support overlapped printing and downloading of the file in devices
+   that are unable to spool files before printing them.
+
+   Every print request will have a response. Responses will indicate
+   success or failure of the request and provide information on failures
+   when they occur. Responses would include things like:
+
+   - Got the print job and queued it
+   - Got the print job and am printing it
+   - Got the print job, started to print it, but printing failed
+      - why it failed (e.g. unrecoverable PostScript error)
+      - state of the printer
+      - how much printed
+   - Got the print job but couldn't print it
+      - why it can't be printed
+      - state of the printer
+   - Got the print job but don't know what to do with it
+   - Didn't get a complete print job (e.g. communication failure)
+
+5.4. GETTING STATUS/CAPABILITIES
+
+   Client                                               IPP Printer
+
+    +----------------------------------------------------------- >
+       Get status and/or capabilities of Printer
+
+
+    < -----------------------------------------------------------+
+        Status/Capabilities
+
+   Clients will need to get information about
+
+   - Static capabilities of the device
+   - Dynamic state of the Printer (e.g. out of paper)
+   - State of a specific job owned by this client
+   - State of all jobs owned by this client
+      - queued
+      - printing
+      - completed
+
+
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 16]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   - Job submission attributes supported/required
+      - scheduling attributes (e.g. priority)
+      - production attributes (e.g. number of copies)
+
+5.5. ASYNCHRONOUS NOTIFICATION
+
+   Client                                               IPP Printer
+
+    +----------------------------------------------------------- >
+       Use the following method to notify me of Printer events
+
+                                 .
+                                 .
+                                 .
+    < -----------------------------------------------------------+
+        Asynchronous notification of Printer event
+
+   Clients must be able to request asynchronous notification for Printer
+   events such as
+
+   - job completion
+   - a fatal error that requires the job to be resubmitted
+   - a condition that severely impacts a queued job for this client
+      e.g. printer is out of paper
+
+   Note: end-user notification is a V1.0 design goal while operator
+   notification is for V2.0.
+
+5.6. JOB CANCELING
+
+   Client                                               IPP Printer
+
+    +----------------------------------------------------------- >
+       Cancel the named job as indicated
+
+
+    < -----------------------------------------------------------+
+        Response (did it or not)
+
+   Similarly clients must be able to make changes to jobs which have
+   been submitted and are queued for printing.  Changing of job
+   attributes should also be supported.  Job modifications, holding and
+   releasing of jobs are not included in the design goals for IPP v1.0.
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 17]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+6. SECURITY CONSIDERATIONS
+
+   The security considerations for IPP are described in Section 4.1
+   above.
+
+7. REFERENCES
+
+   [ipp-iig]  Hastings, T. and C. Manros, "Internet Printing
+              Protocol/1.0: Implementer's Guide", Work in Progress.
+
+   [RFC2569]  Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+              "Mapping between LPD and IPP Protocols", RFC 2569, April
+              1999.
+
+   [RFC2566]  deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
+              Powell, "Internet Printing Protocol/1.0: Model and
+              Semantics", RFC 2568, April 1999.
+
+   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
+              Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+              April 1999.
+
+   [RFC2568]  Zilles, S., "Rationale for the Structure and Model and
+              Protocol for the Internet Printing Protocol", RFC 2568,
+              April 1999.
+
+   [ISO10175] ISO/IEC 10175, Document Printing Application, June 1996.
+
+   [RFC1179]  McLaughlin, L., "Line Printer Daemon Protocol" RFC 1179,
+              August 1990.
+
+   [SSL]      Netscape, The SSL Protocol, Version 3, (Text version
+              3.02), November 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 18]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+8. ACKNOWLEDGMENTS
+
+   This document draws heavily from preliminary work done by others
+   especially in the Printer Working Group (PWG).  The author gratefully
+   acknowledges the specific contributions of:
+
+   Scott Isaacson                   Roger deBry
+   Novell                           Utah Valley State College
+   sisaacson@novell.com             debryro@uvsc.edu
+
+   Carl-Uno Manros                  Robert Herriot
+   Xerox                            Sun
+   manros@cp10.es.xerox.com         Robert.Herrior@pahv.xerox.xom
+
+   Tom Hastings                     Peter Zehler
+   Xerox                            Xerox
+   hastings@cp10.es.xerox.com       Peter.Zehler@usa.xerox.com
+
+9. AUTHOR'S ADDRESS
+
+   F.D. (Don) Wright
+   Lexmark International
+   C14/035-3
+   740 New Circle Rd
+   Lexington, KY  40550
+
+   Phone: 606-232-4808
+   Fax: 606-232-6740
+   EMail: don@lexmark.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 19]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+10. APPENDIX - DETAILED SCENARIOS
+
+   The following are more detailed scenarios illustrating how the
+   Internet Printing Protocol is expected to be used as a part of a
+   complete Internet Printing system.  Some parts of the scenarios
+   include concepts, functions and information that may be outside of
+   the scope of version 1.0 of IPP (e.g. cost per page, payments means
+   available, etc.)  The information contained herein is meant to be
+   generic.  There may not be an exact wording or terminology match
+   between these scenarios and the implementation documents.
+
+10.1. PRINTER DISCOVERY WITHIN AN ENTERPRISE
+
+   A user wants to find a color Postscript printer in his/her enterprise
+   which will print transparencies. The client, directory service, and
+   printer are all behind the same corporate firewall. Because color
+   foils are expensive, printers of this type are access controlled and
+   require an account to be established so that printing can be billed
+   back to the using department. Note the request to find a printer
+   usable by Dept.  J15. Drivers for all supported printers are
+   available from the server they are associated with. A help desk is
+   provided for end user support.  The printer is unattended.
+
+   Client                                  Directory Service
+
+      +---------------------------------------------------------- >
+        Find a printer with these characteristics
+        - prints color, prints transparencies
+        - prints Postscript
+        - is in building 003
+        - accessible by the client
+
+      < ----------------------------------------------------------+
+        Printer "Color-A"
+        - prints color, prints transparencies
+        - prints Postscript
+        - in room H-6, building 003
+        - driver ABC-Postscript-V1.3 required, here is URI
+        - cost is $.45 per page for color transparencies
+        - limit is 10 pages per job
+        - authentication required to use printer
+        - printer is unattended
+        - help desk at x5001
+
+         Printer "Color-B"
+        - prints color, prints transparencies
+        - prints Postscript
+        - in room J-10, building 003
+
+
+
+Wright                        Experimental                     [Page 20]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        - driver XYZ-Postscript-V2.4 required, here is URI
+        - cost is $1.25 page for color transparencies
+        - limit is 5 pages per job
+        - authentication is required to use printer
+        - printer is unattended
+        - help desk at x5001
+
+10.2. PRINTER DISCOVERY ACROSS ENTERPRISES
+
+   A user in Company A wants to find a public printer in a business
+   partner's enterprise (Company B) on which to print a purchase order.
+   The client is behind one corporate firewall and the directory service
+   and the printer are behind a different corporate firewall. Drivers
+   for all supported printers are available from the server they are
+   associated with. A web page is provided for end user support for
+   public printers.
+
+   Client                        Company B Directory Service
+
+      +---------------------------------------------------------- >
+        Find a printer with these characteristics
+        - prints black and white
+        - is in El Segundo, building A
+        - is a public printer
+
+      < ----------------------------------------------------------+
+        Printer "Public-A"
+        - prints black and white
+        - prints Postscript
+        - in El Segundo, room H-6, building A
+        - driver ABC-Postscript-V1.3 required, here is URI
+        - printer is public
+        - help available at http://xerox/elSegundo/publicPrinters
+
+         Printer "Public-B"
+        - prints black and white
+        - prints PCL/5e
+        - is in El Segundo, room J-10, building A
+        - driver XYZ-PCL-V2.4 required, here is URI
+        - printer is public
+        - help available at http://xerox/elSegundo/publicPrinters
+
+10.3. PRINTER DISCOVERY ON THE INTERNET -LOGICAL OPERATIONS
+
+   A student wants to print a paper on a printer at his neighborhood
+   Ink-o's print shop. The report was written using Microsoft Word. The
+   student is interested in the cost of printing since his budget is
+   limited. Note the use of logical operators to find this information.
+
+
+
+Wright                        Experimental                     [Page 21]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   Client                          Ink-o's Directory Service
+
+      +---------------------------------------------------------- >
+        Find a Printer with these characteristics
+        - prints color or black and white
+        - costs less than $.50 per page
+        - tell me about resolution and marking technology
+
+      < ----------------------------------------------------------+
+        Printer "Color-A"
+        - prints color
+        - 600 dpi laser printer
+        - prints Postscript
+        - driver ABC-Postscript-V1.3 required, here is URI
+        - cost is $.50 per page for color
+        - payment required prior to submitting print job
+        - here is URI for more information on Ink-o's
+
+         Printer "Mono-B"
+        - prints black and white
+        - 300 dpi inkjet printer
+        - prints Postscript
+        - driver XYZ-Postscript-V2.4 required, here is URI
+        - cost is $0.35 page for black and white
+        - payment required prior to submitting print job
+        - here is URI for more information on Ink-o's
+
+10.4. PRINTER DISCOVERY ON THE INTERNET - AUTHENTICATION
+
+   An executive in her hotel room is finishing an important presentation
+   on her laptop computer. She connects to a local print shop through
+   the web to get a copy of her charts printed for tomorrow's
+   presentation.  She must find a print shop that is convenient to her
+   hotel and can print color transparencies. She wants to be sure that
+   the printer can be authenticated and can accept encrypted data.
+
+   Client                         SirZippy Directory Service
+
+      +---------------------------------------------------------- >
+        Find a Printer with these characteristics
+        - prints color transparencies
+        - is in Boulder, Colorado
+        - Printer can be authenticated
+        - Printer supports encryption
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 22]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Tell me when you are open for business
+
+      < ----------------------------------------------------------+
+        Printer "Color-A"
+        - prints color transparencies
+        - prints Postscript
+        - driver ABC-Postscript-V1.3 required, here is URI
+        - payment required prior to submitting print job
+        - Printer can be authenticated
+        - Data can be encrypted
+        - Located at 1670 Pearl Street, Boulder, CO
+        - This Branch is open 24 hours a day
+
+
+        Printer "Color-B"
+        - prints color transparencies
+        - prints Postscript
+        - driver ABC-Postscript-V1.3 required, here is URI
+        - payment required prior to submitting print job
+        - Printer can be authenticated
+        - Data can be encrypted
+        - Located at 1220 Arapahoe, Boulder, CO
+        - This Branch is open from 9:00 am to 6:30 pm
+
+10.5. DRIVER DOWNLOAD
+
+   An end user in an enterprise wants to print a lengthy report on a
+   newly installed high speed PostScript printer. Since she will likely
+   use this printer often, she would like to download a driver and
+   install it on her workstation. She is running Windows 95.  Note:
+   Driver download is not a V1.0 design goal.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Tell me where to find print drivers for you
+
+
+
+      < ----------------------------------------------------------+
+        Driver install file is at
+        http://www.ibm.com/drivers/NP12a/Win95
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 23]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+10.6. SUBMITTING A PRINT JOB AS A FILE
+
+   An end-user wants to submit a print job. The print file already
+   exists on his workstation. The client and printer are behind the same
+   corporate firewall. The printer is available to anyone behind the
+   firewall and no authorization or authentication is required. The data
+   is pushed to the printer. The printer is capable of spooling the
+   output. No errors occur.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - document is in Postscript format
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+        Print job accepted and spooled
+        - job id = #12345
+        - current state of print job = spooled
+        - submission time = 02/12/97, 15:35
+        - printer state = printing
+
+10.7. SUBMITTING A PRINT JOB WITH TWO DOCUMENTS
+
+   An end-user wants to submit a print job. The print file already
+   exists on his workstation. The client and printer are behind the same
+   corporate firewall. The printer is available to anyone behind the
+   firewall and no authorization or authentication is required. The data
+   is pushed to the printer. The job consists of two separate documents.
+   The printer is capable of spooling the output. No errors occur.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+
+      < ----------------------------------------------------------+
+
+
+
+Wright                        Experimental                     [Page 24]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Print job accepted and spooled
+        - job id = #12345
+        - submission time = 02/12/97, 15:35
+      +---------------------------------------------------------- >
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+        - OK
+
+      +---------------------------------------------------------- >
+        - here is the document to print, it is the last document.
+
+      < ----------------------------------------------------------+
+        - OK
+
+10.8. SUBMITTING A PRINT JOB AS A FILE, PRINTING FAILS
+
+   An end-user wants to submit a print job. The print file already
+   exists on his workstation. The client and printer are behind the same
+   corporate firewall. The printer is available to anyone behind the
+   firewall and no authorization or authentication is required. The data
+   is pushed to the printer. The printer is not capable of spooling the
+   output so it begins printing while still receiving the file. An error
+   occurs and the printer cannot complete printing (in this case the
+   user requires A4 paper and that paper size is not available on the
+   printer.)
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - document is in Postscript format
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+             Print job accepted
+
+        - printing failed
+        - current state of print job = canceled (A4 not available)
+        - submission time = 02/12/97, 15:35
+        - printer state = ready
+
+
+
+
+
+Wright                        Experimental                     [Page 25]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+10.9. SUBMITTING A PRINT JOB WITH AUTHENTICATION, PRIVACY AND PAYMENT
+
+   A traveling executive needs to print a set of transparencies for an
+   important business meeting. The charts are in Lotus Freelance format
+   on his notebook computer. He has located a SirZippy print shop near
+   his hotel that will print color transparencies. Because the
+   information on the charts is sensitive, he wants to be sure that his
+   data is sent to the Printer in an encrypted format. He also wants to
+   authenticate the Printer. The Printer also authenticates the user.
+   Payment occurs across the Internet.
+
+   Client                                               IPP Printer
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+
+        Mutual authentication and exchange of secret keys
+
+      +---------------------------------------------------------- >
+        Here is a print job (encrypted)
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - tell me where to pick up output
+        - document is in Postscript format
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+        Print job accepted and spooled (encrypted)
+        - job id = #12345
+        - current state of print job = spooled
+        - submission time = 02/12/97, 15:35
+        - printer state = printing
+        - payment required to proceed with job
+        - pick up at 230 East Main after 3:30 pm today
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+        Payment transaction
+
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 26]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+10.10. SUBMITTING A PRINT JOB WITH DECRYPTION ERROR
+
+   A traveling executive needs to print a set of transparencies for an
+   important business meeting. The charts are in Lotus Freelance format
+   on his notebook computer. He has located a SirZippy print shop near
+   his hotel that will print color transparencies. Because the
+   information on the charts is sensitive, he wants to be sure that his
+   data is sent to the printer in an encrypted format. He also wants to
+   authenticate the printer. The printer also authenticates the user.
+   Payment occurs across the Internet. An error occurs during
+   decryption.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+        Mutual authentication and exchange of secret keys
+
+
+      +---------------------------------------------------------- >
+        Here is a print job (encrypted)
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - tell me where to pick up output
+        - document is in Postscript format
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+        Print job accepted and spooled (encrypted)
+        - job id = #12345
+        - current state of print job = spooled
+        - submission time = 02/12/97, 15:35
+        - printer state = printing
+        - payment required to proceed with job
+        - pick up at 230 East Main after 3:30 pm today
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+        Payment transaction
+        .
+        .
+        .
+      < ----------------------------------------------------------+
+        Asynchronous response (email in this case)
+        - decryption failed on job #12345
+
+
+
+Wright                        Experimental                     [Page 27]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        - no pages printed
+        - current state of job = aborted
+
+10.11. SUBMITTING A PRINT JOB WITH AUTHENTICATION
+
+   An end-user wants to submit a print job. The print file already
+   exists on his workstation. The client and printer are behind the same
+   corporate firewall. The printer is available to anyone behind the
+   firewall but authentication and authorization is required.
+   Authorization takes place using the authenticated end-user's name.
+   The data is pushed to the printer. The printer is capable of spooling
+   the output.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+        Authentication
+
+        Note: An authentication failure would end the transaction at
+                  this point.
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - tell me where to pick up output
+        - document is in Postscript format
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+        Print job accepted and spooled
+        - job id = #12345
+        - current state of print job = spooled
+        - submission time = 02/12/97, 15:35
+        - printer state = printing
+
+
+
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 28]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+10.12. SUBMITTING A PRINT JOB GENERATED DYNAMICALLY
+
+   An end-user wants to submit a print job. The print data is generated
+   dynamically and is being transmitted by a printer driver on the
+   client workstation as available. The client and printer are behind
+   the same corporate firewall. The printer is available to anyone
+   behind the firewall and no authentication and authorization is
+   required. The data is pushed to the printer. The printer is capable
+   of spooling the output.  No error occurs.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - document is in Postscript format
+        - here is the print job
+
+
+      < ----------------------------------------------------------+
+        Print data accepted and spooling started
+        - job id = #12345
+        - current job state = spooled
+        - submission time = 02/12/97, 15:35
+        - printer state = printing
+
+10.13. SUBMITTING A PRINT JOB WITH A PRINTER JAM - CANCELED
+
+   An end-user wants to submit a print job. The print data is generated
+   dynamically and is being transmitted by a printer driver on the
+   client workstation as available. The client and printer are behind
+   the same corporate firewall. The printer is available to anyone
+   behind the firewall and no authentication and authorization is
+   required. The data is pushed to the printer. The printer is not
+   capable of spooling the output. The printer jams notifies the user
+   and the user chooses to cancel the job.
+
+   Client                                            IPP Printer
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+
+
+
+Wright                        Experimental                     [Page 29]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        - return status of the printer in response
+        - document is in Postscript format
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+        Print data accepted and printing started
+        - job id = #12345
+
+      +---------------------------------------------------------- >
+        - What is the status of print job #12345?
+
+      < --------------------------------------------------------- +
+        - Job #12345 accepted but printer jammed, cannot continue
+
+      +---------------------------------------------------------- >
+        - Cancel job #12345
+
+      * Printer flushes remaining data
+      < ----------------------------------------------------------+
+         Print job terminated
+        - current job state = canceled
+        - submission time = 02/12/97, 15:35
+        - printer state = jammed
+
+10.14. SUBMITTING A PRINT JOB WITH A PRINTER JAM - RECOVERED
+
+   An end-user wants to submit a print job. The print data is generated
+   dynamically and is being transmitted by a printer driver on the
+   client workstation as available. The client and printer are behind
+   the same corporate firewall. The printer is available to anyone
+   behind the firewall and no authentication and authorization is
+   required. The data is pushed to the printer. The printer is not
+   capable of spooling the output. The printer jams, notifies the user
+   and the user clears the jam and elects to continue.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - document is in Postscript format
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+
+
+
+Wright                        Experimental                     [Page 30]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Print data accepted and printing started
+        - job id = #12345
+
+      < --------------------------------------------------------- +
+        - Notification: printer jammed, cannot continue
+
+      * Jam is clear by human intervention, printing continues
+
+      +---------------------------------------------------------- >
+         Here is the last part of the document to print
+
+      < ----------------------------------------------------------+
+         Print job received
+        - current job state = printing
+        - submission time = 02/12/97, 15:35
+        - printer state = printing
+
+10.15. SUBMITTING A PRINT JOB WITH SERVER PULL
+
+   An end-user wants to submit a print job. The print data is in a file
+   and is publicly available. It is pulled by the printer. The client
+   and printer are behind the same corporate firewall. The printer is
+   available to anyone behind the firewall and no authentication and
+   authorization is required. The printer is capable of spooling the
+   output. Printing may start before the entire job has been pulled.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Here is a print job
+
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+        - here is a reference to the data to be printed
+
+      < ----------------------------------------------------------+
+        Print data accepted and printing started
+        - job id = #12345
+        - current state of job = spooled
+        - submission time = 02/12/97, 13:15
+        - printer state = printing
+
+        .
+        .
+       < ----------------------------------------------------------+
+
+
+
+Wright                        Experimental                     [Page 31]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Get the file to be printed
+
+       +---------------------------------------------------------- >
+        Here it is
+
+        Note: Failure to find the file, would end the transaction
+                  with an error at this point and an asynchronous
+                  notification would be send to the Client.
+
+       < ----------------------------------------------------------+
+         Data received
+
+10.16. SUBMITTING A PRINT JOB WITH REFERENCED RESOURCES
+
+   An end-user wants to submit a print job.  Part of the print data is
+   on a file on the user's workstation. It is pushed by the client, but
+   the print job requires some resource not included in the print file.
+   The client and printer are behind the same corporate firewall. The
+   printer is available to anyone behind the firewall and no
+   authentication and authorization is required. The printer is capable
+   of spooling the output. No errors occur.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job name = MyJob
+        - notify me by email when done printing
+        - print on iso-a4-white paper
+        - print on both sides of the paper
+        - return status of the printer in response
+
+      < ----------------------------------------------------------+
+        Print job accepted and spooled
+        - job id = #12345
+        - submission time = 02/12/97, 15:35
+
+      +---------------------------------------------------------- >
+        - here is the document to print
+
+      < ----------------------------------------------------------+
+        - OK
+
+      +---------------------------------------------------------- >
+        - here is the URI to print, it is the last document.
+
+      < ----------------------------------------------------------+
+        - OK
+
+
+
+Wright                        Experimental                     [Page 32]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+       < ----------------------------------------------------------+
+         Get the external resource
+
+       +---------------------------------------------------------- >
+         Here it is
+
+10.17. GETTING CAPABILITIES
+
+10.17.1. Submission Attributes
+
+   An end-user wants to get the production and scheduling attributes
+   that are supported or required when submitting jobs to this printer.
+   The client will use these attributes when forming the subsequent
+   print request.
+
+   Client                                        IPP Printer
+      +---------------------------------------------------------- >
+        I'm going to submit a Postscript job
+        give me your job submission attributes
+
+      < ----------------------------------------------------------+
+        Postscript production attributes for this Printer are:
+        - medium-select = us-letter-white, us-legal-white
+           - default is us-letter-white
+           -   copies = 1,2,3,4,5
+           - default is 1
+                - print-quality = draft, normal, high
+           - default is draft
+                - sides = 1-sided, 2-sided-long-edge
+           - default is 2-sided-long-edge
+        - Job scheduling attributes for this Printer are:
+             - job-priority = 1,2,3
+           - default = 3
+
+10.17.2. Printer Capabilities
+
+   An end-user wants to determine the resolution, marking technology,
+   and PDLs supported by the printer.
+
+   Client                                        IPP Printer
+      +---------------------------------------------------------- >
+        Please tell me the
+        - resolution of the printer
+        - the marking technology of the printer
+        - PDLs supported
+      < ----------------------------------------------------------+
+        Printer resolution  = 600 dpi
+        Marking Technology = laser
+
+
+
+Wright                        Experimental                     [Page 33]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        PDLs supported = Postscript level 2, PCL/6
+
+10.18. GETTING STATUS
+
+10.18.1. Printer State/Status
+
+   An end-user wants to determine the state or status of the printer.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        What is the state of the printer?
+
+      < ----------------------------------------------------------+
+        Printer state = out-of-paper
+
+10.18.2. Job Status
+
+   An end user wants to get the status of a job he has submitted.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Please tell me the status of job #12345
+
+      < ----------------------------------------------------------+
+        Job #12345 is queued
+        it is number 3 in the queue
+        printer state = printing
+
+10.18.3. Status of All My Jobs
+
+   An end user wants to get a list of all of the jobs he has submitted
+   to this Printer.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+        Please tell me the status of my jobs
+
+      < ----------------------------------------------------------+
+        Job #00012 is complete
+        Printed at 12:35 on 01/23/97
+
+        Job #09876 is printing
+
+        Job #12345 is queued
+        it is number 3 in the queue
+
+
+
+Wright                        Experimental                     [Page 34]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Job #34567 is queued
+        it is number 7 in the queue
+
+10.19. ASYNCHRONOUS NOTIFICATION
+
+10.19.1. Job Completion
+
+   An end-user wants to get notification of events that affect his print
+   jobs. Print job completes without error.
+
+   Client                                        IPP Printer
+
+      < ----------------------------------------------------------+
+        Print job #123 completed
+
+10.19.2. Job Complete with Data
+
+   An end-user wants to get notification of events that affect his print
+   jobs. Print job completes, users asked for all end of job
+   information.
+
+   Client                                        IPP Printer
+
+      < ----------------------------------------------------------+
+        Print job #123 completed
+        - total pages printed = 15
+        - number of copies printed = 3
+        - total cost to print = $7.45
+        - pick up copies in room H-6, building 005
+
+10.19.3. Print Job Fails
+
+   An end-user wants to get notification of events that affect his print
+   jobs. Print job fails. Printer is unattended.
+
+   Client                                        IPP Printer
+
+      < ----------------------------------------------------------+
+        Print job #123 failed
+        - total pages printed = 15
+        - number of pages submitted = 25
+        - printer-state = jammed
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 35]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+10.20. CANCEL A JOB
+
+   The end-user submits a print job and later decides to cancel it.
+
+   Client                                        IPP Printer
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+        Authentication.
+
+
+      +---------------------------------------------------------- >
+        Cancel job #1234
+
+      < ----------------------------------------------------------+
+        Job #1234 Canceled
+
+
+10.21. END TO END SCENARIO - WITHIN AN ENTERPRISE
+
+   An office worker prints on shared departmental printers. All printers
+   in the office are public, that is, no authentication or authorization
+   is required. Printers are protected from external access by a
+   firewall. No billing or accounting is required. Most printing is done
+   from desktop applications. A help desk is provided for printing
+   problems. Standard operating systems and applications are used.
+   Drivers are available, but are installed manually by support
+   personnel. This scenario assumes that drivers have been installed and
+   that drivers are not IPP aware, that is, they cannot communicate
+   across an IPP connection to obtain status and capabilities. IPP
+   printers appear in application pull-down menus.  Printer
+   configuration data is hard wired into the driver.
+
+   End-user selects print from the application pull down menu. An IPP
+   printer is selected from the list of Printers offered
+
+   The driver puts up a dialogue with hard-wired set of options for this
+   printer. The end-user makes choices and submits job.
+
+   Client                                        IPP Printer
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job-name = memo-to-boss
+        - notify me by email when job is complete
+        - print on us-letter-white paper
+        - print 1 copy
+        - print at normal quality
+        - print on 1 side
+
+
+
+Wright                        Experimental                     [Page 36]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        - give me the state of the printer in response
+
+   The driver generates the print data and passes it to the IPP driver a
+   piece at a time as it is generated.
+
+      +---------------------------------------------------------- >
+        Here is the print data
+
+
+      < ----------------------------------------------------------+
+        Print data received, file is spooled
+        - printer state = printing
+        - time submitted = 2/12/97, 15:35
+        - current job state = spooled
+
+   Client adds this job to list of current jobs. List of jobs and state
+   of each is available on a pull-down menu on the client.
+
+   End-user selects job #1234 from list and clicks on it to see its
+   status.
+
+      +---------------------------------------------------------- >
+        Give me the state of job #1234
+        and the state of the Printer
+
+      < ----------------------------------------------------------+
+        Job #1234 state = spooled
+        - it is number 3 in the queue
+        - printer state = printing
+
+   The job completes without error
+
+      < ----------------------------------------------------------+
+        Job #1234 completed
+        12 of 12 pages printed
+
+10.22. END TO END SCENARIO - ACROSS ENTERPRISES
+
+   An office worker in Company A needs to print an office document on a
+   "public" printer at Company B, a business partner. Both companies
+   have corporate firewalls so the print request must flow out of A's
+   firewall and into B's firewall. The office worker can look at public
+   printers in Company B's directory service. The document is generated
+   by a desktop application. Since the printer is "public" no
+   authentication or authorization is required.  A driver is downloaded.
+   The driver is IPP aware, that is, it can communicate dynamically
+   through the IPP protocol layer to obtain information about the
+   printer.
+
+
+
+Wright                        Experimental                     [Page 37]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+   Client                      Company B's Directory Service
+
+   End user connects to B's Directory service
+
+      +---------------------------------------------------------- >
+        Find a Printer with these characteristics
+        - public (no authorization or authentication required)
+        - is in Lexington, building 004
+        - prints black and white
+
+      < ----------------------------------------------------------+
+        Printer "Public-A"
+        - http://www.lexmark.com/pubprinter/a
+
+        Printer "Public-B"
+        - http://www.lexmark.com/pubprinter/b
+
+   End user selects Public-A
+
+   Client                                           Public-A
+
+      +---------------------------------------------------------- >
+        Where can I find a driver for you?
+
+      < ----------------------------------------------------------+
+        Drivers at http://www.lexmark.com/pubprinters/a/os245
+
+   End user gets driver and installs it on his PC.
+
+   End-user selects print from the application pull down menu. "Public-
+   A" is selected from the list of Printers offered
+
+      +---------------------------------------------------------- >
+        I'm going to submit a print job
+        give me your job submission attributes
+
+      < ----------------------------------------------------------+
+
+        Production attributes for this Printer are:
+        - medium-select = us-letter-white, us-legal-white
+           - default is us-letter-white
+           -   copies = 1,2,3,4,5
+           - default is 1
+                - print-quality = draft, normal, high
+           - default is draft
+                - sides = 1-sided, 2-sided-long-edge
+           - default is 2-sided-long-edge
+
+
+
+
+Wright                        Experimental                     [Page 38]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Job scheduling attributes for this Printer are:
+        - job-priority = 1,2,3
+           default = 3
+
+   Driver puts up dialogue with available options and fills in the
+   defaults.
+
+   End-user makes choices and submits job
+
+      +---------------------------------------------------------- >
+        Here is a print job
+        - job-name = memo-to-Don-Wright
+        - notify me by email when job is complete
+        - print on us-letter-white paper
+        - print 1 copy
+        - print at normal quality
+        - print on 1 side
+        - give me the state of the printer in response
+
+
+   The driver generates the print data and passes it to the IPP driver a
+   piece at a time.
+
+      +---------------------------------------------------------- >
+        Here is the print data
+
+      < ----------------------------------------------------------+
+        Print data received, and spooling started
+        print job id = #1234
+
+        Print data received, file is spooled
+
+        - printer state = printing
+        - time submitted = 2/12/97, 15:35
+        - current job state = spooled
+
+   Client adds this job to list of current jobs.  List of jobs and state
+   of each is available on a pull-down menu on the client.
+
+   End-user selects job #1234 from list and clicks on it to see its
+   status.
+
+      +---------------------------------------------------------- >
+        Give me the state of job #1234
+        and the state of the Printer
+
+      < ----------------------------------------------------------+
+        Job #1234 state = spooled
+
+
+
+Wright                        Experimental                     [Page 39]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        - it is number 3 in the queue
+        - printer state = printing
+
+       * The job completes without error
+      < ----------------------------------------------------------+
+        Job #1234 completed
+        12 of 12 pages printed
+
+10.23. END TO END SCENARIO - ON THE INTERNET
+
+   An executive in her hotel room is finishing an important presentation
+   on her laptop computer. She connects to a local print shop through
+   the web to get a copy of her charts printed for tomorrow's
+   presentation.  She must find a print shop that is convenient and can
+   print color transparencies. She must download and temporarily install
+   a driver in order to generate the PDL required by the print shop.
+   Mutual authentication is required by the print shop and payment must
+   be made in advance. The job is encrypted on the wire to prevent
+   eavesdropping.
+
+   End-user completes presentation. She goes to the web and connects to
+   the SirZippy home page.
+
+      Client                      SirZippy Directory Service
+      +---------------------------------------------------------- >
+
+        Find me a printer with these characteristics
+        - Near Market Street in San Jose
+        - Prints color transparencies
+        - drivers can be downloaded
+        - supports privacy (encryption)
+        -
+
+   Available Printers matching these characteristics are looked up in the
+   Directory Service
+
+      < ----------------------------------------------------------+
+
+        Printer "Color-A"
+        - located at 123 First Street in San Jose
+        - URI is http://www.SirZippy.com/FirstStreet/Color-A
+        - prints color transparencies
+        - 600 dpi laser
+        - driver ABC-Postscript-V1.3 available at this URI
+        - cost = $.75 per page
+        - authentication required to use printer
+        - payment required prior to printing
+
+
+
+
+Wright                        Experimental                     [Page 40]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Printer "Color-B"
+        - located at 67 San Carlos Street, San Jose
+        - URI is http://www.SirZippy.com/SanCarlos/Color-B
+        - prints color transparencies
+        - 1200 dpi laser
+        - driver XYZ-PostScript-V4.3 available at this URI
+        - cost = $1.25 per page
+        - authentication required to use printer
+        - payment required prior to printing
+        - more information at this URI
+
+   The user decides to use the first printer because it is closer. She
+   connects to the URI given to get a driver.
+
+   Client                                         Driver URI
+
+      +---------------------------------------------------------- >
+        I need a driver for "Color-A"
+
+
+      < ----------------------------------------------------------+
+         Driver installer is at http://www.xerox.com/prtdrvrs
+
+        Driver is installed
+
+        User connects to
+        "Color-A"
+
+   Client                              IPP Printer "Color-A"
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+        Mutual authentication and exchange of secret keys
+
+      +---------------------------------------------------------- >
+        I'm going to submit a print job
+        give me your job submission attributes
+
+      < ----------------------------------------------------------+
+        Production attributes for this Printer are:
+        - medium-select = us-letter-white, us-legal-white
+             - default is us-letter-white
+        - copies = 1,2,3,4,5
+             - default is 1
+        - print-quality = draft, normal, high
+             - default is draft
+        - sides = 1-sided, 2-sided-long-edge
+             - default is 2-sided-long-edge
+
+
+
+Wright                        Experimental                     [Page 41]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+        Job scheduling attributes for this Printer are:
+        - job-priority = 1,2,3
+           default = 3
+
+   Driver puts up dialogue with available options and fills in the
+   defaults.
+
+   End-user makes choices and submits job
+
+      +---------------------------------------------------------- >
+         Here is a print job
+
+        - job-name = presentation
+        - notify me by email when job is complete
+        - print on us-letter-transparency
+        - print 1 copy
+        - print at high quality
+        - print by 9:00 am tomorrow morning
+        - give me the state of the printer in response
+
+   The driver generates the print data and passes it to the IPP  driver a
+   piece at a time.
+
+      +---------------------------------------------------------- >
+       Here is the print data
+
+       < ---------------------------------------------------------+
+       Print data received, and spooling started
+       print job id = #1234
+
+       Print data received, file is spooled
+        - printer state = printing
+        - time submitted = 2/12/97, 15:35
+        - current job state = held, waiting for payment
+
+      +---------------------------------------------------------- >
+      < ----------------------------------------------------------+
+        Payment transaction
+
+      < ----------------------------------------------------------+
+        Job is scheduled to print, pick up after 9:00am tomorrow
+        Thank you for using SirZippy
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 42]
+
+RFC 2567             Internet Printing Design Goals           April 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wright                        Experimental                     [Page 43]
+
diff --git a/standards/rfc2568.txt b/standards/rfc2568.txt
new file mode 100644
index 000000000..2d3ae4905
--- /dev/null
+++ b/standards/rfc2568.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                          S. Zilles
+Request for Comments: 2568                            Adobe Systems Inc.
+Category: Experimental                                        April 1999
+
+
+         Rationale for the Structure of the Model and Protocol
+                   for the Internet Printing Protocol
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+IESG Note
+
+   This document defines an Experimental protocol for the Internet
+   community.  The IESG expects that a revised version of this protocol
+   will be published as Proposed Standard protocol.  The Proposed
+   Standard, when published, is expected to change from the protocol
+   defined in this memo.  In particular, it is expected that the
+   standards-track version of the protocol will incorporate strong
+   authentication and privacy features, and that an "ipp:" URL type will
+   be defined which supports those security measures.  Other changes to
+   the protocol are also possible.  Implementors are warned that future
+   versions of this protocol may not interoperate with the version of
+   IPP defined in this document, or if they do interoperate, that some
+   protocol features may not be available.
+
+   The IESG encourages experimentation with this protocol, especially in
+   combination with Transport Layer Security (TLS) [RFC2246], to help
+   determine how TLS may effectively be used as a security layer for
+   IPP.
+
+ABSTRACT
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies. This document describes IPP
+   from a high level view, defines a roadmap for the various documents
+   that form the suite of IPP specifications, and gives background and
+   rationale for the IETF working group's major decisions.
+
+
+
+Zilles                        Experimental                      [Page 1]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+   The full set of IPP documents includes:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol (this document)
+      Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
+      Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
+      Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
+      Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  The Design Goals document calls out a subset of end
+   user requirements that are satisfied in IPP/1.0. Operator and
+   administrator requirements are out of scope for version 1.0.
+
+   The "Internet Printing Protocol/1.0: Model and Semantics" document
+   describes a simplified model consisting of abstract objects, their
+   attributes, and their operations that is independent of encoding and
+   transport.  The model consists of a Printer and a Job object.  The
+   Job optionally supports multiple documents.  This document also
+   addresses security, internationalization, and directory issues.
+
+   The "Internet Printing Protocol/1.0: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1.  It defines the encoding rules
+   for a new Internet media type called "application/ipp".
+
+   The "Internet Printing Protocol/1.0: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.0 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+1.   ARCHITECTURAL OVERVIEW
+
+   The Internet Printing Protocol (IPP) is an application level protocol
+   that can be used for distributed printing on the Internet.  This
+   protocol defines interactions between a client and a server.  The
+
+
+
+Zilles                        Experimental                      [Page 2]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+   protocol allows a client to inquire about capabilities of a printer,
+   to submit print jobs and to inquire about and cancel print jobs. The
+   server for these requests is the Printer; the Printer is an
+   abstraction of a generic document output device and/or a print
+   service provider. Thus, the Printer could be a real printing device,
+   such as a computer printer or fax output device, or it could be a
+   service that interfaced with output devices.
+
+   The protocol is heavily influenced by the printing model introduced
+   in the Document Printing Application (DPA) [ISO10175] standard.
+   Although DPA specifies both end user and administrative features, IPP
+   version 1.0 (IPP/1.0) focuses only on end user functionality.
+
+   The architecture for IPP defines (in the Model and Semantics document
+   [RFC2566]) an abstract Model for the data which is used to control
+   the printing process and to provide information about the process and
+   the capabilities of the Printer. This abstract Model is hierarchical
+   in nature and reflects the structure of the Printer and the Jobs that
+   may be being processed by the Printer.
+
+   The Internet provides a channel between the client and the
+   server/Printer. Use of this channel requires flattening and
+   sequencing the hierarchical Model data. Therefore, the IPP also
+   defines (in the Encoding and Transport document [RFC2565]) an
+   encoding of the data in the model for transfer between the client and
+   server.  This transfer of data may be either a request or the
+   response to a request.
+
+   Finally, the IPP defines (in the Encoding and Transport document
+   [RFC2565]) a protocol for transferring the encoded request and
+   response data between the client and the server/Printer.
+
+   An example of a typical interaction would be a request from the
+   client to create a print job. The client would assemble the Model
+   data to be associated with that job, such as the name of the job, the
+   media to use, the number of pages to place on each media instance,
+   etc. This data would then be encoded according to the Protocol and
+   would be transmitted according to the Protocol. The server/Printer
+   would receive the encoded Model data, decode it into a form
+   understood by the server/Printer and, based on that data, do one of
+   two things: (1) accept the job or (2) reject the job. In either case,
+   the server must construct a response in terms of the Model data,
+   encode that response according to the Protocol and transmit that
+   encoded Model data as the response to the request using the Protocol.
+
+   Another part of the IPP architecture is the Directory Schema
+   described in the model document. The role of a Directory Schema is to
+   provide a standard set of attributes which might be used to query a
+
+
+
+Zilles                        Experimental                      [Page 3]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+   directory service for the URI of a Printer that is likely to meet the
+   needs of the client. The IPP architecture also addresses security
+   issues such as control of access to server/Printers and secure
+   transmissions of requests, response and the data to be printed.
+
+2. THE PRINTER
+
+   Because the (abstract) server/Printer encompasses a wide range of
+   implementations, it is necessary to make some assumptions about a
+   minimal implementation. The most likely minimal implementation is one
+   that is embedded in an output device running a specialized real time
+   operating system and with limited processing, memory and storage
+   capabilities. This printer will be connected to the Internet and will
+   have at least a TCP/IP capability with (likely) SNMP [RFC1905,
+   RFC1906] support for the Internet connection. In addition, it is
+   likely the the Printer will be an HTML/HTTP server to allow direct
+   user access to information about the printer.
+
+3. RATIONALE FOR THE MODEL
+
+   The Model [RFC2566] is defined independently of any encoding of the
+   Model data both to support the likely uses of IPP and to be robust
+   with respect to the possibility of alternate encoding.
+
+   It is expected that a client or server/Printer would represent the
+   Model data in some data structure within the applications/servers
+   that support IPP. Therefore, the Model was designed to make that
+   representation straightforward. Typically a parser or formatter would
+   be used to convert from or to the encoded data format. Once in an
+   internal form suitable to a product, the data can be manipulated by
+   the product. For example, the data sent with a Print Job can be used
+   to control the processing of that Print Job.
+
+   The semantics of IPP are attached to the (abstract) Model.
+   Therefore, the application/server is not dependent on the encoding of
+   the Model data, and it is possible to consider alternative mechanisms
+   and formats by which the data could be transmitted from a client to a
+   server; for example, a server could have a direct, client-less GUI
+   interface that might be used to accept some kinds of Print Jobs. This
+   independence would also allow a different encoding and/or
+   transmission mechanism to be used if the ones adopted here were shown
+   to be overly limiting in the future. Such a change could be migrated
+   into new products as an alternate protocol stack/parser for the Model
+   data.
+
+
+
+
+
+
+
+Zilles                        Experimental                      [Page 4]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+   Having an abstract Model also allows the Model data to be aligned
+   with the (abstract) model used in the Printer [RFC1759], Job and Host
+   Resources MIBs. This provides consistency in interpretation of the
+   data obtained independently of how the data is accessed, whether via
+   IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs.
+
+   There is one aspect of the Model that deserves some extra
+   explanation. There are two ways for identifying a Job object: (a)
+   with a Job URI and (b) using a combination of the Printer URI and a
+   Job ID (a 32 bit positive integer). Allowing Job objects to have URIs
+   allows for flexibility and scalability. For example a job could be
+   moved from a printer with a large backlog to one with a smaller load
+   and the job identification, the Job object URI, need not change.
+   However, many existing printing systems have local models or
+   interface constraints that force Job objects to be identified using
+   only a 32-bit positive integer rather than a URI.  This numeric Job
+   ID is only unique within the context of the Printer object to which
+   the create request was originally submitted.  In order to allow both
+   types of client access to Jobs (either by Job URI or by numeric Job
+   ID), when the Printer object successfully processes a create request
+   and creates a new Job, the Printer object generates both a Job URI
+   and a Job ID for the new Job object. This requirement allows all
+   clients to access Printer objects and Job objects independent of any
+   local constraints imposed on the client implementation.
+
+4. RATIONALE FOR THE PROTOCOL
+
+   There are two parts to the Protocol: (1) the encoding of the Model
+   data and (2) the mechanism for transmitting the model data between
+   client and server.
+
+4.1 The Encoding
+
+   To make it simpler to develop embedded printers, a very simple binary
+   encoding has been chosen. This encoding is adequate to represent the
+   kinds of data that occur within the Model. It has a simple structure
+   consisting of sequences of attributes. Each attribute has a name,
+   prefixed by a name length, and a value. The names are strings
+   constrained to characters from a subset of ASCII.  The values are
+   either scalars or a sequence of scalars. Each scalar value has a
+   length specification and a value tag which indicates the type of the
+   value. The value type has two parts: a major class part, such as
+   integer or string, and a minor class part which distinguishes the
+   usage of the major class, such as dateTime string. Tagging of the
+   values with type information allows for introducing new value types
+   at some future time.
+
+
+
+
+
+Zilles                        Experimental                      [Page 5]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+   A fully encoded request/response has a version number, an operation
+   (for a request) or a status and optionally a status message (for a
+   response), associated parameters and attributes which are encoded
+   Model data and, optionally (for a request), print data following the
+   Model data.
+
+4.2 The Transmission Mechanism
+
+   The chosen mechanism for transmitting the encoded Model data is HTTP
+   1.1 Post (and associated response). No modifications to HTTP 1.1 are
+   proposed or required. The sole role of the Transmission Mechanism is
+   to provide a transfer of encoded Model data from/to the client
+   to/from the server. This could be done using any data delivery
+   mechanism. The key reasons why HTTP 1.1 Post is used are given below.
+   The most important of these is the first. With perhaps this
+   exception, these reasons could be satisfied by other mechanisms.
+   There is no claim that this list uniquely determines a choice of
+   mechanism.
+
+      1. HTTP 1.0 is already widely deployed and, based on the recent
+      evidence, HTTP 1.1 is being widely deployed as the manufacturers
+      release new products. The performance benefits of HTTP 1.1 have
+      been shown and manufactures are reacting positively.
+
+      Wide deployment has meant that many of the problems of making a
+      protocol work in a wide range of environments from local net to
+      Intranet to Internet have been solved and will stay solved with
+      HTTP 1.1 deployment.
+
+      2. HTTP 1.1 solves most of the problems that might have required a
+      new protocol to be developed. HTTP 1.1 allows persistent
+      connections that make a multi-message protocol be more efficient;
+      for example it is practical to have separate Create-Job and Send-
+      Document messages. Chunking allows the transmission of large print
+      files without having to pre-scan the file to determine the file
+      length. The accept headers allow the client's protocol and
+      localization desires to be transmitted with the IPP operations and
+      data. If the Model were to provide for the redirection of Job
+      requests, such as Cancel-Job, when a Job is moved, the HTTP
+      redirect response allows a client to be informed when a Job he is
+      interested in is moved to another server/Printer for any reason.
+
+      3. Most network Printers will be implementing HTTP servers for
+      reasons other than IPP. These network attached Printers want to
+      provide information on how to use the printer, its current state,
+      HELP information, etc. in HTML. This requires having an HTTP
+      server which would be available to do IPP functions as well.
+
+
+
+
+Zilles                        Experimental                      [Page 6]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+      4.  Most of the complexity of HTTP 1.1 is concerned with the
+      implementation of HTTP proxies and not the implementation of HTTP
+      clients and/or servers. Work is proceeding in the HTTP Working
+      Group to help identify what must be done by a server.  As the
+      Encoding and Transport document shows, that is not very much.
+
+      5. HTTP implementations provide support for handling URLs that
+      would have to be provided if a new protocol were defined.
+
+      6. An HTTP based solution fits well with the Internet security
+      mechanisms that are currently deployed or being deployed. HTTP
+      will run over SSL3. The digest access authentication mechanism of
+      HTTP 1.1 provides an adequate level of access control. These
+      solutions are deployed and in practical use; a new solution would
+      require extensive use to have the same degree of confidence in its
+      security.  Note: SSL3 is not on the IETF standards track.
+
+      7. HTTP provides an extensibility model that a new protocol would
+      have to develop independently. In particular, the headers,
+      intent-types (via Internet Media Types) and error codes have wide
+      acceptance and a useful set of definitions and methods for
+      extension.
+
+      8. Although not strictly a reason why IPP should use HTTP as the
+      transmission protocol, it is extremely helpful that there are many
+      prototyping tools that work with HTTP and that CGI scripts can be
+      used to test and debug parts of the protocol.
+
+      9. Finally, the POST method was chosen to carry the print data
+      because its usage for data transmission has been established, it
+      works and the results are available via CGI scripts or servlets.
+      Creating a new method would have better identified the intended
+      use of the POSTed data, but a new method would be more difficult
+      to deploy. Assigning a new default port for IPP provided the
+      necessary identification with minimal impact to installed
+      infrastructure, so was chosen instead.
+
+5. RATIONALE FOR THE DIRECTORY SCHEMA
+
+      Successful use of IPP depends on the client finding a suitable IPP
+      enabled Printer to which to send a IPP requests, such as print a
+      job. This task is simplified if there is a Directory Service which
+      can be queried for a suitable Printer. The purpose of the
+      Directory Schema is to have a standard description of Printer
+      attributes that can be associated the URI for the printer. These
+      attributes are a subset of the Model attributes and can be encoded
+      in the appropriate query syntax for the Directory Service being
+      used by the client.
+
+
+
+Zilles                        Experimental                      [Page 7]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY
+
+      Security is an area of active work on the Internet. Complete
+      solutions to a wide range of security concerns are not yet
+      available. Therefore, in the design of IPP, the focus has been on
+      identifying a set of security protocols/features that are
+      implemented (or currently implementable) and solve real problems
+      with distributed printing. The two areas that seem appropriate to
+      support are: (1) authorization to use a Printer and (2) secure
+      interaction with a printer. The chosen mechanisms are the digest
+      authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure
+      communication mechanism.
+
+7. REFERENCES
+
+   [ipp-iig]  Hastings, T. and C. Manros, "Internet Printing
+              Protocol/1.0:Implementer's Guide", Work in Progress.
+
+   [RFC2569]  Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+              "Mapping between LPD and IPP Protocols", RFC 2569, April
+              1999.
+
+   [RFC2566]  deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P.
+              Powell, "Internet Printing Protocol/1.0: Model and
+              Semantics", RFC 2566, April 1999.
+
+   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
+              Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+              April 1999.
+
+   [RFC2567]  Wright, D., "Design Goals for an Internet Printing
+              Protocol", RFC 2567, April 1999.
+
+   [ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June
+              1996.
+
+   [RFC1759]  Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+              Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+   [RFC1905]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+              "Protocol Operations for Version 2 of the Simple Network
+              Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+   [RFC1906]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+              "Transport Mappings for  Version 2 of the Simple Network
+              Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+
+
+
+
+Zilles                        Experimental                      [Page 8]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+   [SSL]      Netscape, The SSL Protocol, Version 3, (Text version
+              3.02), November 1996.
+
+8. AUTHOR'S ADDRESS
+
+   Stephen Zilles
+   Adobe Systems Incorporated
+   345 Park Avenue
+   MailStop W14
+   San Jose, CA 95110-2704
+
+   Phone: +1 408 536-4766
+   Fax:   +1 408 537-4042
+   EMail: szilles@adobe.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zilles                        Experimental                      [Page 9]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zilles                        Experimental                     [Page 10]
+
diff --git a/standards/rfc2569.txt b/standards/rfc2569.txt
new file mode 100644
index 000000000..767857c34
--- /dev/null
+++ b/standards/rfc2569.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                         R. Herriot
+Request For Comments: 2569                             Xerox Corporation
+Category: Experimental                                         N. Jacobs
+                                                  Sun Microsystems, Inc.
+                                                             T. Hastings
+                                                       Xerox Corporation
+                                                               J. Martin
+                                                        Underscore, Inc.
+                                                              April 1999
+
+
+                 Mapping between LPD and IPP Protocols
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+IESG Note
+
+   This document defines an Experimental protocol for the Internet
+   community.  The IESG expects that a revised version of this protocol
+   will be published as Proposed Standard protocol.  The Proposed
+   Standard, when published, is expected to change from the protocol
+   defined in this memo.  In particular, it is expected that the
+   standards-track version of the protocol will incorporate strong
+   authentication and privacy features, and that an "ipp:" URL type will
+   be defined which supports those security measures.  Other changes to
+   the protocol are also possible.  Implementors are warned that future
+   versions of this protocol may not interoperate with the version of
+   IPP defined in this document, or if they do interoperate, that some
+   protocol features may not be available.
+
+   The IESG encourages experimentation with this protocol, especially in
+   combination with Transport Layer Security (TLS) [RFC 2246], to help
+   determine how TLS may effectively be used as a security layer for
+   IPP.
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 1]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+Abstract
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP). IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies. This document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon). This document describes the mapping between (1) the commands
+   and operands of the 'Line Printer Daemon (LPD) Protocol' specified in
+   RFC 1179 and (2) the operations, operation attributes and job
+   template attributes of the Internet Printing Protocol/1.0 (IPP).  One
+   of the purposes of this document is to compare the functionality of
+   the two protocols.  Another purpose is to facilitate implementation
+   of gateways between LPD and IPP.
+
+   WARNING: RFC 1179 was not on the IETF standards track.  While RFC
+   1179 was intended to record existing practice, it fell short in some
+   areas.  However, this specification maps between (1) the actual
+   current practice of RFC 1179 and (2) IPP.  This document does not
+   attempt to map the numerous divergent extensions to the LPD protocol
+   that have been made by many implementers.
+
+   The full set of IPP documents includes:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
+      Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
+      Internet Printing Protocol/1.0: Implementors Guide [ipp-iig]
+      Mapping between LPD and IPP Protocols (this document)
+
+   The document, "Design Goals for an Internet Printing Protocol", takes
+   a broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet. It identifies
+   requirements for three types of users: end users, operators, and
+   administrators. It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0. Operator and administrator requirements are
+   out of scope for version 1.0.
+
+   The document, "Rationale for the Structure and Model and Protocol for
+   the Internet Printing Protocol", describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specifications, and gives background and rationale for the
+   IETF working group's major decisions.
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 2]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   The document, "Internet Printing Protocol/1.0: Model and Semantics",
+   describes a simplified model with abstract objects, their attributes,
+   and their operations. It introduces a Printer and a Job object. The
+   Job object supports multiple documents per Job. It also addresses
+   security, internationalization, and directory issues.
+
+   The document, "Internet Printing Protocol/1.0: Encoding and
+   Transport", is a formal mapping of the abstract operations and
+   attributes defined in the model document onto HTTP/1.1. It defines
+   the encoding rules for a new Internet media type called '
+   application/ipp'.
+
+   This document "Internet Printing Protocol/1.0: Implementer's Guide",
+   gives advice to implementers of IPP clients and IPP objects.
+
+TABLE OF CONTENTS
+
+   1. Introduction.....................................................4
+   2. Terminology......................................................5
+   3. Mapping from LPD Commands to IPP Operations......................5
+   3.1 Print any waiting jobs..........................................6
+   3.2 Receive a printer job...........................................6
+   3.2.1 Abort job.....................................................7
+   3.2.2 Receive control file..........................................7
+   3.2.3 Receive data file.............................................8
+   3.3 Send queue state (short)........................................8
+   3.4 Send queue state (long)........................................10
+   3.5 Remove jobs....................................................12
+   4. Mapping of LPD Control File Lines to IPP Operation and Job
+      Template Attributes.............................................13
+   4.1 Required Job Functions.........................................13
+   4.2 Optional Job Functions.........................................14
+   4.3 Required Document Functions....................................14
+   4.4 Recommended Document Functions.................................16
+   5. Mapping from IPP operations to LPD commands.....................16
+   5.1 Print-Job......................................................16
+   5.2 Print-URI......................................................18
+   5.3 Validate-Job...................................................18
+   5.4 Create-Job.....................................................18
+   5.5 Send-Document..................................................18
+   5.6 Send-URI.......................................................18
+   5.7 Cancel-Job.....................................................18
+   5.8 Get-Printer-Attributes.........................................19
+   5.9 Get-Job-Attributes.............................................19
+   5.10 Get-Jobs......................................................20
+   6. Mapping of IPP Attributes to LPD Control File Lines.............20
+   6.1 Required Job Functions.........................................21
+   6.2 Optional Job Functions.........................................21
+
+
+
+Herriot, et al.               Experimental                      [Page 3]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   6.3 Required Document Functions....................................22
+   7. Security Considerations.........................................23
+   8. References......................................................23
+   9. Authors' Addresses..............................................24
+   10.Appendix A: ABNF Syntax for response of Send-queue-state (short)25
+   11.Appendix B: ABNF Syntax for response of Send-queue-state (long) 26
+   12.Appendix C: Unsupported LPD functions...........................27
+   13.Full Copyright Statement........................................28
+
+1. Introduction
+
+   The reader of this specification is expected to be familiar with the
+   IPP Model and Semantics specification [RFC2566], the IPP Encoding and
+   Transport [RF2565], and the Line Printer Daemon (LPD) protocol
+   specification [RFC1179] as described in RFC 1179.
+
+   RFC 1179 was written in 1990 in an attempt to document existing LPD
+   protocol implementations.  Since then, a number of undocumented
+   extensions have been made by vendors to support functionality
+   specific to their printing solutions.  All of these extensions
+   consist of additional control file commands.  This document does not
+   address any of these vendor extensions.  Rather it addresses existing
+   practice within the context of the features described by RFC 1179.
+   Deviations of existing practice from RFC 1179 are so indicated.
+
+   Other LPD control file commands in RFC 1179 are obsolete. They are
+   intended to work on "text" only formats and are inappropriate for
+   many contemporary document formats that completely specify each page.
+   This document does not address the support of these obsolete
+   features.
+
+   In the area of document formats, also known as page description
+   languages (PDL), RFC 1179 defines a fixed set with no capability for
+   extension.  Consequently, some new PDL's are not supported, and some
+   of those that are supported are sufficiently unimportant now that
+   they have not been registered for use with the Printer MIB [RFC1759]
+   and IPP [RFC2566] [RFC2565], though they could be registered if
+   desired.  See the Printer MIB specification [RFC1759] and/or the IPP
+   Model specification [RFC2566] for instructions for registration of
+   document-formats with IANA.  IANA lists the registered document-
+   formats as "printer languages".
+
+   This document addresses the protocol mapping for both directions:
+   mapping of the LPD protocol to the IPP protocol and mapping of the
+   IPP protocol to the LPD protocol. The former is called the "LPD-to-
+   IPP mapper" and the latter is called the "IPP-to-LPD mapper".
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 4]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   This document is an informational document that is not on the
+   standards track.  It is intended to help implementers of gateways
+   between IPP and LPD.  It also provides an example, which gives
+   additional insight into IPP.
+
+2. Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   RFC 1179 uses the word "command" in two contexts: for over-the-wire
+   operations and for command file functions. This document SHALL use
+   the word "command" for the former and the phrase "functions" for the
+   latter.  The syntax of the LPD commands is given using ABNF
+   [RFC2234].
+
+   The following tokens are used in order to make the syntax more
+   readable:
+
+      LF stands for %x0A (linefeed)
+      SP stands for %x20.  (space)
+      DIGIT stands for %x30-39 ("0" to "9")
+
+3. Mapping from LPD Commands to IPP Operations
+
+   This section describes the mapping from LPD commands to IPP
+   operations.  Each of the following sub-sections appear as sub-
+   sections of section 5 of RFC 1179.
+
+   The following table summarizes the IPP operation that the mapper uses
+   when it receives an LPD command. Each section below gives more
+   detail:
+
+      LPD command                IPP operation
+
+
+      print-any-waiting-jobs     ignore
+      receive-a-printer-job      Print-Job or Create-Job/Send-Document
+            send queue state       Get-Printer-Attributes and Get-Jobs
+              (short or long)
+            remove-jobs          Cancel-Job
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 5]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+3.1 Print any waiting jobs
+
+   Command syntax:
+
+     print-waiting-jobs = %x01 printer-name LF
+
+   This command causes the LPD daemon check its queue and print any
+   waiting jobs. An IPP printer handles waiting jobs without such a
+   nudge.
+
+   If the  mapper receives this LPD command, it SHALL ignore it and send
+   no IPP operation.
+
+3.2 Receive a printer job
+
+   Command syntax:
+
+     receive-job = %x02 printer-name LF
+
+   The control file and data files mentioned in the following paragraphs
+   are received via LPD sub-commands that follow this command. Their
+   mapping to IPP commands and attributes is described later in this
+   section.
+
+   The mapper maps the 'Receive a printer job' command to either:
+
+      - the Print-Job operation which includes a single data file or
+      - the Create-Job operation followed by one Send-Document operation
+        for each data file.
+
+   If the IPP printer supports both Create-Job and Send-Document, and if
+   a job consists of:
+
+      - a single data file, the mapper SHOULD use the Print-Job
+        operation, but MAY use the Create-Job and Send-Document
+        operations.
+      - more than one data file, the mapper SHALL use Create-Job
+        followed by one Send-Document for each received LPD data file.
+
+   If the IPP printer does not support both Create-Job and Send-
+   Document, and if a job consists of:
+
+      - a single data file, the mapper SHALL use the PrintJob
+        operation.
+      - more than one data file, the mapper SHALL submit each received
+        LPD data file as a separate Print-Job operation (thereby
+        converting a single LPD job into multiple IPP jobs).
+
+
+
+
+Herriot, et al.               Experimental                      [Page 6]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   If the mapper uses Create-Job and Send-Document, it MUST send the
+   Create-Job operation before it sends any Send-Document operations
+   whether the LPD control file, which supplies attributes for Create-
+   Job, arrives before or after all LPD data files.
+
+   NOTE: This specification does not specify how the mapper maps: the
+   LPD Printer-name operand to the IPP "printer-uri" operation
+   attribute.
+
+   The following three sub-sections gives further details about the
+   mapping from LPD receive-a-printer-job sub-commands.  Each of the
+   following subsections appear as sub-sections of section 6 of RFC
+   1179.
+
+3.2.1 Abort job
+
+   Sub-command syntax:
+
+      abort-job = %x1 LF
+
+   This sub-command of receive-a-printer-job is intended to abort any
+   job transfer in process.
+
+   If the mapper receives this sub-command, it SHALL cancel the job that
+   it is in the process of transmitting.
+
+   If the mapper is in the process of sending a Print-Job or Create-Job
+   operation, it terminates the job either by closing the connection, or
+   performing the Cancel-Job operation with the job-uri that it received
+   from the Print-Job or Create-Job operation.
+
+   NOTE: This sub-command is implied if at any time the connection
+   between the LPD client and server is terminated before an entire
+   print job has been transferred via an LPD Receive-a-printer-job
+   request.
+
+3.2.2 Receive control file
+
+   Sub-command syntax:
+
+   receive-control-file = %x2 number-of-bytes SP name-of-control-file LF
+   number-of-bytes = 1*DIGIT
+   name-of-control-file = "cfA" job-number client-host-name
+                          ; e.g. "cfA123woden"
+   job-number = 3DIGIT
+   client-host-name = <a host name>
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 7]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   This sub-command is roughly equivalent to the IPP Create-Job
+   operation.
+
+   The mapper SHALL use the contents of the received LPD control file to
+   create IPP operation attribute and job template attribute values to
+   transmit with the Print-Job or Create-Job operation.
+
+3.2.3 Receive data file
+
+Sub-command syntax:  %x3 number-of-bytes-in-data-file Name-of-data-file
+
+   receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
+   number-of-bytes = 1*DIGIT
+   name-of-data-file = "df" letter job-number client-host-name
+               ; e.g. "dfA123woden for the first file
+   letter = %x41-5A /  %x61-7A    ;  "A" to "Z", "a" to "z"
+                                  ;  first file is "A",
+                                  ; second "B", and  52nd file is "z"
+   job-number = 3DIGIT
+   client-host-name = <a host name>
+
+   This sub-command is roughly equivalent to the IPP Send-Document
+   operation.
+
+   The mapper SHALL use the contents of the received LPD data file as
+   the data to transmit with the IPP Print-Job or Send-Document
+   operation.
+
+   Although RFC 1179 alludes to a method for passing an unspecified
+   length data file by using an octet-count of zero, no implementations
+   support this feature. The mapper SHALL reject a job that has a value
+   of 0 in the number-of-bytes field.
+
+3.3 Send queue state (short)
+
+   Command syntax:
+
+send-queue-short  = %x03 printer-name *(SP(user-name / job-number)) LF
+
+   The mapper's response to this command includes information about the
+   printer and its jobs. RFC 1179 specifies neither the information nor
+   the format of its response. This document requires the mapper to
+   follow existing practice as specified in this document.
+
+   The mapper SHALL produce a response in the following format which
+   consists of a printer-status line optionally followed by a heading
+   line, and a list of jobs. This format is defined by examples below.
+   Appendix A contains the ABNF syntax.
+
+
+
+Herriot, et al.               Experimental                      [Page 8]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   For an printer with no jobs, the response starts in column 1 and is:
+
+      no entries
+
+   For a printer with jobs, an example of the response is:
+
+     killtree is ready and printing
+     Rank   Owner      Job          Files             Total Size
+     active fred       123          stuff             1204 bytes
+     1st    smith      124          resume, foo       34576 bytes
+     2nd    fred       125          more              99 bytes
+     3rd    mary       126          mydoc             378 bytes
+     4th    jones      127          statistics.ps     4567 bytes
+     5th    fred       128          data.txt          9 bytes
+
+   The column numbers of above headings and job entries are:
+
+     |      |          |            |                 |
+     01     08         19           35                63
+
+   The mapper SHALL produce each field above from the following IPP
+   attribute:
+
+   LPD field IPP attribute          special conversion details
+
+   printer-  printer-state and      For a printer-state of idle or
+   status    printer-state-reasons  processing, the mapper SHALL use
+                                    the formats above.  For stopped,
+                                    the mapper SHALL use printer-
+                                    state-reasons to produce an
+                                    unspecified format for the error.
+   rank      number-of-             the mapper SHALL the format above
+             intervening-jobs
+   owner     job-originating-user-  unspecified conversion; job-
+             name                   originating-user-name may be the
+                                    mapper's user-name
+   job       job-id                 the mapper shall use the job-id
+   files     document-name          the mapper shall create a comma
+                                    separated list of the document-
+                                    names and then truncate this list
+                                    to the first 24 characters
+   total-    job-k-                 the mapper shall multiple the
+   size      octets*copies*1024     value of job-k-octets by 1024 and
+                                    by the value of the "copies"
+                                    attribute.
+
+
+
+
+
+
+Herriot, et al.               Experimental                      [Page 9]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   A mapper SHOULD use the job attribute number-of-intervening-jobs
+   rather than the job's position in a list of jobs to determine 'rank'
+   because a Printer may omit jobs that it wants to keep secret. If a
+   printer doesn't support the job attribute number-of-intervening-jobs,
+   a mapper MAY use the job's position.
+
+   Note: a Printer may set the value of job-originating-user-name to the
+   authenticated user or to the value of "requesting-user-name",
+   depending on the implementation and configuration. For a gateway, the
+   authenticated user is the user-id of the gateway, but the
+   "requesting-user-name" may contain the name of the user who is the
+   gateway's client.
+
+   In order to obtain the information specified above, The LPD-to-IPP
+   mapper SHALL use the Get-Printer-Attributes operation to get
+   printer-status and SHOULD use the Get-Jobs operation to get
+   information about all of the jobs. If the LPD command contains job-
+   numbers or user-names, the mapper MAY handle the filtering of the
+   response. If the LPD command contains job-numbers but no user-names,
+   the mapper MAY use Get-Job-Attributes on each converted job-number
+   rather than Get-Jobs. If the LPD command contains a single user-name
+   but no job-numbers, the mapper MAY use Get-Jobs with the my-jobs
+   option if the server supports this option and if the server allows
+   the client to be a proxy for the LPD user.
+
+   NOTE: This specification does not define how the mapper maps the LPD
+   Printer-name operand to the IPP "printer-uri" operation attribute.
+
+3.4 Send queue state (long)
+
+   Command syntax:
+
+   send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
+
+   The mapper's response to this command includes information about the
+   printer and its jobs. RFC 1179 specifies neither the information nor
+   the format of its response. This document requires the mapper to
+   follow existing practice as specified in this document.
+
+   The mapper SHALL produce a response in the following format which
+   consists of a printer-status line optionally followed a list of jobs,
+   where each job consists of a blank line, a description line, and one
+   line for each file. The description line contains the user-name,
+   rank, job-number and host. This format is defined by examples below.
+   Appendix B contain the ABNF syntax.
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 10]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   For an printer with no jobs the response is:
+
+      no entries
+
+   For a printer with jobs, an example of the response is:
+
+      killtree is ready and printing
+
+      fred: active                        [job 123 tiger]
+              2 copies of stuff           602 bytes
+
+      smith: 1st                          [job 124 snail]
+              2 copies of resume          7088 bytes
+              2 copies of foo             10200 bytes
+
+      fred: 2nd                           [job 125 tiger]
+              more                        99 bytes
+
+      The column numbers of above headings and job entries are:
+
+      |       |                           |
+      01      09                          41
+
+   Although the format of the long form is different from the format of
+   the short form, their fields are identical except for a) the copies
+   and host fields which are only in the long form, and b) the "size"
+   field contains the single copy size of each file.  Thus the sum of
+   the file sizes in the "size" field times the value of the "copies"
+   field produces the value for the "Total Size" field in the short
+   form. For fields other than the host and copies fields, see the
+   preceding section.  For the host field see the table below.
+
+      LPD field IPP attribute        special conversion details
+
+      host                           unspecified conversion; job-
+                                     originating-host may be the
+                                     mapper's host
+      copies    copies               the mapper shall assume the
+                                     value of copies precedes the
+                                     string "copies of "; otherwise,
+                                     the value of copies is 1.
+
+   NOTE: This specification does not define how the mapper maps the LPD
+   Printer-name operand to the IPP printer-uri operation attribute.
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 11]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+3.5 Remove jobs
+
+   Command syntax:
+
+      remove-jobs = %x05 printer-name SP agent
+                          *(SP(user-name / job-number)) LF
+
+   The agent operand is the user-name of the user initiating the
+   remove-jobs command. The special user-name 'root' indicates a
+   privileged user who can remove jobs whose user-name differs from the
+   agent.
+
+   The mapper SHALL issue one Cancel-Job operation for each job
+   referenced by the remove-jobs command. Each job-number in the
+   remove-jobs command references a single job. Each user-name in the
+   remove-jobs command implicitly references all jobs owned by the
+   specified user. The active job is implicitly referenced when the
+   remove-jobs command contains neither job-numbers nor user-names. The
+   mapper MAY use Get-Jobs to determine the job-uri of implicitly
+   referenced jobs.
+
+   The mapper SHALL not use the agent name of 'root' when end-users
+   cancel their own jobs.  Violation of this rule creates a potential
+   security violation, and it may cause the printer to issue a
+   notification that misleads a user into thinking that some other
+   person canceled the job.
+
+   If the agent of a remove-jobs command for a job J is the same as the
+   user name specified with the 'P' function in the control file for job
+   J, then the mapper SHALL ensure that the initiator of the Cancel-Job
+   command for job J is the same as job-originating-user for job J.
+
+   Note: This requirement means that a mapper must be consistent in who
+   the receiver perceives as the initiator of IPP operations. The mapper
+   either acts as itself or acts on behalf of another user. The latter
+   is preferable if it is possible. This consistency is necessary
+   between Print-Job/Create-Job and Cancel-Job in order for Cancel-Job
+   to work, but it is also desirable for other operations. For example,
+   Get-Jobs may give more information about job submitted by the
+   initiator of this operation.
+
+   NOTE: This specification does not define how the mapper maps: (1) the
+   LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number
+   to the IPP "job-uri".
+
+   NOTE: This specification does not specify how the mapper maps the LPD
+   user-name to the IPP job-originating-user because the mapper may use
+   its own user-name with jobs.
+
+
+
+Herriot, et al.               Experimental                     [Page 12]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+4. Mapping of LPD Control File Lines to IPP Operation and Job Template
+   Attributes
+
+   This section describes the mapping from LPD control file lines
+   (called 'functions') to IPP operation attributes and job template
+   attributes.  The mapper receives the control file lines via the LPD
+   receive-control-file sub-command.  Each of the LPD functions appear
+   as sub-sections of section 7 of RFC 1179.
+
+   In LPD control file lines, the text operands have a maximum length of
+   31 or 99 while IPP operation attribute and job template attribute
+   values have a maximum of 255 or 1023 octets, depending on the
+   attribute syntax.  Therefore, no data is lost.
+
+   The mapper converts each supported LPD function to its corresponding
+   IPP operation or job template attribute as defined by tables in the
+   subsections that follow. These subsections group functions according
+   to whether they are:
+
+      - required with a job,
+      - optional with a job
+      - required with each document.
+
+   In the tables below, each LPD value is given a name, such as 'h'. If
+   an IPP value uses the LPD value, then the IPP value column contains
+   the LPD name, such as 'h' to denote this.  Otherwise, the IPP value
+   column specifies the literal value.
+
+4.1 Required Job Functions
+
+   The following LPD functions MUST be in a received LPD job. The mapper
+   SHALL receive each of the following LPD functions and SHALL include
+   the information as a operation or job template attribute with each
+   IPP job.  The functions SHOULD be in the order 'H', 'P' and they
+   SHOULD be the first two functions in the control file, but they MAY
+   be anywhere in the control file and in any order:
+
+   LPD function                     IPP
+   name value   description         name          value
+
+   H    h       Originating Host                  h (in security layer)
+   P    u       User identification requesting-   u (and in security
+                                    user-name     layer)
+                none                ipp-          'true'
+                                    attribute-
+                                    fidelity
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 13]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   A mapper MAY send its own host rather than the client's host, and a
+   mapper MAY send its own user-name as user identification rather than
+   the client user. But in any case, the values sent SHALL be compatible
+   with the Cancel-Job operation. The IPP operation MAY have no way to
+   specify an originating host-name.
+
+   The mapper SHALL include ipp-attribute-fidelity = true so that it
+   doesn't have to determine which attributes a printer supports.
+
+4.2 Optional Job Functions
+
+   The following LPD functions MAY be present in a received job. These
+   functions SHOULD follow the required job functions and precede the
+   document functions, but they MAY be anywhere in the control file.
+
+   If the mapper receives such an LPD function, the mapper SHALL include
+   the corresponding IPP attribute with the value converted as specified
+   in the table below.  If the mapper does not receive such an LPD
+   attribute, the mapper SHALL NOT include the corresponding IPP
+   attribute, except the 'L' LPD function whose absence has a special
+   meaning as noted in the table.
+
+   LPD function                  IPP
+   name value  description       name         value
+
+   J    j      Job name for      job-name     j
+               banner page
+   L    l      Print banner page job-sheets   'standard' if 'L' is
+                                              present
+                                              'none' if 'L' is present
+   M    m      Mail When Printed              IPP has no notification
+                                              mechanism. To support
+                                              this LPD feature, the
+                                              gateway must poll using
+                                              the Get-Job-Attributes
+                                              operation.
+
+4.3 Required Document Functions
+
+   The mapper SHALL receive one set of the required document functions
+   with each copy of a document, and SHALL include the converted
+   information as operation or job template attributes with each IPP
+   document.
+
+   If the control file contains required and recommended document
+   functions, the required functions SHOULD precede the recommended ones
+   and if the job contains multiple documents, all the functions for
+
+
+
+
+Herriot, et al.               Experimental                     [Page 14]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   each document are grouped together as shown in the example of section
+   6.3 "Required Document Functions". However, the document functions
+   MAY be in any order.
+
+   LPD function                   IPP
+   name value description         name             value
+
+   f     fff  Print formatted     document-format  'application/octet-
+              file                                 stream'
+   l     fff  Print file leaving  document-format  'application/octet-
+              control characters                   stream'
+   o     fff  Print Postscript    document-format  'application/PostScri
+              output file                          pt'
+                                  copies           see note
+
+   Note: In practice, the 'f' LPD function is often overloaded. It is
+   often used with any format of document data including PostScript and
+   PCL data.
+
+   Note: In practice, the 'l' LPD function is often used as a rough
+   equivalent to the 'f' function.
+
+   Note: When RFC 1179 was written, no implementation supported the 'o'
+   function; instead 'f' was used for PostScript. Windows NT now sends '
+   o' function for a PostScript file.
+
+   Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name
+   of the data file as transferred, e.g. "dfA123woden".
+
+   If the mapper receives any other lower case letter, the mapper SHALL
+   reject the job because the document contains a format that the mapper
+   does not support.
+
+   The mapper determines the number of copies by counting the number of
+   occurrences of each 'fff' file with one of the lower-case functions
+   above. For example, if 'f dfA123woden' occurs 4 times, then copies
+   has a value of 4. Although the LPD protocol allows the value of
+   copies to be different for each document, the commands and the
+   receiving print systems don't support this.
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 15]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+4.4 Recommended Document Functions
+
+   The mapper SHOULD receive one set of the recommended document
+   functions with each document, and SHOULD include the converted
+   information as an operation or job template attribute with each IPP
+   document. The functions SHOULD be received in the order 'U' and 'N',
+   but they MAY arrive in any order.
+
+   LPD function                       IPP
+   name  value   description          name              value
+
+   U     fff                          ignored
+   N     n       Name of source file  document-name     n
+
+   Note: the value 'fff' of the 'U' function is the name of the data
+   file as transferred, e.g. "dfA123woden".
+
+5. Mapping from IPP operations to LPD commands
+
+   If the IPP-to-LPD mapper receives an IPP operation, the following
+   table summarizes the LPD command that it uses. Each section below
+   gives the detail. Each of the following sub-sections appear as sub-
+   sections of section 3 in the document "Internet Printing
+   Protocol/1.0: Model and Semantics" [RFC2566].
+
+   IPP operation                     LPD command
+
+   Print-Job or Print-URI or         receive-a-printer-job
+   Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs
+   Validate-Job                      implemented by the mapper
+   Cancel-Job                        remove-jobs
+   Get-Printer-Attributes, Get-Job-  send queue state (short or long)
+   Attributes or Get-Jobs
+
+5.1 Print-Job
+
+   The mapper SHALL send the following commands in the order listed
+   below:
+
+      - receive-a-printer-job command
+      - both receive-control-file sub-command and receive-data-file
+        sub-command (unspecified order, see Note below)
+      - print-any-waiting-jobs command, except that if the mapper is
+        sending a sequence of receive a printer-job commands, it MAY
+        omit sending print-any-waiting-jobs after any receive a
+        printer-job command that is neither the first nor last command
+        in this sequence
+
+
+
+
+Herriot, et al.               Experimental                     [Page 16]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   Note: it is recommended that the order of the receive-control-file
+   subcommand and the receive-data-file sub-command be configurable
+   because either order fails for some print systems. Some print systems
+   assume that the control file follows all data files and start
+   printing immediately on receipt of the control file. When such a
+   print system tries to print a data file that has not arrived, it
+   produces an error.  Other print systems assume that the control file
+   arrives before the data files and start printing when the first data
+   file arrives. Such a system ignores the control information, such as
+   banner page or copies.
+
+   NOTE: This specification does not define the mapping between the IPP
+   printer-uri and the LPD printer-name.
+
+   The mapper SHALL send the IPP operation attributes and job template
+   attributes received from the operation to the LPD printer by using
+   the LPD receive-control-file sub-command. The mapper SHALL create the
+   LPD job-number for use in the control file name, but the receiving
+   printer MAY, in some circumstances, assign a different job-number to
+   the job.  The mapper SHALL create the IPP job-id and IPP job-uri
+   returned in the Print-Job response.
+
+   NOTE: This specification does not specify how the mapper determines
+   the LPD job-number, the IPP job-id or the IPP job-uri of a job that
+   it creates nor does it specify the relationship between the IPP job-
+   uri, IPP the job-id and the LPD job-number, both of which the mapper
+   creates.  However, it is likely that the mapper will use the same
+   integer value for both the LPD job-number and the IPP job-id, and
+   that the IPP Job-uri is the printer's URI with the job-id
+   concatenated on the end.
+
+   The mapper SHALL send data received in the IPP operation to the LPD
+   printer by using the LPD receive-data-file sub-command. The mapper
+   SHALL specify the exact number of bytes being transmitted in the
+   number-of-bytes field of the receive-data-file sub-command. It SHALL
+   NOT use a value of 0 in this field.
+
+   If the mapper, while it is transmitting a receive-a-printer-job
+   command or sub-command, either detects that its IPP connection has
+   closed or receives a Cancel-Job operation, the mapper SHALL terminate
+   the LPD job either with the abort sub-command or the remove-jobs
+   command.
+
+   This document does not address error code conversion.
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 17]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+5.2 Print-URI
+
+   The mapper SHALL handle this operation in the same way as a Print-Job
+   operation except that it SHALL obtain data referenced by the
+   "document-uri" operation attribute and SHALL then treat that data as
+   if it had been received via a Print-Job operation.
+
+5.3 Validate-Job
+
+   The mapper SHALL perform this operation directly. Because LPD
+   supports very few attributes, this operation doesn't have much to
+   check.
+
+5.4 Create-Job
+
+   The mapper SHALL handle this operation like Print-Job, except:
+
+      - the mapper SHALL send the control file after it has received the
+        last Send-Document or Send-URI operation because the control
+        file contains all the document-name and document-format values
+        specified in the Send-Document and Send-URI operations.
+      - the mapper SHALL perform one receive-data-file sub-command for
+        each Send-Document or Send-URI operation received and in the
+        same order received.
+      - the mapper SHALL send the control file either before all data
+        files or after all data files. (See the note in the section on
+        Print-Job about the dilemma of sending the control file either
+        before or after the data files.
+
+5.5 Send-Document
+
+   The mapper performs a receive-data-file sub-command on the received
+   data. See the preceding section 5.4 "Create-Job" for the details.
+
+5.6 Send-URI
+
+   The mapper SHALL obtain the data referenced by the "document-uri"
+   operation attribute, and SHALL then treat that data as if it had been
+   received via a Send-Document operation. See the preceding section 5.5
+   "Send-Document" for the details.
+
+5.7 Cancel-Job
+
+   The mapper SHALL perform a remove-jobs command with the following
+   operation attributes:
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 18]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+      - the printer is the one to which the job was submitted, that is
+        the IPP printer-uri is mapped to an LPD printer-name by the same
+        mechanism as for all commands
+      - the agent is the authenticated user-name of the IPP client
+      - the job-number is the job-id returned by the Print-Job command,
+        that is, the LPD job-number has the same value as the IPP job-id
+        for likely implementations
+
+5.8 Get-Printer-Attributes
+
+   LPD severely limits the set of attributes that the mapper is able to
+   return in its response for this operation. The mapper SHALL support,
+   at most, the following printer attributes:
+
+      - printer-state
+      - printer-state-reasons
+
+   The mapper uses either the long or short form of the "send queue
+   state" command.
+
+   The mapper SHALL assume that the LPD response that it receives has
+   the format and information specified in section 3.3 "Send queue state
+   (short)" and section 3.4 "Send queue state (long)".  The mapper SHALL
+   determine the value of each requested attribute by using the inverse
+   of the mapping specified in the two aforementioned sections.
+
+   Note: the mapper can determine the response from the printer-status
+   line without examining the rest of the LPD response.
+
+5.9 Get-Job-Attributes
+
+   LPD severely limits the set of attributes that the mapper is able to
+   return in its response for this operation. The mapper SHALL support,
+   at most, the following job attributes:
+
+      - number-of-intervening-jobs
+      - job-originating-user-name
+      - job-id
+      - document-name
+      - job-k-octets
+      - copies
+
+   The mapper uses either the long or short form of the "send queue
+   state" command. If it receives a request for the "job-k-octets" or
+   "copies" and supports the attribute it SHALL use the long form;
+   otherwise, it SHALL use the short form.
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 19]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   Note: the value of job-k-octets is the value in the short form
+   divided by the number of "copies" which is on the long form only. Its
+   value can also be determined by adding the "size" field values for
+   each document in the job in the long form.
+
+   The mapper SHALL assume that the LPD response that it receives has
+   the format and information specified in section 3.3 "Send queue state
+   (short)" and section 3.4 "Send queue state (long)".  The mapper SHALL
+   determine the value of each requested attribute by using the inverse
+   of the mapping specified in the two aforementioned sections.
+
+   Note: when the mapper uses the LPD short form, it can determine the
+   response from the single LPD line that pertains to the job specified
+   by the Get-Job-Attributes operation.
+
+   Note: the mapper can use its correspondence between the IPP job-id,
+   job-uri and the LPD job-number.
+
+5.10 Get-Jobs
+
+   The mapper SHALL perform this operation in the same way as Get-Job-
+   Attributes except that the mapper converts all the LPD job-lines, and
+   the IPP response contains one job object for each job-line in the LPD
+   response.
+
+6. Mapping of IPP Attributes to LPD Control File Lines
+
+   This section describes the mapping from IPP operation attributes and
+   job template attributes to LPD control file lines (called '
+   functions'). The mapper receives the IPP operation attributes and job
+   template atributes via the IPP operation.  Each of the IPP operation
+   attributes and job template attributes appear as sub-sections of
+   section 3 and 4.2 in the IPP model document [RFC2566].
+
+   In the context of LPD control file lines, the text operands have a
+   maximum length of 31 or 99 while IPP operation attributes and job
+   template attributes have a maximum of 255 or 1023 octets, depending
+   on the attribute syntax.  Therefore, there may be some data loss if
+   the IPP operation attribute and job template attribute values exceed
+   the maximum length of the LPD equivalent operands.
+
+   The mapper converts each supported IPP operation attribute and job
+   template attribute to its corresponding LPD function as defined by
+   tables in the subsections that follow. These subsections group
+   functions according to whether they are:
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 20]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+      - required with a job,
+      - optional with a job
+      - required with each document.
+
+   In the tables below, each IPP value is given a name, such as 'h'. If
+   an LPD value uses the IPP value, then the LPD value column contains
+   the IPP name, such as 'h' to denote this.  Otherwise, the LPD value
+   column specifies the literal value.
+
+6.1 Required Job Functions
+
+   The mapper SHALL include the following LPD functions with each job,
+   and they SHALL have the specified value. They SHALL be the first
+   functions in the control file and they SHALL be in the order "H" and
+   then "P".
+
+   IPP                           LPD function
+   name                  value   name  value         description
+
+   (perhaps in security  h       H     gateway host  Originating Host
+   layer)
+   requesting-user-name  u       P     u             User identification
+   and in the security
+   layer
+
+   A mapper SHALL sends its own host rather than the client's host,
+   because some LPD systems require that it be the same as the host from
+   which the remove-jobs command comes.  A mapper MAY send its own user
+   name as user identification rather than the client user. But in any
+   case, the values sent SHALL be compatible with the LPD remove-jobs
+   operation.
+
+6.2 Optional Job Functions
+
+   The mapper MAY include the following LPD functions with each job.
+   They SHALL have the specified value if they are sent. These
+   functions, if present, SHALL follow the require job functions, and
+   they SHALL precede the required document functions.
+
+   IPP attribute                      LPD function
+   name           value               name value  description
+
+   job-name       j                   J    j      Job name for banner
+                                                  page
+   job-sheets     'standard'          L    u      Print banner page
+   job-sheets     'none'                          omit 'L' function
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 21]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+   Note: 'L' has special meaning when it is omitted. If 'J' is omitted,
+   some undefined behavior occurs with respect to the banner page.
+
+6.3 Required Document Functions
+
+   The mapper SHALL include one set of the following LPD functions with
+   each document, and they SHALL have the specified values. For each
+   document, the order of the functions SHALL be 'f', 'U' and then 'N',
+   where 'f' is replicated once for each copy.
+
+   IPP attribute                      LPD function
+
+   name        value                  name value  description
+
+   document-   'application/octet-    f    fff    Print formatted file
+   format      stream' or
+               'application/PostScript'
+   copies      c                                  replicate 'f' 'c'
+                                                  times
+   none                               U    fff    Unlink data file
+   document-   n                      N    n      Name of source file
+   name
+
+   Note: the value 'fff' of the 'f' and 'U' functions is the name of the
+   data file as transferred, e.g. "dfA123woden".
+
+   Note: the mapper SHALL not send the 'o' function
+
+   ISSUE: should we register DVI, troff or ditroff?
+
+   If the mapper receives no "ipp-attribute-fidelitybest-effort" or it
+   has a value of false, then the mapper SHALL reject the job if it
+   specifies attributes or attribute values that are not among those
+   supported in the above tables.
+
+   Below is an example of the minimal control file for a job with three
+   copies of two files 'foo' and 'bar':
+
+      H tiger
+      P jones
+      f dfA123woden
+      f dfA123woden
+      f dfA123woden
+      U dfA123woden
+      N foo
+      f dfB123woden
+      f dfB123woden
+      f dfB123woden
+
+
+
+Herriot, et al.               Experimental                     [Page 22]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+      U dfB123woden
+      N bar
+
+7. Security Considerations
+
+   There are no security issues beyond those covered in the IPP Encoding
+   and Transport document [RFC2565], the IPP model document [RFC2566]
+   and the LPD document [RFC1179].
+
+8. References
+
+   [ipp-iig] Hasting, T., et al., "Internet Printing Protocol/1.0:
+             Implementer's Guide", Work in Progress.
+
+   [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J.
+             Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+   [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
+             August 1990.
+
+   [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2234] D. Crocker et al., "Augmented BNF for Syntax
+             Specifications:  ABNF", RFC 2234, November 1997.
+
+   [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
+             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+             April 1999.
+
+   [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P.
+             Powell, "Internet Printing Protocol/1.0: Model and
+             Semantics", RFC 2566, April 1999.
+
+   [RFC2567] Wright, D., "Design Goals for an Internet Printing
+             Protocol", RFC 2567, April 1999.
+
+   [RFC2568] Zilles, S., "Rationale for the Structure and Model and
+             Protocol for the Internet Printing Protocol", RFC 2568,
+             April 1999.
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 23]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+9. Authors' Addresses
+
+   Robert Herriot (Editor)
+   Xerox Corporation
+   3400 Hillview Ave., Bldg #1
+   Palo Alto, CA 94304
+
+   Phone: 650-813-7696
+   Fax:  650-813-6860
+   EMail:  rherriot@pahv.xerox.com
+
+
+   Norm Jacobs
+   Sun Microsystems Inc.
+   1430 Owl Ridge Rd.
+   Colorado Springs, CO 80919
+
+   Phone:  719-532-9927
+   Fax:    719-535-0956
+   EMail:  Norm.Jacobs@Central.sun.com
+
+
+   Thomas N. Hastings
+   Xerox Corporation
+   701 S. Aviation Blvd., ESAE-231
+   El Segundo, CA 90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Jay Martin
+   Underscore, Inc.
+   41-C Sagamore Park Road
+   Hudson, NH 03051-4915
+
+   Phone:  603-889-7000
+   Fax:  603-889-2699
+   EMail:  jkm@underscore.com
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 24]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+10. Appendix A: ABNF Syntax for response of Send-queue-state (short)
+
+   The syntax in ABNF for the response to the LPD command 'send-queue-
+   state (long)' is:
+
+    status-response = empty-queue / nonempty-queue
+    empty-queue = "no-entries" LF
+    nonempty-queue = printer-status LF heading LF *(job LF)
+    printer-status =  OK-status / error-status
+    OK-status = printer-name SP "ready and printing" LF
+    error-status = < implementation dependent status information >
+    heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files"
+                    23SP "Total Size" LF
+                       ; the column headings and their values below begin
+    at the columns
+                       ; 1, 8, 19, 35 and 63
+    job = rank *SP owner *SP job *SP files *SP total-size "bytes"
+                      ; jobs are in order of oldest to newest
+    rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
+                      ; job that is printing is "active"
+                      ; other values show position in the queue
+    owner = <user name of person who submitted the job>
+    job = 1*3DIGIT   ; job-number
+    files = <file name> *( "," <file name>) ; truncated to 24 characters
+    total-size = 1*DIGIT  ; combined size in bytes of all documents
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 25]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+11. Appendix B: ABNF Syntax for response of Send-queue-state (long)
+
+   The syntax in ABNF for the response to the LPD command 'send-queue-
+   state (long)' is:
+
+    status-response = empty-queue / nonempty-queue
+    empty-queue = "no-entries" LF
+    nonempty-queue = printer-status LF  *job
+    printer-status =  OK-status / error-status
+    OK-status = printer-name SP "ready and printing" LF
+    error-status = < implementation dependent status information >
+    job = LF line-1 LF line-2 LF
+    line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
+    line-2 =  file-name 1*SP document-size "bytes"
+          ; jobs are in order of oldest to newest
+    rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
+            ; job that is printing is "active"
+            ; other values show position in the queue
+    owner = <user name of person who submitted the job>
+    job = 1*3DIGIT
+    file-name = [ 1*DIGIT  "copies of" SP ] <file name>
+                  ; truncated to 24 characters
+    document-size = 1*DIGIT  ;size of single copy of the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 26]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+12. Appendix C: Unsupported LPD functions
+
+   The follow LPD functions have no IPP equivalent. The LPD-to-IPP
+   mapper ignores them and the IPP-to-LPD mapper does not send them.
+
+    LPD command
+    name  description
+
+    C     Class for banner page
+    I     Indent Printing
+    H     Host of client
+    M     Mail when printed
+    S     Symbolic link data
+    T     Title for pr
+    W     Width of output
+    1     troff R font
+    2     troff I font
+    3     troff B font
+    4     troff S font
+
+   The follow LPD functions specify document-formats which have no IPP
+   equivalent, unless someone registers them. The LPD-to-IPP mapper
+   rejects jobs that request such a document format, and the IPP-to-LPD
+   mapper does not send them.
+
+    LPD command
+    name   description
+
+    c      Plot CIF file
+    d      Print DVI file
+    g      Plot file
+    k      reserved for Kerberized clients and servers
+    n      Print ditroff output file
+    p      Print file with 'pr' format
+    r      File to print with FORTRAN carriage control
+    t      Print troff output file
+    v      Print raster file
+    z      reserved for future use with the Palladium
+           print system
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 27]
+
+RFC 2569         Mapping between LPD and IPP Protocols        April 1999
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.               Experimental                     [Page 28]
+
diff --git a/standards/rfc2595.txt b/standards/rfc2595.txt
new file mode 100644
index 000000000..66897cd6c
--- /dev/null
+++ b/standards/rfc2595.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 2595                                      Innosoft
+Category: Standards Track                                      June 1999
+
+
+                   Using TLS with IMAP, POP3 and ACAP
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1. Motivation
+
+   The TLS protocol (formerly known as SSL) provides a way to secure an
+   application protocol from tampering and eavesdropping.  The option of
+   using such security is desirable for IMAP, POP and ACAP due to common
+   connection eavesdropping and hijacking attacks [AUTH].  Although
+   advanced SASL authentication mechanisms can provide a lightweight
+   version of this service, TLS is complimentary to simple
+   authentication-only SASL mechanisms or deployed clear-text password
+   login commands.
+
+   Many sites have a high investment in authentication infrastructure
+   (e.g., a large database of a one-way-function applied to user
+   passwords), so a privacy layer which is not tightly bound to user
+   authentication can protect against network eavesdropping attacks
+   without requiring a new authentication infrastructure and/or forcing
+   all users to change their password.  Recognizing that such sites will
+   desire simple password authentication in combination with TLS
+   encryption, this specification defines the PLAIN SASL mechanism for
+   use with protocols which lack a simple password authentication
+   command such as ACAP and SMTP.  (Note there is a separate RFC for the
+   STARTTLS command in SMTP [SMTPTLS].)
+
+   There is a strong desire in the IETF to eliminate the transmission of
+   clear-text passwords over unencrypted channels.  While SASL can be
+   used for this purpose, TLS provides an additional tool with different
+   deployability characteristics.  A server supporting both TLS with
+
+
+
+
+Newman                      Standards Track                     [Page 1]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   simple passwords and a challenge/response SASL mechanism is likely to
+   interoperate with a wide variety of clients without resorting to
+   unencrypted clear-text passwords.
+
+   The STARTTLS command rectifies a number of the problems with using a
+   separate port for a "secure" protocol variant.  Some of these are
+   mentioned in section 7.
+
+1.1. Conventions Used in this Document
+
+   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
+   "MAY", and "OPTIONAL" in this document are to be interpreted as
+   described in "Key words for use in RFCs to Indicate Requirement
+   Levels" [KEYWORDS].
+
+   Terms related to authentication are defined in "On Internet
+   Authentication" [AUTH].
+
+   Formal syntax is defined using ABNF [ABNF].
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+2. Basic Interoperability and Security Requirements
+
+   The following requirements apply to all implementations of the
+   STARTTLS extension for IMAP, POP3 and ACAP.
+
+2.1. Cipher Suite Requirements
+
+   Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
+   suite is REQUIRED.  This is important as it assures that any two
+   compliant implementations can be configured to interoperate.
+
+   All other cipher suites are OPTIONAL.
+
+2.2. Privacy Operational Mode Security Requirements
+
+   Both clients and servers SHOULD have a privacy operational mode which
+   refuses authentication unless successful activation of an encryption
+   layer (such as that provided by TLS) occurs prior to or at the time
+   of authentication and which will terminate the connection if that
+   encryption layer is deactivated.  Implementations are encouraged to
+   have flexability with respect to the minimal encryption strength or
+   cipher suites permitted.  A minimalist approach to this
+   recommendation would be an operational mode where the
+   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to
+   permitting authentication.
+
+
+
+Newman                      Standards Track                     [Page 2]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   Clients MAY have an operational mode which uses encryption only when
+   it is advertised by the server, but authentication continues
+   regardless.  For backwards compatibility, servers SHOULD have an
+   operational mode where only the authentication mechanisms required by
+   the relevant base protocol specification are needed to successfully
+   authenticate.
+
+2.3. Clear-Text Password Requirements
+
+   Clients and servers which implement STARTTLS MUST be configurable to
+   refuse all clear-text login commands or mechanisms (including both
+   standards-track and nonstandard mechanisms) unless an encryption
+   layer of adequate strength is active.  Servers which allow
+   unencrypted clear-text logins SHOULD be configurable to refuse
+   clear-text logins both for the entire server, and on a per-user
+   basis.
+
+2.4. Server Identity Check
+
+   During the TLS negotiation, the client MUST check its understanding
+   of the server hostname against the server's identity as presented in
+   the server Certificate message, in order to prevent man-in-the-middle
+   attacks.  Matching is performed according to these rules:
+
+   - The client MUST use the server hostname it used to open the
+     connection as the value to compare against the server name as
+     expressed in the server certificate.  The client MUST NOT use any
+     form of the server hostname derived from an insecure remote source
+     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.
+
+   - If a subjectAltName extension of type dNSName is present in the
+     certificate, it SHOULD be used as the source of the server's
+     identity.
+
+   - Matching is case-insensitive.
+
+   - A "*" wildcard character MAY be used as the left-most name
+     component in the certificate.  For example, *.example.com would
+     match a.example.com, foo.example.com, etc. but would not match
+     example.com.
+
+   - If the certificate contains multiple names (e.g. more than one
+     dNSName field), then a match with any one of the fields is
+     considered acceptable.
+
+   If the match fails, the client SHOULD either ask for explicit user
+   confirmation, or terminate the connection and indicate the server's
+   identity is suspect.
+
+
+
+Newman                      Standards Track                     [Page 3]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+2.5. TLS Security Policy Check
+
+   Both the client and server MUST check the result of the STARTTLS
+   command and subsequent TLS negotiation to see whether acceptable
+   authentication or privacy was achieved.  Ignoring this step
+   completely invalidates using TLS for security.  The decision about
+   whether acceptable authentication or privacy was achieved is made
+   locally, is implementation-dependent, and is beyond the scope of this
+   document.
+
+3. IMAP STARTTLS extension
+
+   When the TLS extension is present in IMAP, "STARTTLS" is listed as a
+   capability in response to the CAPABILITY command.  This extension
+   adds a single command, "STARTTLS" to the IMAP protocol which is used
+   to begin a TLS negotiation.
+
+3.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      Once TLS has been started, the client MUST discard cached
+      information about server capabilities and SHOULD re-issue the
+      CAPABILITY command.  This is necessary to protect against
+      man-in-the-middle attacks which alter the capabilities list prior
+      to STARTTLS.  The server MAY advertise different capabilities
+      after STARTTLS.
+
+      The formal syntax for IMAP is amended as follows:
+
+
+
+
+Newman                      Standards Track                     [Page 4]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+        command_any   =/  "STARTTLS"
+
+   Example:    C: a001 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
+               S: a001 OK CAPABILITY completed
+               C: a002 STARTTLS
+               S: a002 OK Begin TLS negotiation now
+               <TLS negotiation, further commands are under TLS layer>
+               C: a003 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
+               S: a003 OK CAPABILITY completed
+               C: a004 LOGIN joe password
+               S: a004 OK LOGIN completed
+
+3.2. IMAP LOGINDISABLED capability
+
+   The current IMAP protocol specification (RFC 2060) requires the
+   implementation of the LOGIN command which uses clear-text passwords.
+   Many sites may choose to disable this command unless encryption is
+   active for security reasons.  An IMAP server MAY advertise that the
+   LOGIN command is disabled by including the LOGINDISABLED capability
+   in the capability response.  Such a server will respond with a tagged
+   "NO" response to any attempt to use the LOGIN command.
+
+   An IMAP server which implements STARTTLS MUST implement support for
+   the LOGINDISABLED capability on unencrypted connections.
+
+   An IMAP client which complies with this specification MUST NOT issue
+   the LOGIN command if this capability is present.
+
+   This capability is useful to prevent clients compliant with this
+   specification from sending an unencrypted password in an environment
+   subject to passive attacks.  It has no impact on an environment
+   subject to active attacks as a man-in-the-middle attacker can remove
+   this capability.  Therefore this does not relieve clients of the need
+   to follow the privacy mode recommendation in section 2.2.
+
+   Servers advertising this capability will fail to interoperate with
+   many existing compliant IMAP clients and will be unable to prevent
+   those clients from disclosing the user's password.
+
+4. POP3 STARTTLS extension
+
+   The POP3 STARTTLS extension adds the STLS command to POP3 servers.
+   If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
+   also be implemented to avoid the need for client probing of multiple
+   commands.  The capability name "STLS" indicates this command is
+   present and permitted in the current state.
+
+
+
+Newman                      Standards Track                     [Page 5]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+      STLS
+
+         Arguments: none
+
+         Restrictions:
+             Only permitted in AUTHORIZATION state.
+
+         Discussion:
+             A TLS negotiation begins immediately after the CRLF at the
+             end of the +OK response from the server.  A -ERR response
+             MAY result if a security layer is already active.  Once a
+             client issues a STLS command, it MUST NOT issue further
+             commands until a server response is seen and the TLS
+             negotiation is complete.
+
+             The STLS command is only permitted in AUTHORIZATION state
+             and the server remains in AUTHORIZATION state, even if
+             client credentials are supplied during the TLS negotiation.
+             The AUTH command [POP-AUTH] with the EXTERNAL mechanism
+             [SASL] MAY be used to authenticate once TLS client
+             credentials are successfully exchanged, but servers
+             supporting the STLS command are not required to support the
+             EXTERNAL mechanism.
+
+             Once TLS has been started, the client MUST discard cached
+             information about server capabilities and SHOULD re-issue
+             the CAPA command.  This is necessary to protect against
+             man-in-the-middle attacks which alter the capabilities list
+             prior to STLS.  The server MAY advertise different
+             capabilities after STLS.
+
+         Possible Responses:
+             +OK -ERR
+
+         Examples:
+             C: STLS
+             S: +OK Begin TLS negotiation
+             <TLS negotiation, further commands are under TLS layer>
+               ...
+             C: STLS
+             S: -ERR Command not permitted when TLS active
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 6]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+5. ACAP STARTTLS extension
+
+   When the TLS extension is present in ACAP, "STARTTLS" is listed as a
+   capability in the ACAP greeting.  No arguments to this capability are
+   defined at this time.  This extension adds a single command,
+   "STARTTLS" to the ACAP protocol which is used to begin a TLS
+   negotiation.
+
+5.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      After the TLS layer is established, the server MUST re-issue an
+      untagged ACAP greeting.  This is necessary to protect against
+      man-in-the-middle attacks which alter the capabilities list prior
+      to STARTTLS.  The client MUST discard cached capability
+      information and replace it with the information from the new ACAP
+      greeting.  The server MAY advertise different capabilities after
+      STARTTLS.
+
+      The formal syntax for ACAP is amended as follows:
+
+        command_any   =/  "STARTTLS"
+
+   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+               C: a002 STARTTLS
+               S: a002 OK "Begin TLS negotiation now"
+               <TLS negotiation, further commands are under TLS layer>
+               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+
+
+
+
+Newman                      Standards Track                     [Page 7]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+6. PLAIN SASL mechanism
+
+   Clear-text passwords are simple, interoperate with almost all
+   existing operating system authentication databases, and are useful
+   for a smooth transition to a more secure password-based
+   authentication mechanism.  The drawback is that they are unacceptable
+   for use over an unencrypted network connection.
+
+   This defines the "PLAIN" SASL mechanism for use with ACAP and other
+   protocols with no clear-text login command.  The PLAIN SASL mechanism
+   MUST NOT be advertised or used unless a strong encryption layer (such
+   as the provided by TLS) is active or backwards compatibility dictates
+   otherwise.
+
+   The mechanism consists of a single message from the client to the
+   server.  The client sends the authorization identity (identity to
+   login as), followed by a US-ASCII NUL character, followed by the
+   authentication identity (identity whose password will be used),
+   followed by a US-ASCII NUL character, followed by the clear-text
+   password.  The client may leave the authorization identity empty to
+   indicate that it is the same as the authentication identity.
+
+   The server will verify the authentication identity and password with
+   the system authentication database and verify that the authentication
+   credentials permit the client to login as the authorization identity.
+   If both steps succeed, the user is logged in.
+
+   The server MAY also use the password to initialize any new
+   authentication database, such as one suitable for CRAM-MD5
+   [CRAM-MD5].
+
+   Non-US-ASCII characters are permitted as long as they are represented
+   in UTF-8 [UTF-8].  Use of non-visible characters or characters which
+   a user may be unable to enter on some keyboards is discouraged.
+
+   The formal grammar for the client message using Augmented BNF [ABNF]
+   follows.
+
+   message         = [authorize-id] NUL authenticate-id NUL password
+   authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   password        = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   NUL             = %x00
+   UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
+                     UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
+   UTF8-1          = %x80-BF
+   UTF8-2          = %xC0-DF UTF8-1
+   UTF8-3          = %xE0-EF 2UTF8-1
+
+
+
+Newman                      Standards Track                     [Page 8]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   UTF8-4          = %xF0-F7 3UTF8-1
+   UTF8-5          = %xF8-FB 4UTF8-1
+   UTF8-6          = %xFC-FD 5UTF8-1
+
+   Here is an example of how this might be used to initialize a CRAM-MD5
+   authentication database for ACAP:
+
+   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+               C: a001 AUTHENTICATE "CRAM-MD5"
+               S: + "<1896.697170952@postoffice.reston.mci.net>"
+               C: "tim b913a602c7eda7a495b4e6e7334d3890"
+               S: a001 NO (TRANSITION-NEEDED)
+                  "Please change your password, or use TLS to login"
+               C: a002 STARTTLS
+               S: a002 OK "Begin TLS negotiation now"
+               <TLS negotiation, further commands are under TLS layer>
+               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+               C: a003 AUTHENTICATE "PLAIN" {21+}
+               C: <NUL>tim<NUL>tanstaaftanstaaf
+               S: a003 OK CRAM-MD5 password initialized
+
+   Note: In this example, <NUL> represents a single ASCII NUL octet.
+
+7. imaps and pop3s ports
+
+   Separate "imaps" and "pop3s" ports were registered for use with SSL.
+   Use of these ports is discouraged in favor of the STARTTLS or STLS
+   commands.
+
+   A number of problems have been observed with separate ports for
+   "secure" variants of protocols.  This is an attempt to enumerate some
+   of those problems.
+
+   - Separate ports lead to a separate URL scheme which intrudes into
+     the user interface in inappropriate ways.  For example, many web
+     pages use language like "click here if your browser supports SSL."
+     This is a decision the browser is often more capable of making than
+     the user.
+
+   - Separate ports imply a model of either "secure" or "not secure."
+     This can be misleading in a number of ways.  First, the "secure"
+     port may not in fact be acceptably secure as an export-crippled
+     cipher suite might be in use.  This can mislead users into a false
+     sense of security.  Second, the normal port might in fact be
+     secured by using a SASL mechanism which includes a security layer.
+     Thus the separate port distinction makes the complex topic of
+     security policy even more confusing.  One common result of this
+     confusion is that firewall administrators are often misled into
+
+
+
+Newman                      Standards Track                     [Page 9]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+     permitting the "secure" port and blocking the standard port.  This
+     could be a poor choice given the common use of SSL with a 40-bit
+     key encryption layer and plain-text password authentication is less
+     secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
+
+   - Use of separate ports for SSL has caused clients to implement only
+     two security policies: use SSL or don't use SSL.  The desirable
+     security policy "use TLS when available" would be cumbersome with
+     the separate port model, but is simple with STARTTLS.
+
+   - Port numbers are a limited resource.  While they are not yet in
+     short supply, it is unwise to set a precedent that could double (or
+     worse) the speed of their consumption.
+
+
+8. IANA Considerations
+
+   This constitutes registration of the "STARTTLS" and "LOGINDISABLED"
+   IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
+
+   The registration for the POP3 "STLS" capability follows:
+
+   CAPA tag:                   STLS
+   Arguments:                  none
+   Added commands:             STLS
+   Standard commands affected: May enable USER/PASS as a side-effect.
+     CAPA command SHOULD be re-issued after successful completion.
+   Announced states/Valid states: AUTHORIZATION state only.
+   Specification reference:    this memo
+
+   The registration for the ACAP "STARTTLS" capability follows:
+
+   Capability name:            STARTTLS
+   Capability keyword:         STARTTLS
+   Capability arguments:       none
+   Published Specification(s): this memo
+   Person and email address for further information:
+       see author's address section below
+
+   The registration for the PLAIN SASL mechanism follows:
+
+   SASL mechanism name:        PLAIN
+   Security Considerations:    See section 9 of this memo
+   Published specification:    this memo
+   Person & email address to contact for further information:
+       see author's address section below
+   Intended usage:             COMMON
+   Author/Change controller:   see author's address section below
+
+
+
+Newman                      Standards Track                    [Page 10]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+9. Security Considerations
+
+   TLS only provides protection for data sent over a network connection.
+   Messages transferred over IMAP or POP3 are still available to server
+   administrators and usually subject to eavesdropping, tampering and
+   forgery when transmitted through SMTP or NNTP.  TLS is no substitute
+   for an end-to-end message security mechanism using MIME security
+   multiparts [MIME-SEC].
+
+   A man-in-the-middle attacker can remove STARTTLS from the capability
+   list or generate a failure response to the STARTTLS command.  In
+   order to detect such an attack, clients SHOULD warn the user when
+   session privacy is not active and/or be configurable to refuse to
+   proceed without an acceptable level of security.
+
+   A man-in-the-middle attacker can always cause a down-negotiation to
+   the weakest authentication mechanism or cipher suite available.  For
+   this reason, implementations SHOULD be configurable to refuse weak
+   mechanisms or cipher suites.
+
+   Any protocol interactions prior to the TLS handshake are performed in
+   the clear and can be modified by a man-in-the-middle attacker.  For
+   this reason, clients MUST discard cached information about server
+   capabilities advertised prior to the start of the TLS handshake.
+
+   Clients are encouraged to clearly indicate when the level of
+   encryption active is known to be vulnerable to attack using modern
+   hardware (such as encryption keys with 56 bits of entropy or less).
+
+   The LOGINDISABLED IMAP capability (discussed in section 3.2) only
+   reduces the potential for passive attacks, it provides no protection
+   against active attacks.  The responsibility remains with the client
+   to avoid sending a password over a vulnerable channel.
+
+   The PLAIN mechanism relies on the TLS encryption layer for security.
+   When used without TLS, it is vulnerable to a common network
+   eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
+   unless a suitable TLS encryption layer is active or backwards
+   compatibility dictates otherwise.
+
+   When the PLAIN mechanism is used, the server gains the ability to
+   impersonate the user to all services with the same password
+   regardless of any encryption provided by TLS or other network privacy
+   mechanisms.  While many other authentication mechanisms have similar
+   weaknesses, stronger SASL mechanisms such as Kerberos address this
+   issue.  Clients are encouraged to have an operational mode where all
+   mechanisms which are likely to reveal the user's password to the
+   server are disabled.
+
+
+
+Newman                      Standards Track                    [Page 11]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   The security considerations for TLS apply to STARTTLS and the
+   security considerations for SASL apply to the PLAIN mechanism.
+   Additional security requirements are discussed in section 2.
+
+10. References
+
+   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
+              Configuration Access Protocol", RFC 2244, November 1997.
+
+   [AUTH]     Haller, N. and R. Atkinson, "On Internet Authentication",
+              RFC 1704, October 1994.
+
+   [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+              AUTHorize Extension for Simple Challenge/Response", RFC
+              2195, September 1997.
+
+   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 2060, December 1996.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
+              "Security Multiparts for MIME: Multipart/Signed and
+              Multipart/Encrypted", RFC 1847, October 1995.
+
+   [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
+              STD 53, RFC 1939, May 1996.
+
+   [POP3EXT]  Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
+              Mechanism", RFC 2449, November 1998.
+
+   [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+              December 1994.
+
+   [SASL]     Myers, J., "Simple Authentication and Security Layer
+              (SASL)", RFC 2222, October 1997.
+
+   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              TLS", RFC 2487, January 1999.
+
+   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+
+
+
+
+Newman                      Standards Track                    [Page 12]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 2279, January 1998.
+
+
+11. Author's Address
+
+   Chris Newman
+   Innosoft International, Inc.
+   1050 Lakes Drive
+   West Covina, CA 91790 USA
+
+   EMail: chris.newman@innosoft.com
+
+
+A. Appendix -- Compliance Checklist
+
+   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".
+
+   Rules                                                 Section
+   -----                                                 -------
+   Mandatory-to-implement Cipher Suite                      2.1
+   SHOULD have mode where encryption required               2.2
+   server SHOULD have mode where TLS not required           2.2
+   MUST be configurable to refuse all clear-text login
+     commands or mechanisms                                 2.3
+   server SHOULD be configurable to refuse clear-text
+     login commands on entire server and on per-user basis  2.3
+   client MUST check server identity                        2.4
+   client MUST use hostname used to open connection         2.4
+   client MUST NOT use hostname from insecure remote lookup 2.4
+   client SHOULD support subjectAltName of dNSName type     2.4
+   client SHOULD ask for confirmation or terminate on fail  2.4
+   MUST check result of STARTTLS for acceptable privacy     2.5
+   client MUST NOT issue commands after STARTTLS
+      until server response and negotiation done        3.1,4,5.1
+   client MUST discard cached information             3.1,4,5.1,9
+   client SHOULD re-issue CAPABILITY/CAPA command       3.1,4
+   IMAP server with STARTTLS MUST implement LOGINDISABLED   3.2
+   IMAP client MUST NOT issue LOGIN if LOGINDISABLED        3.2
+   POP server MUST implement POP3 extensions                4
+   ACAP server MUST re-issue ACAP greeting                  5.1
+
+
+
+
+Newman                      Standards Track                    [Page 13]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   client SHOULD warn when session privacy not active and/or
+     refuse to proceed without acceptable security level    9
+   SHOULD be configurable to refuse weak mechanisms or
+     cipher suites                                          9
+
+   The PLAIN mechanism is an optional part of this specification.
+   However if it is implemented the following rules apply:
+
+   Rules                                                 Section
+   -----                                                 -------
+   MUST NOT use PLAIN unless strong encryption active
+     or backwards compatibility dictates otherwise         6,9
+   MUST use UTF-8 encoding for characters in PLAIN          6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                    [Page 14]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                    [Page 15]
+
diff --git a/standards/rfc2616.txt b/standards/rfc2616.txt
new file mode 100644
index 000000000..45d7d08b8
--- /dev/null
+++ b/standards/rfc2616.txt
@@ -0,0 +1,9859 @@
+
+
+
+
+
+
+Network Working Group                                      R. Fielding
+Request for Comments: 2616                                   UC Irvine
+Obsoletes: 2068                                              J. Gettys
+Category: Standards Track                                   Compaq/W3C
+                                                              J. Mogul
+                                                                Compaq
+                                                            H. Frystyk
+                                                               W3C/MIT
+                                                           L. Masinter
+                                                                 Xerox
+                                                              P. Leach
+                                                             Microsoft
+                                                        T. Berners-Lee
+                                                               W3C/MIT
+                                                             June 1999
+
+
+                Hypertext Transfer Protocol -- HTTP/1.1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Hypertext Transfer Protocol (HTTP) is an application-level
+   protocol for distributed, collaborative, hypermedia information
+   systems. It is a generic, stateless, protocol which can be used for
+   many tasks beyond its use for hypertext, such as name servers and
+   distributed object management systems, through extension of its
+   request methods, error codes and headers [47]. A feature of HTTP is
+   the typing and negotiation of data representation, allowing systems
+   to be built independently of the data being transferred.
+
+   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", and is an update to RFC 2068 [33].
+
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 1]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+Table of Contents
+
+   1   Introduction ...................................................7
+   1.1    Purpose......................................................7
+   1.2   Requirements .................................................8
+   1.3   Terminology ..................................................8
+   1.4   Overall Operation ...........................................12
+   2   Notational Conventions and Generic Grammar ....................14
+   2.1   Augmented BNF ...............................................14
+   2.2   Basic Rules .................................................15
+   3   Protocol Parameters ...........................................17
+   3.1   HTTP Version ................................................17
+   3.2   Uniform Resource Identifiers ................................18
+   3.2.1    General Syntax ...........................................19
+   3.2.2    http URL .................................................19
+   3.2.3    URI Comparison ...........................................20
+   3.3   Date/Time Formats ...........................................20
+   3.3.1    Full Date ................................................20
+   3.3.2    Delta Seconds ............................................21
+   3.4   Character Sets ..............................................21
+   3.4.1    Missing Charset ..........................................22
+   3.5   Content Codings .............................................23
+   3.6   Transfer Codings ............................................24
+   3.6.1    Chunked Transfer Coding ..................................25
+   3.7   Media Types .................................................26
+   3.7.1    Canonicalization and Text Defaults .......................27
+   3.7.2    Multipart Types ..........................................27
+   3.8   Product Tokens ..............................................28
+   3.9   Quality Values ..............................................29
+   3.10  Language Tags ...............................................29
+   3.11  Entity Tags .................................................30
+   3.12  Range Units .................................................30
+   4   HTTP Message ..................................................31
+   4.1   Message Types ...............................................31
+   4.2   Message Headers .............................................31
+   4.3   Message Body ................................................32
+   4.4   Message Length ..............................................33
+   4.5   General Header Fields .......................................34
+   5   Request .......................................................35
+   5.1   Request-Line ................................................35
+   5.1.1    Method ...................................................36
+   5.1.2    Request-URI ..............................................36
+   5.2   The Resource Identified by a Request ........................38
+   5.3   Request Header Fields .......................................38
+   6   Response ......................................................39
+   6.1   Status-Line .................................................39
+   6.1.1    Status Code and Reason Phrase ............................39
+   6.2   Response Header Fields ......................................41
+
+
+
+Fielding, et al.            Standards Track                     [Page 2]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   7   Entity ........................................................42
+   7.1   Entity Header Fields ........................................42
+   7.2   Entity Body .................................................43
+   7.2.1    Type .....................................................43
+   7.2.2    Entity Length ............................................43
+   8   Connections ...................................................44
+   8.1   Persistent Connections ......................................44
+   8.1.1    Purpose ..................................................44
+   8.1.2    Overall Operation ........................................45
+   8.1.3    Proxy Servers ............................................46
+   8.1.4    Practical Considerations .................................46
+   8.2   Message Transmission Requirements ...........................47
+   8.2.1    Persistent Connections and Flow Control ..................47
+   8.2.2    Monitoring Connections for Error Status Messages .........48
+   8.2.3    Use of the 100 (Continue) Status .........................48
+   8.2.4    Client Behavior if Server Prematurely Closes Connection ..50
+   9   Method Definitions ............................................51
+   9.1   Safe and Idempotent Methods .................................51
+   9.1.1    Safe Methods .............................................51
+   9.1.2    Idempotent Methods .......................................51
+   9.2   OPTIONS .....................................................52
+   9.3   GET .........................................................53
+   9.4   HEAD ........................................................54
+   9.5   POST ........................................................54
+   9.6   PUT .........................................................55
+   9.7   DELETE ......................................................56
+   9.8   TRACE .......................................................56
+   9.9   CONNECT .....................................................57
+   10   Status Code Definitions ......................................57
+   10.1  Informational 1xx ...........................................57
+   10.1.1   100 Continue .............................................58
+   10.1.2   101 Switching Protocols ..................................58
+   10.2  Successful 2xx ..............................................58
+   10.2.1   200 OK ...................................................58
+   10.2.2   201 Created ..............................................59
+   10.2.3   202 Accepted .............................................59
+   10.2.4   203 Non-Authoritative Information ........................59
+   10.2.5   204 No Content ...........................................60
+   10.2.6   205 Reset Content ........................................60
+   10.2.7   206 Partial Content ......................................60
+   10.3  Redirection 3xx .............................................61
+   10.3.1   300 Multiple Choices .....................................61
+   10.3.2   301 Moved Permanently ....................................62
+   10.3.3   302 Found ................................................62
+   10.3.4   303 See Other ............................................63
+   10.3.5   304 Not Modified .........................................63
+   10.3.6   305 Use Proxy ............................................64
+   10.3.7   306 (Unused) .............................................64
+
+
+
+Fielding, et al.            Standards Track                     [Page 3]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   10.3.8   307 Temporary Redirect ...................................65
+   10.4  Client Error 4xx ............................................65
+   10.4.1    400 Bad Request .........................................65
+   10.4.2    401 Unauthorized ........................................66
+   10.4.3    402 Payment Required ....................................66
+   10.4.4    403 Forbidden ...........................................66
+   10.4.5    404 Not Found ...........................................66
+   10.4.6    405 Method Not Allowed ..................................66
+   10.4.7    406 Not Acceptable ......................................67
+   10.4.8    407 Proxy Authentication Required .......................67
+   10.4.9    408 Request Timeout .....................................67
+   10.4.10   409 Conflict ............................................67
+   10.4.11   410 Gone ................................................68
+   10.4.12   411 Length Required .....................................68
+   10.4.13   412 Precondition Failed .................................68
+   10.4.14   413 Request Entity Too Large ............................69
+   10.4.15   414 Request-URI Too Long ................................69
+   10.4.16   415 Unsupported Media Type ..............................69
+   10.4.17   416 Requested Range Not Satisfiable .....................69
+   10.4.18   417 Expectation Failed ..................................70
+   10.5  Server Error 5xx ............................................70
+   10.5.1   500 Internal Server Error ................................70
+   10.5.2   501 Not Implemented ......................................70
+   10.5.3   502 Bad Gateway ..........................................70
+   10.5.4   503 Service Unavailable ..................................70
+   10.5.5   504 Gateway Timeout ......................................71
+   10.5.6   505 HTTP Version Not Supported ...........................71
+   11   Access Authentication ........................................71
+   12   Content Negotiation ..........................................71
+   12.1  Server-driven Negotiation ...................................72
+   12.2  Agent-driven Negotiation ....................................73
+   12.3  Transparent Negotiation .....................................74
+   13   Caching in HTTP ..............................................74
+   13.1.1   Cache Correctness ........................................75
+   13.1.2   Warnings .................................................76
+   13.1.3   Cache-control Mechanisms .................................77
+   13.1.4   Explicit User Agent Warnings .............................78
+   13.1.5   Exceptions to the Rules and Warnings .....................78
+   13.1.6   Client-controlled Behavior ...............................79
+   13.2  Expiration Model ............................................79
+   13.2.1   Server-Specified Expiration ..............................79
+   13.2.2   Heuristic Expiration .....................................80
+   13.2.3   Age Calculations .........................................80
+   13.2.4   Expiration Calculations ..................................83
+   13.2.5   Disambiguating Expiration Values .........................84
+   13.2.6   Disambiguating Multiple Responses ........................84
+   13.3  Validation Model ............................................85
+   13.3.1   Last-Modified Dates ......................................86
+
+
+
+Fielding, et al.            Standards Track                     [Page 4]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   13.3.2   Entity Tag Cache Validators ..............................86
+   13.3.3   Weak and Strong Validators ...............................86
+   13.3.4   Rules for When to Use Entity Tags and Last-Modified Dates.89
+   13.3.5   Non-validating Conditionals ..............................90
+   13.4  Response Cacheability .......................................91
+   13.5  Constructing Responses From Caches ..........................92
+   13.5.1   End-to-end and Hop-by-hop Headers ........................92
+   13.5.2   Non-modifiable Headers ...................................92
+   13.5.3   Combining Headers ........................................94
+   13.5.4   Combining Byte Ranges ....................................95
+   13.6  Caching Negotiated Responses ................................95
+   13.7  Shared and Non-Shared Caches ................................96
+   13.8  Errors or Incomplete Response Cache Behavior ................97
+   13.9  Side Effects of GET and HEAD ................................97
+   13.10   Invalidation After Updates or Deletions ...................97
+   13.11   Write-Through Mandatory ...................................98
+   13.12   Cache Replacement .........................................99
+   13.13   History Lists .............................................99
+   14   Header Field Definitions ....................................100
+   14.1  Accept .....................................................100
+   14.2  Accept-Charset .............................................102
+   14.3  Accept-Encoding ............................................102
+   14.4  Accept-Language ............................................104
+   14.5  Accept-Ranges ..............................................105
+   14.6  Age ........................................................106
+   14.7  Allow ......................................................106
+   14.8  Authorization ..............................................107
+   14.9  Cache-Control ..............................................108
+   14.9.1   What is Cacheable .......................................109
+   14.9.2   What May be Stored by Caches ............................110
+   14.9.3   Modifications of the Basic Expiration Mechanism .........111
+   14.9.4   Cache Revalidation and Reload Controls ..................113
+   14.9.5   No-Transform Directive ..................................115
+   14.9.6   Cache Control Extensions ................................116
+   14.10   Connection ...............................................117
+   14.11   Content-Encoding .........................................118
+   14.12   Content-Language .........................................118
+   14.13   Content-Length ...........................................119
+   14.14   Content-Location .........................................120
+   14.15   Content-MD5 ..............................................121
+   14.16   Content-Range ............................................122
+   14.17   Content-Type .............................................124
+   14.18   Date .....................................................124
+   14.18.1   Clockless Origin Server Operation ......................125
+   14.19   ETag .....................................................126
+   14.20   Expect ...................................................126
+   14.21   Expires ..................................................127
+   14.22   From .....................................................128
+
+
+
+Fielding, et al.            Standards Track                     [Page 5]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   14.23   Host .....................................................128
+   14.24   If-Match .................................................129
+   14.25   If-Modified-Since ........................................130
+   14.26   If-None-Match ............................................132
+   14.27   If-Range .................................................133
+   14.28   If-Unmodified-Since ......................................134
+   14.29   Last-Modified ............................................134
+   14.30   Location .................................................135
+   14.31   Max-Forwards .............................................136
+   14.32   Pragma ...................................................136
+   14.33   Proxy-Authenticate .......................................137
+   14.34   Proxy-Authorization ......................................137
+   14.35   Range ....................................................138
+   14.35.1    Byte Ranges ...........................................138
+   14.35.2    Range Retrieval Requests ..............................139
+   14.36   Referer ..................................................140
+   14.37   Retry-After ..............................................141
+   14.38   Server ...................................................141
+   14.39   TE .......................................................142
+   14.40   Trailer ..................................................143
+   14.41  Transfer-Encoding..........................................143
+   14.42   Upgrade ..................................................144
+   14.43   User-Agent ...............................................145
+   14.44   Vary .....................................................145
+   14.45   Via ......................................................146
+   14.46   Warning ..................................................148
+   14.47   WWW-Authenticate .........................................150
+   15 Security Considerations .......................................150
+   15.1      Personal Information....................................151
+   15.1.1   Abuse of Server Log Information .........................151
+   15.1.2   Transfer of Sensitive Information .......................151
+   15.1.3   Encoding Sensitive Information in URI's .................152
+   15.1.4   Privacy Issues Connected to Accept Headers ..............152
+   15.2  Attacks Based On File and Path Names .......................153
+   15.3  DNS Spoofing ...............................................154
+   15.4  Location Headers and Spoofing ..............................154
+   15.5  Content-Disposition Issues .................................154
+   15.6  Authentication Credentials and Idle Clients ................155
+   15.7  Proxies and Caching ........................................155
+   15.7.1    Denial of Service Attacks on Proxies....................156
+   16   Acknowledgments .............................................156
+   17   References ..................................................158
+   18   Authors' Addresses ..........................................162
+   19   Appendices ..................................................164
+   19.1  Internet Media Type message/http and application/http ......164
+   19.2  Internet Media Type multipart/byteranges ...................165
+   19.3  Tolerant Applications ......................................166
+   19.4  Differences Between HTTP Entities and RFC 2045 Entities ....167
+
+
+
+Fielding, et al.            Standards Track                     [Page 6]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   19.4.1   MIME-Version ............................................167
+   19.4.2   Conversion to Canonical Form ............................167
+   19.4.3   Conversion of Date Formats ..............................168
+   19.4.4   Introduction of Content-Encoding ........................168
+   19.4.5   No Content-Transfer-Encoding ............................168
+   19.4.6   Introduction of Transfer-Encoding .......................169
+   19.4.7   MHTML and Line Length Limitations .......................169
+   19.5  Additional Features ........................................169
+   19.5.1   Content-Disposition .....................................170
+   19.6  Compatibility with Previous Versions .......................170
+   19.6.1   Changes from HTTP/1.0 ...................................171
+   19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
+   19.6.3   Changes from RFC 2068 ...................................172
+   20   Index .......................................................175
+   21   Full Copyright Statement ....................................176
+
+1 Introduction
+
+1.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 1945 [6], improved
+   the protocol by allowing messages to be in the format of MIME-like
+   messages, containing metainformation about the data transferred and
+   modifiers on the request/response semantics. However, HTTP/1.0 does
+   not sufficiently take into consideration the effects of hierarchical
+   proxies, caching, the need for persistent connections, or 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 includes more stringent requirements than HTTP/1.0 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 and headers that indicate the
+   purpose of a request [47]. It builds on the discipline of reference
+   provided by the Uniform Resource Identifier (URI) [3], as a location
+   (URL) [4] or name (URN) [20], for indicating the resource to which a
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 7]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   method is to be applied. Messages are passed in a format similar to
+   that used by Internet mail [9] as defined by the Multipurpose
+   Internet Mail Extensions (MIME) [7].
+
+   HTTP is also used as a generic protocol for communication between
+   user agents and proxies/gateways to other Internet systems, including
+   those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
+   and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
+   access to resources available from diverse applications.
+
+1.2 Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [34].
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the MUST or REQUIRED level requirements for the protocols it
+   implements. An implementation that satisfies all the MUST or REQUIRED
+   level and all the SHOULD level requirements for its protocols is said
+   to be "unconditionally compliant"; one that satisfies all the MUST
+   level requirements but not all the SHOULD level requirements for its
+   protocols is said to be "conditionally compliant."
+
+1.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 4 and
+      transmitted via the connection.
+
+   request
+      An HTTP request message, as defined in section 5.
+
+   response
+      An HTTP response message, as defined in section 6.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 8]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   resource
+      A network data object or service that can be identified by a URI,
+      as defined in section 3.2. Resources may be available in multiple
+      representations (e.g. multiple languages, data formats, size, and
+      resolutions) or vary in other ways.
+
+   entity
+      The 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 7.
+
+   representation
+      An entity included with a response that is subject to content
+      negotiation, as described in section 12. There may exist multiple
+      representations associated with a particular response status.
+
+   content negotiation
+      The mechanism for selecting the appropriate representation when
+      servicing a request, as described in section 12. The
+      representation of entities in any response can be negotiated
+      (including error responses).
+
+   variant
+      A resource may have one, or more than one, representation(s)
+      associated with it at any given instant. Each of these
+      representations is termed a `varriant'.  Use of the term `variant'
+      does not necessarily imply that the resource is subject to content
+      negotiation.
+
+   client
+      A 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.
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 9]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   origin server
+      The server on which a given resource resides or is to be created.
+
+   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 implement
+      both the client and server requirements of this specification. A
+      "transparent proxy" is a proxy that does not modify the request or
+      response beyond what is required for proxy authentication and
+      identification. A "non-transparent proxy" is a proxy that modifies
+      the request or response in order to provide some added service to
+      the user agent, such as group annotation services, media type
+      transformation, protocol reduction, or anonymity filtering. Except
+      where either transparent or non-transparent behavior is explicitly
+      stated, the HTTP proxy requirements apply to both types of
+      proxies.
+
+   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.
+
+   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.
+
+   cache
+      A program's local store of response messages and the subsystem
+      that controls its message storage, retrieval, and deletion. A
+      cache stores cacheable 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 is acting as a tunnel.
+
+   cacheable
+      A response is cacheable if a cache is allowed to store a copy of
+      the response message for use in answering subsequent requests. The
+      rules for determining the cacheability of HTTP responses are
+      defined in section 13. Even if a resource is cacheable, there may
+      be additional constraints on whether a cache can use the cached
+      copy for a particular request.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 10]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   first-hand
+      A response is first-hand if it comes directly and without
+      unnecessary delay from the origin server, perhaps via one or more
+      proxies. A response is also first-hand 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.
+
+   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 sent 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.
+
+   semantically transparent
+      A cache behaves in a "semantically transparent" manner, with
+      respect to a particular response, when its use affects neither the
+      requesting client nor the origin server, except to improve
+      performance. When a cache is semantically transparent, the client
+      receives exactly the same response (except for hop-by-hop headers)
+      that it would have received had its request been handled directly
+      by the origin server.
+
+   validator
+      A protocol element (e.g., an entity tag or a Last-Modified time)
+      that is used to find out whether a cache entry is an equivalent
+      copy of an entity.
+
+   upstream/downstream
+      Upstream and downstream describe the flow of a message: all
+      messages flow from upstream to downstream.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 11]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   inbound/outbound
+      Inbound and outbound refer to the request and response paths for
+      messages: "inbound" means "traveling toward the origin server",
+      and "outbound" means "traveling toward the user agent"
+
+1.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. The relationship
+   between HTTP and MIME is described in appendix 19.4.
+
+   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).
+
+          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 will pass through four separate connections.
+   This distinction is important because some HTTP communication options
+
+
+
+Fielding, et al.            Standards Track                    [Page 12]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 usefully cacheable, and some requests may
+   contain modifiers which place special requirements on cache behavior.
+   HTTP requirements for cache behavior and cacheable responses are
+   defined in section 13.
+
+   In fact, there are a wide variety of architectures and configurations
+   of caches and proxies currently being experimented with or deployed
+   across the World Wide Web. These systems include national hierarchies
+   of proxy caches to save transoceanic bandwidth, systems that
+   broadcast or multicast cache entries, organizations that distribute
+   subsets of cached data via CD-ROM, and so on. HTTP systems are used
+   in corporate intranets over high-bandwidth links, and for access via
+   PDAs with low-power radio links and intermittent connectivity. The
+   goal of HTTP/1.1 is to support the wide diversity of configurations
+   already deployed while introducing protocol constructs that meet the
+   needs of those who build web applications that require high
+   reliability and, failing that, at least reliable indications of
+   failure.
+
+   HTTP communication usually takes place over TCP/IP connections. The
+   default port is TCP 80 [19], 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 units of the protocol in question is outside the scope
+   of this specification.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 13]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   In HTTP/1.0, most implementations used a new connection for each
+   request/response exchange. In HTTP/1.1, a connection may be used for
+   one or more request/response exchanges, although connections may be
+   closed for a variety of reasons (see section 8.1).
+
+2 Notational Conventions and Generic Grammar
+
+2.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 [9]. Implementors 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. White space 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 ("|") are alternatives, e.g., "yes |
+      no" will accept yes or no.
+
+   (rule1 rule2)
+      Elements enclosed in parentheses are treated as a single element.
+      Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
+      foo elem" and "elem bar elem".
+
+   *rule
+      The character "*" preceding an element indicates repetition. The
+      full form is "<n>*<m>element" indicating at least <n> and at most
+      <m> occurrences of element. Default values are 0 and infinity so
+      that "*(element)" allows any number, including zero; "1*element"
+      requires at least one; and "1*2element" allows one or two.
+
+   [rule]
+      Square brackets enclose optional elements; "[foo bar]" is
+      equivalent to "*1(foo bar)".
+
+
+
+Fielding, et al.            Standards Track                    [Page 14]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   N rule
+      Specific repetition: "<n>(element)" is equivalent to
+      "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
+      Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
+      alphabetic characters.
+
+   #rule
+      A construct "#" is defined, similar to "*", for defining lists of
+      elements. The full form is "<n>#<m>element" indicating at least
+      <n> and at most <m> elements, each separated by one or more commas
+      (",") and OPTIONAL linear white space (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 white space (LWS) can be included
+      between any two adjacent words (token or quoted-string), and
+      between adjacent words and separators, without changing the
+      interpretation of a field. At least one delimiter (LWS and/or
+
+      separators) MUST exist between any two tokens (for the definition
+      of "token" below), since they would otherwise be interpreted as a
+      single token.
+
+2.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 ANSI X3.4-1986 [21].
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 15]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       OCTET          = <any 8-bit sequence of data>
+       CHAR           = <any US-ASCII character (octets 0 - 127)>
+       UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
+       LOALPHA        = <any US-ASCII lowercase letter "a".."z">
+       ALPHA          = UPALPHA | LOALPHA
+       DIGIT          = <any US-ASCII digit "0".."9">
+       CTL            = <any US-ASCII control character
+                        (octets 0 - 31) and DEL (127)>
+       CR             = <US-ASCII CR, carriage return (13)>
+       LF             = <US-ASCII LF, linefeed (10)>
+       SP             = <US-ASCII SP, space (32)>
+       HT             = <US-ASCII HT, horizontal-tab (9)>
+       <">            = <US-ASCII double-quote mark (34)>
+
+   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
+   protocol elements except the entity-body (see appendix 19.3 for
+   tolerant applications). The end-of-line marker within an entity-body
+   is defined by its associated media type, as described in section 3.7.
+
+       CRLF           = CR LF
+
+   HTTP/1.1 header field values can be folded onto multiple lines if the
+   continuation line begins with a space or horizontal tab. All linear
+   white space, including folding, has the same semantics as SP. A
+   recipient MAY replace any linear white space with a single SP before
+   interpreting the field value or forwarding the message downstream.
+
+       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 characters from character sets other than ISO-
+   8859-1 [22] only when encoded according to the rules of RFC 2047
+   [14].
+
+       TEXT           = <any OCTET except CTLs,
+                        but including LWS>
+
+   A CRLF is allowed in the definition of TEXT only as part of a header
+   field continuation. It is expected that the folding LWS will be
+   replaced with a single SP before interpretation of the TEXT value.
+
+   Hexadecimal numeric characters are used in several protocol elements.
+
+       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
+                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 16]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 (as defined in section
+   3.6).
+
+       token          = 1*<any CHAR except CTLs or separators>
+       separators     = "(" | ")" | "<" | ">" | "@"
+                      | "," | ";" | ":" | "\" | <">
+                      | "/" | "[" | "]" | "?" | "="
+                      | "{" | "}" | SP | HT
+
+   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 | quoted-pair | comment ) ")"
+       ctext          = <any TEXT excluding "(" and ")">
+
+   A string of text is parsed as a single word if it is quoted using
+   double-quote marks.
+
+       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
+       qdtext         = <any TEXT except <">>
+
+   The backslash character ("\") MAY be used as a single-character
+   quoting mechanism only within quoted-string and comment constructs.
+
+       quoted-pair    = "\" CHAR
+
+3 Protocol Parameters
+
+3.1 HTTP Version
+
+   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
+   of the protocol. The protocol versioning policy is intended to allow
+   the sender to indicate the format of a message and its capacity for
+   understanding further HTTP communication, rather than the features
+   obtained via that communication. No change is made to the version
+   number for the addition of message components which do not affect
+   communication behavior or which only add to extensible field values.
+   The <minor> number is incremented when the changes made to the
+   protocol add features which do not change the general message parsing
+   algorithm, but which may add to the message semantics and imply
+   additional capabilities of the sender. The <major> number is
+   incremented when the format of a message within the protocol is
+   changed. See RFC 2145 [36] for a fuller explanation.
+
+
+
+Fielding, et al.            Standards Track                    [Page 17]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The version of an HTTP message is indicated by an HTTP-Version field
+   in the first line of the message.
+
+       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
+
+   Note that the major and minor numbers MUST 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 MUST be ignored by recipients and
+   MUST NOT be sent.
+
+   An application that sends a request or response message that includes
+   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
+   with this specification. Applications that are at least conditionally
+   compliant with this specification SHOULD use an HTTP-Version of
+   "HTTP/1.1" in their messages, and MUST do so for any message that is
+   not compatible with HTTP/1.0. For more details on when to send
+   specific HTTP-Version values, see RFC 2145 [36].
+
+   The HTTP version of an application is the highest HTTP version for
+   which the application is at least conditionally compliant.
+
+   Proxy and gateway applications need to be careful when forwarding
+   messages in protocol versions different from that of the application.
+   Since the protocol version indicates the protocol capability of the
+   sender, a proxy/gateway MUST NOT send a message with a version
+   indicator which is greater than its actual version. If a higher
+   version request is received, the proxy/gateway MUST either downgrade
+   the request version, or respond with an error, or switch to tunnel
+   behavior.
+
+   Due to interoperability problems with HTTP/1.0 proxies discovered
+   since the publication of RFC 2068[33], caching proxies MUST, gateways
+   MAY, and tunnels MUST NOT upgrade the request to the highest version
+   they support. The proxy/gateway's response to that request MUST be in
+   the same major version as the request.
+
+      Note: Converting between versions of HTTP may involve modification
+      of header fields required or forbidden by the versions involved.
+
+3.2 Uniform Resource Identifiers
+
+   URIs have been known by many names: WWW addresses, Universal Document
+   Identifiers, Universal Resource Identifiers [3], and finally the
+   combination of Uniform Resource Locators (URL) [4] and Names (URN)
+   [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
+   simply formatted strings which identify--via name, location, or any
+   other characteristic--a resource.
+
+
+
+Fielding, et al.            Standards Track                    [Page 18]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+3.2.1 General Syntax
+
+   URIs in HTTP can be represented in absolute form or relative to some
+   known base URI [11], 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. For definitive information on
+   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
+   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
+   1738 [4] and RFC 1808 [11]). This specification adopts the
+   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
+   "host","abs_path", "rel_path", and "authority" from that
+   specification.
+
+   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 414 (Request-URI Too Long) status if a URI is longer
+   than the server can handle (see section 10.4.15).
+
+      Note: Servers ought to be cautious about depending on URI lengths
+      above 255 bytes, because some older client or proxy
+      implementations might not properly support these lengths.
+
+3.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 [ "?" query ]]
+
+   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 (section 5.1.2). The use of IP addresses
+   in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). 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 5.1.2). If a proxy
+   receives a host name which is not a fully qualified domain name, it
+   MAY add its domain to the host name it received. If a proxy receives
+   a fully qualified domain name, the proxy MUST NOT change the host
+   name.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 19]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+3.2.3 URI Comparison
+
+   When comparing two URIs to decide if they match or not, a client
+   SHOULD use a case-sensitive octet-by-octet comparison of the entire
+   URIs, with these exceptions:
+
+      - A port that is empty or not given is equivalent to the default
+        port for that URI-reference;
+
+        - 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 other than those in the "reserved" and "unsafe" sets (see
+   RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
+
+   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
+
+3.3 Date/Time Formats
+
+3.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 [8] (an update to
+   RFC 822 [9]). The second format is in common use, but is based on the
+   obsolete RFC 850 [12] date format and lacks a four-digit year.
+   HTTP/1.1 clients and servers that parse the date value MUST accept
+   all three formats (for compatibility with HTTP/1.0), though they MUST
+   only generate the RFC 1123 format for representing HTTP-date values
+   in header fields. See section 19.3 for further information.
+
+      Note: Recipients of date values are encouraged to be robust in
+      accepting date values that may have been sent by non-HTTP
+      applications, as is sometimes the case when retrieving or posting
+      messages via proxies/gateways to SMTP or NNTP.
+
+
+
+Fielding, et al.            Standards Track                    [Page 20]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
+   (GMT), without exception. For the purposes of HTTP, GMT is exactly
+   equal to UTC (Coordinated Universal Time). This is indicated in the
+   first two formats by the inclusion of "GMT" as the three-letter
+   abbreviation for time zone, and MUST be assumed when reading the
+   asctime format. HTTP-date is case sensitive and MUST NOT include
+   additional LWS beyond that specifically included as SP in the
+   grammar.
+
+       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.
+
+3.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.
+
+       delta-seconds  = 1*DIGIT
+
+3.4 Character Sets
+
+   HTTP uses the same definition of the term "character set" as that
+   described for MIME:
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 21]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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
+   encoding, 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
+   [19].
+
+       charset = 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 [19] MUST represent the character set defined
+   by that registry. Applications SHOULD limit their use of character
+   sets to those defined by the IANA registry.
+
+   Implementors should be aware of IETF character set requirements [38]
+   [41].
+
+3.4.1 Missing Charset
+
+   Some HTTP/1.0 software has interpreted a Content-Type header without
+   charset parameter incorrectly to mean "recipient should guess."
+   Senders wishing to defeat this behavior MAY include a charset
+   parameter even when the charset is ISO-8859-1 and SHOULD do so when
+   it is known that it will not confuse the recipient.
+
+   Unfortunately, some older HTTP/1.0 clients did not deal properly with
+   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
+   charset label provided by the sender; and those user agents that have
+   a provision to "guess" a charset MUST use the charset from the
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 22]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   content-type field if they support that charset, rather than the
+   recipient's preference, when initially displaying a document. See
+   section 3.7.1.
+
+3.5 Content Codings
+
+   Content coding values indicate an encoding transformation that has
+   been or can be applied to an entity. Content codings are primarily
+   used to allow a document to be compressed or otherwise usefully
+   transformed without losing the identity of its underlying media type
+   and without loss of information. Frequently, the entity is stored in
+   coded form, transmitted directly, and only decoded by the recipient.
+
+       content-coding   = token
+
+   All content-coding values are case-insensitive. HTTP/1.1 uses
+   content-coding values in the Accept-Encoding (section 14.3) and
+   Content-Encoding (section 14.11) 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.
+
+   The Internet Assigned Numbers Authority (IANA) acts as a registry for
+   content-coding value tokens. Initially, the registry contains the
+   following tokens:
+
+   gzip An encoding format produced by the file compression program
+        "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
+        Lempel-Ziv coding (LZ77) with a 32 bit CRC.
+
+   compress
+        The encoding format produced by the common UNIX file compression
+        program "compress". This format is an adaptive Lempel-Ziv-Welch
+        coding (LZW).
+
+        Use of program names for the identification of encoding formats
+        is not desirable and is discouraged for future encodings. Their
+        use here is representative of historical practice, not good
+        design. For compatibility with previous implementations of HTTP,
+        applications SHOULD consider "x-gzip" and "x-compress" to be
+        equivalent to "gzip" and "compress" respectively.
+
+   deflate
+        The "zlib" format defined in RFC 1950 [31] in combination with
+        the "deflate" compression mechanism described in RFC 1951 [29].
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 23]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   identity
+        The default (identity) encoding; the use of no transformation
+        whatsoever. This content-coding is used only in the Accept-
+        Encoding header, and SHOULD NOT be used in the Content-Encoding
+        header.
+
+   New content-coding value tokens SHOULD be registered; to allow
+   interoperability between clients and servers, specifications of the
+   content coding algorithms needed to implement a new value SHOULD be
+   publicly available and adequate for independent implementation, and
+   conform to the purpose of content coding defined in this section.
+
+3.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 entity.
+
+       transfer-coding         = "chunked" | transfer-extension
+       transfer-extension      = token *( ";" parameter )
+
+   Parameters are in  the form of attribute/value pairs.
+
+       parameter               = attribute "=" value
+       attribute               = token
+       value                   = token | quoted-string
+
+   All transfer-coding values are case-insensitive. HTTP/1.1 uses
+   transfer-coding values in the TE header field (section 14.39) and in
+   the Transfer-Encoding header field (section 14.41).
+
+   Whenever a transfer-coding is applied to a message-body, the set of
+   transfer-codings MUST include "chunked", unless the message is
+   terminated by closing the connection. When the "chunked" transfer-
+   coding is used, it MUST be the last transfer-coding applied to the
+   message-body. The "chunked" transfer-coding MUST NOT be applied more
+   than once to a message-body. These rules allow the recipient to
+   determine the transfer-length of the message (section 4.4).
+
+   Transfer-codings are analogous to the Content-Transfer-Encoding
+   values of MIME [7], 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 7.2.2), or the desire to
+   encrypt data over a shared transport.
+
+
+
+Fielding, et al.            Standards Track                    [Page 24]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Internet Assigned Numbers Authority (IANA) acts as a registry for
+   transfer-coding value tokens. Initially, the registry contains the
+   following tokens: "chunked" (section 3.6.1), "identity" (section
+   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
+   (section 3.5).
+
+   New transfer-coding value tokens SHOULD be registered in the same way
+   as new content-coding value tokens (section 3.5).
+
+   A server which receives 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 an HTTP/1.0
+   client.
+
+3.6.1 Chunked 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 trailer 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.
+
+       Chunked-Body   = *chunk
+                        last-chunk
+                        trailer
+                        CRLF
+
+       chunk          = chunk-size [ chunk-extension ] CRLF
+                        chunk-data CRLF
+       chunk-size     = 1*HEX
+       last-chunk     = 1*("0") [ chunk-extension ] CRLF
+
+       chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
+       chunk-ext-name = token
+       chunk-ext-val  = token | quoted-string
+       chunk-data     = chunk-size(OCTET)
+       trailer        = *(entity-header CRLF)
+
+   The chunk-size field is a string of hex digits indicating the size of
+   the chunk. The chunked encoding is ended by any chunk whose size is
+   zero, followed by the trailer, which is terminated by an empty line.
+
+   The trailer allows the sender to include additional HTTP header
+   fields at the end of the message. The Trailer header field can be
+   used to indicate which header fields are included in a trailer (see
+   section 14.40).
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 25]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A server using chunked transfer-coding in a response MUST NOT use the
+   trailer for any header fields unless at least one of the following is
+   true:
+
+   a)the request included a TE header field that indicates "trailers" is
+     acceptable in the transfer-coding of the  response, as described in
+     section 14.39; or,
+
+   b)the server is the origin server for the response, the trailer
+     fields consist entirely of optional metadata, and the recipient
+     could use the message (in a manner acceptable to the origin server)
+     without receiving this metadata.  In other words, the origin server
+     is willing to accept the possibility that the trailer fields might
+     be silently discarded along the path to the client.
+
+   This requirement prevents an interoperability failure when the
+   message is being received by an HTTP/1.1 (or later) proxy and
+   forwarded to an HTTP/1.0 recipient. It avoids a situation where
+   compliance with the protocol would have necessitated a possibly
+   infinite buffer on the proxy.
+
+   An example process for decoding a Chunked-Body is presented in
+   appendix 19.4.6.
+
+   All HTTP/1.1 applications MUST be able to receive and decode the
+   "chunked" transfer-coding, and MUST ignore chunk-extension extensions
+   they do not understand.
+
+3.7 Media Types
+
+   HTTP uses Internet Media Types [17] in the Content-Type (section
+   14.17) and Accept (section 14.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 (as defined in section 3.6).
+
+   The type, subtype, and parameter attribute names are case-
+   insensitive. Parameter values might or might not be case-sensitive,
+   depending on the semantics of the parameter name. Linear white space
+   (LWS) MUST NOT be used between the type and subtype, nor between an
+   attribute and its value. The presence or absence of a parameter might
+   be significant to the processing of a media-type, depending on its
+   definition within the media type registry.
+
+
+
+Fielding, et al.            Standards Track                    [Page 26]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Note that some older HTTP applications do not recognize media type
+   parameters. When sending data to older HTTP applications,
+   implementations SHOULD only use media type parameters when they are
+   required by that type/subtype definition.
+
+   Media-type values are registered with the Internet Assigned Number
+   Authority (IANA [19]). The media type registration process is
+   outlined in RFC 1590 [17]. Use of non-registered media types is
+   discouraged.
+
+3.7.1 Canonicalization and Text Defaults
+
+   Internet media types are registered with a canonical form. An
+   entity-body transferred via HTTP messages MUST be represented in the
+   appropriate canonical form prior to its transmission except for
+   "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. HTTP relaxes this requirement and allows the
+   transport of text media with plain CR or LF alone representing a line
+   break when 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 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-coding, 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 3.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. See
+   section 3.4.1 for compatibility problems.
+
+3.7.2 Multipart Types
+
+   MIME provides for a number of "multipart" types -- encapsulations of
+   one or more entities within a single message-body. All multipart
+   types share a common syntax, as defined in section 5.1.1 of RFC 2046
+
+
+
+Fielding, et al.            Standards Track                    [Page 27]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [40], 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 2046, the epilogue of any multipart message MUST be
+   empty; HTTP applications MUST NOT transmit the epilogue (even if the
+   original multipart contains an epilogue). These restrictions exist in
+   order to preserve the self-delimiting nature of a multipart message-
+   body, wherein the "end" of the message-body is indicated by the
+   ending multipart boundary.
+
+   In general, HTTP treats a multipart message-body no differently than
+   any other media type: strictly as payload. The one exception is the
+   "multipart/byteranges" type (appendix 19.2) when it appears in a 206
+   (Partial Content) response, which will be interpreted by some HTTP
+   caching mechanisms as described in sections 13.5.4 and 14.16. In all
+   other cases, an HTTP user agent SHOULD follow the same or similar
+   behavior as a MIME user agent would upon receipt of a multipart type.
+   The MIME header fields within each body-part of a multipart message-
+   body do not have any significance to HTTP beyond that defined by
+   their MIME semantics.
+
+   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 [15].
+
+3.8 Product Tokens
+
+   Product tokens are used to allow communicating applications to
+   identify themselves by software name and version. Most fields using
+   product tokens also allow sub-products which form a significant part
+   of the application to be listed, separated by white space. 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
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 28]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Product tokens SHOULD be short and to the point. They MUST NOT be
+   used for advertising or other non-essential information. 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).
+
+3.9 Quality Values
+
+   HTTP content negotiation (section 12) uses short "floating point"
+   numbers to indicate the relative importance ("weight") of various
+   negotiable parameters.  A weight is normalized to a real number in
+   the range 0 through 1, where 0 is the minimum and 1 the maximum
+   value. If a parameter has a quality value of 0, then content with
+   this parameter is `not acceptable' for the client. 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") ] )
+
+   "Quality values" is a misnomer, since these values merely represent
+   relative degradation in desired quality.
+
+3.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 [1]. 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
+
+   White space 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
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 29]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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.)
+
+3.11 Entity Tags
+
+   Entity tags are used for comparing two or more entities from the same
+   requested resource. HTTP/1.1 uses entity tags in the ETag (section
+   14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
+   If-Range (section 14.27) header fields. The definition of how they
+   are used and compared as cache validators is in section 13.3.3. An
+   entity tag consists of an opaque quoted string, possibly prefixed by
+   a weakness indicator.
+
+      entity-tag = [ weak ] opaque-tag
+      weak       = "W/"
+      opaque-tag = quoted-string
+
+   A "strong entity tag" MAY be shared by two entities of a resource
+   only if they are equivalent by octet equality.
+
+   A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
+   two entities of a resource only if the entities are equivalent and
+   could be substituted for each other with no significant change in
+   semantics. A weak entity tag can only be used for weak comparison.
+
+   An entity tag MUST be unique across all versions of all entities
+   associated with a particular resource. A given entity tag value MAY
+   be used for entities obtained by requests on different URIs. The use
+   of the same entity tag value in conjunction with entities obtained by
+   requests on different URIs does not imply the equivalence of those
+   entities.
+
+3.12 Range Units
+
+   HTTP/1.1 allows a client to request that only part (a range of) the
+   response entity be included within the response. HTTP/1.1 uses range
+   units in the Range (section 14.35) and Content-Range (section 14.16)
+   header fields. An entity can 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.
+
+
+
+Fielding, et al.            Standards Track                    [Page 30]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 has been designed to allow implementations of applications
+   that do not depend on knowledge of ranges.
+
+4 HTTP Message
+
+4.1 Message Types
+
+   HTTP messages consist of requests from client to server and responses
+   from server to client.
+
+       HTTP-message   = Request | Response     ; HTTP/1.1 messages
+
+   Request (section 5) and Response (section 6) messages use the generic
+   message format of RFC 822 [9] for transferring entities (the payload
+   of the message). Both types of message consist of a start-line, zero
+   or more header fields (also known as "headers"), an empty line (i.e.,
+   a line with nothing preceding the CRLF) indicating the end of the
+   header fields, and possibly a message-body.
+
+        generic-message = start-line
+                          *(message-header CRLF)
+                          CRLF
+                          [ message-body ]
+        start-line      = Request-Line | Status-Line
+
+   In the interest of robustness, servers SHOULD ignore any empty
+   line(s) received where a Request-Line is expected. In other words, if
+   the server is reading the protocol stream at the beginning of a
+   message and receives a CRLF first, it should ignore the CRLF.
+
+   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
+   after a POST request. To restate what is explicitly forbidden by the
+   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
+   extra CRLF.
+
+4.2 Message Headers
+
+   HTTP header fields, which include general-header (section 4.5),
+   request-header (section 5.3), response-header (section 6.2), and
+   entity-header (section 7.1) fields, follow the same generic format as
+   that given in Section 3.1 of RFC 822 [9]. 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. Applications ought to follow "common form", where
+   one is known or indicated, when generating HTTP constructs, since
+   there might exist some implementations that fail to accept anything
+
+
+
+Fielding, et al.            Standards Track                    [Page 31]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   beyond the common forms.
+
+       message-header = field-name ":" [ field-value ]
+       field-name     = token
+       field-value    = *( field-content | LWS )
+       field-content  = <the OCTETs making up the field-value
+                        and consisting of either *TEXT or combinations
+                        of token, separators, and quoted-string>
+
+   The field-content does not include any leading or trailing LWS:
+   linear white space occurring before the first non-whitespace
+   character of the field-value or after the last non-whitespace
+   character of the field-value. Such leading or trailing LWS MAY be
+   removed without changing the semantics of the field value. Any LWS
+   that occurs between field-content MAY be replaced with a single SP
+   before interpreting the field value or forwarding the message
+   downstream.
+
+   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 message-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. The order in which header fields with the same
+   field-name are received is therefore significant to the
+   interpretation of the combined field value, and thus a proxy MUST NOT
+   change the order of these field values when a message is forwarded.
+
+4.3 Message Body
+
+   The message-body (if any) of an HTTP message is used to carry the
+   entity-body associated with the request or response. The message-body
+   differs from the entity-body only when a transfer-coding has been
+   applied, as indicated by the Transfer-Encoding header field (section
+   14.41).
+
+       message-body = entity-body
+                    | <entity-body encoded as per Transfer-Encoding>
+
+   Transfer-Encoding MUST be used to indicate any transfer-codings
+   applied by an application to ensure safe and proper transfer of the
+   message. Transfer-Encoding is a property of the message, not of the
+
+
+
+Fielding, et al.            Standards Track                    [Page 32]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   entity, and thus MAY be added or removed by any application along the
+   request/response chain. (However, section 3.6 places restrictions on
+   when certain transfer-codings may be used.)
+
+   The rules for when a message-body is allowed in a message differ for
+   requests and responses.
+
+   The presence of a message-body in a request is signaled by the
+   inclusion of a Content-Length or Transfer-Encoding header field in
+   the request's message-headers. A message-body MUST NOT be included in
+   a request if the specification of the request method (section 5.1.1)
+   does not allow sending an entity-body in requests. A server SHOULD
+   read and forward a message-body on any request; if the request method
+   does not include defined semantics for an entity-body, then the
+   message-body SHOULD be ignored when handling the request.
+
+   For response messages, whether or not a message-body is included with
+   a message is dependent on both the request method and the response
+   status code (section 6.1.1). All responses to the HEAD request method
+   MUST NOT include a message-body, even though the presence of entity-
+   header fields might lead one to believe they do. All 1xx
+   (informational), 204 (no content), and 304 (not modified) responses
+   MUST NOT include a message-body. All other responses do include a
+   message-body, although it MAY be of zero length.
+
+4.4 Message Length
+
+   The transfer-length of a message is the length of the message-body as
+   it appears in the message; that is, after any transfer-codings have
+   been applied. When a message-body is included with a message, the
+   transfer-length of that body is determined by one of the following
+   (in order of precedence):
+
+   1.Any response message which "MUST NOT" include a message-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.
+
+   2.If a Transfer-Encoding header field (section 14.41) is present and
+     has any value other than "identity", then the transfer-length is
+     defined by use of the "chunked" transfer-coding (section 3.6),
+     unless the message is terminated by closing the connection.
+
+   3.If a Content-Length header field (section 14.13) is present, its
+     decimal value in OCTETs represents both the entity-length and the
+     transfer-length. The Content-Length header field MUST NOT be sent
+     if these two lengths are different (i.e., if a Transfer-Encoding
+
+
+
+Fielding, et al.            Standards Track                    [Page 33]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+     header field is present). If a message is received with both a
+     Transfer-Encoding header field and a Content-Length header field,
+     the latter MUST be ignored.
+
+   4.If the message uses the media type "multipart/byteranges", and the
+     ransfer-length is not otherwise specified, then this self-
+     elimiting media type defines the transfer-length. This media type
+     UST NOT be used unless the sender knows that the recipient can arse
+     it; the presence in a request of a Range header with ultiple byte-
+     range specifiers from a 1.1 client implies that the lient can parse
+     multipart/byteranges responses.
+
+       A range header might be forwarded by a 1.0 proxy that does not
+       understand multipart/byteranges; in this case the server MUST
+       delimit the message using methods defined in items 1,3 or 5 of
+       this section.
+
+   5.By the server closing the connection. (Closing the connection
+     cannot be used to indicate the end of a request body, since that
+     would leave no possibility for the server to send back a response.)
+
+   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
+   containing a message-body MUST include a valid Content-Length header
+   field unless the server is known to be HTTP/1.1 compliant. If a
+   request contains a message-body and a Content-Length is not given,
+   the server SHOULD respond with 400 (bad request) if it cannot
+   determine the length of the message, or with 411 (length required) if
+   it wishes to insist on receiving a valid Content-Length.
+
+   All HTTP/1.1 applications that receive entities MUST accept the
+   "chunked" transfer-coding (section 3.6), thus allowing this mechanism
+   to be used for messages when the message length cannot be determined
+   in advance.
+
+   Messages MUST NOT include both a Content-Length header field and a
+   non-identity transfer-coding. If the message does include a non-
+   identity transfer-coding, the Content-Length MUST be ignored.
+
+   When a Content-Length is given in a message where a message-body is
+   allowed, its field value MUST exactly match the number of OCTETs in
+   the message-body. HTTP/1.1 user agents MUST notify the user when an
+   invalid length is received and detected.
+
+4.5 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 header fields apply only to the
+
+
+
+Fielding, et al.            Standards Track                    [Page 34]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   message being transmitted.
+
+       general-header = Cache-Control            ; Section 14.9
+                      | Connection               ; Section 14.10
+                      | Date                     ; Section 14.18
+                      | Pragma                   ; Section 14.32
+                      | Trailer                  ; Section 14.40
+                      | Transfer-Encoding        ; Section 14.41
+                      | Upgrade                  ; Section 14.42
+                      | Via                      ; Section 14.45
+                      | Warning                  ; Section 14.46
+
+   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.
+
+5 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.
+
+        Request       = Request-Line              ; Section 5.1
+                        *(( general-header        ; Section 4.5
+                         | request-header         ; Section 5.3
+                         | entity-header ) CRLF)  ; Section 7.1
+                        CRLF
+                        [ message-body ]          ; Section 4.3
+
+5.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 is allowed
+   except in the final CRLF sequence.
+
+        Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 35]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+5.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 9.2
+                      | "GET"                    ; Section 9.3
+                      | "HEAD"                   ; Section 9.4
+                      | "POST"                   ; Section 9.5
+                      | "PUT"                    ; Section 9.6
+                      | "DELETE"                 ; Section 9.7
+                      | "TRACE"                  ; Section 9.8
+                      | "CONNECT"                ; Section 9.9
+                      | extension-method
+       extension-method = token
+
+   The list of methods allowed by a resource can be specified in an
+   Allow header field (section 14.7). The return code of the response
+   always notifies the client whether a method is currently allowed on a
+   resource, since the set of allowed methods can change dynamically. An
+   origin server SHOULD return the status code 405 (Method Not Allowed)
+   if the method is known by the origin server but not allowed for the
+   requested resource, and 501 (Not Implemented) if the method is
+   unrecognized or not implemented by the origin server. The methods GET
+   and HEAD MUST be supported by all general-purpose servers. 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 9.
+
+5.1.2 Request-URI
+
+   The Request-URI is a Uniform Resource Identifier (section 3.2) and
+   identifies the resource upon which to apply the request.
+
+       Request-URI    = "*" | absoluteURI | abs_path | authority
+
+   The four 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
+
+
+
+Fielding, et al.            Standards Track                    [Page 36]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 authority form is only used by the CONNECT method (section 9.9).
+
+   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 section 3.2.1, abs_path) as
+   the Request-URI, and the network location of the URI (authority) 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 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).
+
+   The Request-URI is transmitted in the format specified in section
+   3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
+   [42], the origin server MUST decode the Request-URI in order to
+   properly interpret the request. Servers SHOULD respond to invalid
+   Request-URIs with an appropriate status code.
+
+   A transparent proxy MUST NOT rewrite the "abs_path" part of the
+   received Request-URI when forwarding it to the next inbound server,
+   except as noted above to replace a null abs_path with "/".
+
+      Note: The "no rewrite" rule prevents the proxy from changing the
+      meaning of the request when the origin server is improperly using
+      a non-reserved URI character for a reserved purpose.  Implementors
+      should be aware that some pre-HTTP/1.1 proxies have been known to
+      rewrite the Request-URI.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 37]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+5.2 The Resource Identified by a Request
+
+   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 value when
+   determining the resource identified by an HTTP/1.1 request. (But see
+   section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
+
+   An origin server that does differentiate resources based on the host
+   requested (sometimes referred to as virtual hosts or vanity host
+   names) 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 part of the
+     Request-URI. Any Host header field value 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 value.
+
+   3. If the host as determined by rule 1 or 2 is not a valid host on
+     the server, the response MUST be a 400 (Bad Request) error message.
+
+   Recipients of an HTTP/1.0 request that lacks 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.
+
+5.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 to the parameters on a programming language method
+   invocation.
+
+       request-header = Accept                   ; Section 14.1
+                      | Accept-Charset           ; Section 14.2
+                      | Accept-Encoding          ; Section 14.3
+                      | Accept-Language          ; Section 14.4
+                      | Authorization            ; Section 14.8
+                      | Expect                   ; Section 14.20
+                      | From                     ; Section 14.22
+                      | Host                     ; Section 14.23
+                      | If-Match                 ; Section 14.24
+
+
+
+Fielding, et al.            Standards Track                    [Page 38]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                      | If-Modified-Since        ; Section 14.25
+                      | If-None-Match            ; Section 14.26
+                      | If-Range                 ; Section 14.27
+                      | If-Unmodified-Since      ; Section 14.28
+                      | Max-Forwards             ; Section 14.31
+                      | Proxy-Authorization      ; Section 14.34
+                      | Range                    ; Section 14.35
+                      | Referer                  ; Section 14.36
+                      | TE                       ; Section 14.39
+                      | User-Agent               ; Section 14.43
+
+   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.
+
+6 Response
+
+   After receiving and interpreting a request message, a server responds
+   with an HTTP response message.
+
+       Response      = Status-Line               ; Section 6.1
+                       *(( general-header        ; Section 4.5
+                        | response-header        ; Section 6.2
+                        | entity-header ) CRLF)  ; Section 7.1
+                       CRLF
+                       [ message-body ]          ; Section 7.2
+
+6.1 Status-Line
+
+   The first line of a 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
+
+6.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. These codes are fully
+   defined in section 10. 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 human
+   user. The client is not required to examine or display the Reason-
+   Phrase.
+
+
+
+Fielding, et al.            Standards Track                    [Page 39]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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
+   recommendations -- they MAY be replaced by local equivalents without
+   affecting the protocol.
+
+      Status-Code    =
+            "100"  ; Section 10.1.1: Continue
+          | "101"  ; Section 10.1.2: Switching Protocols
+          | "200"  ; Section 10.2.1: OK
+          | "201"  ; Section 10.2.2: Created
+          | "202"  ; Section 10.2.3: Accepted
+          | "203"  ; Section 10.2.4: Non-Authoritative Information
+          | "204"  ; Section 10.2.5: No Content
+          | "205"  ; Section 10.2.6: Reset Content
+          | "206"  ; Section 10.2.7: Partial Content
+          | "300"  ; Section 10.3.1: Multiple Choices
+          | "301"  ; Section 10.3.2: Moved Permanently
+          | "302"  ; Section 10.3.3: Found
+          | "303"  ; Section 10.3.4: See Other
+          | "304"  ; Section 10.3.5: Not Modified
+          | "305"  ; Section 10.3.6: Use Proxy
+          | "307"  ; Section 10.3.8: Temporary Redirect
+          | "400"  ; Section 10.4.1: Bad Request
+          | "401"  ; Section 10.4.2: Unauthorized
+          | "402"  ; Section 10.4.3: Payment Required
+          | "403"  ; Section 10.4.4: Forbidden
+          | "404"  ; Section 10.4.5: Not Found
+          | "405"  ; Section 10.4.6: Method Not Allowed
+          | "406"  ; Section 10.4.7: Not Acceptable
+
+
+
+Fielding, et al.            Standards Track                    [Page 40]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+          | "407"  ; Section 10.4.8: Proxy Authentication Required
+          | "408"  ; Section 10.4.9: Request Time-out
+          | "409"  ; Section 10.4.10: Conflict
+          | "410"  ; Section 10.4.11: Gone
+          | "411"  ; Section 10.4.12: Length Required
+          | "412"  ; Section 10.4.13: Precondition Failed
+          | "413"  ; Section 10.4.14: Request Entity Too Large
+          | "414"  ; Section 10.4.15: Request-URI Too Large
+          | "415"  ; Section 10.4.16: Unsupported Media Type
+          | "416"  ; Section 10.4.17: Requested range not satisfiable
+          | "417"  ; Section 10.4.18: Expectation Failed
+          | "500"  ; Section 10.5.1: Internal Server Error
+          | "501"  ; Section 10.5.2: Not Implemented
+          | "502"  ; Section 10.5.3: Bad Gateway
+          | "503"  ; Section 10.5.4: Service Unavailable
+          | "504"  ; Section 10.5.5: Gateway Time-out
+          | "505"  ; Section 10.5.6: HTTP Version not supported
+          | extension-code
+
+      extension-code = 3DIGIT
+      Reason-Phrase  = *<TEXT, excluding CR, LF>
+
+   HTTP status codes are extensible. HTTP applications are not required
+   to understand the meaning of all registered status codes, though such
+   understanding is obviously desirable. However, applications MUST
+   understand the class of any status code, as indicated by the first
+   digit, and treat any unrecognized response as being equivalent to the
+   x00 status code of that class, with the exception that an
+   unrecognized response MUST NOT be cached. For example, if an
+   unrecognized status code of 431 is received by the client, it can
+   safely assume that there was something wrong with its request and
+   treat the response as if it had received a 400 status code. In such
+   cases, user agents SHOULD present to the user the entity returned
+   with the response, since that entity is likely to include human-
+   readable information which will explain the unusual status.
+
+6.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 = Accept-Ranges           ; Section 14.5
+                       | Age                     ; Section 14.6
+                       | ETag                    ; Section 14.19
+                       | Location                ; Section 14.30
+                       | Proxy-Authenticate      ; Section 14.33
+
+
+
+Fielding, et al.            Standards Track                    [Page 41]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                       | Retry-After             ; Section 14.37
+                       | Server                  ; Section 14.38
+                       | Vary                    ; Section 14.44
+                       | WWW-Authenticate        ; Section 14.47
+
+   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.
+
+7 Entity
+
+   Request and Response messages MAY transfer an entity if not otherwise
+   restricted by the request method or response status code. An entity
+   consists of entity-header fields and an entity-body, although some
+   responses will only include the entity-headers.
+
+   In this section, both sender and recipient refer to either the client
+   or the server, depending on who sends and who receives the entity.
+
+7.1 Entity Header Fields
+
+   Entity-header fields define metainformation about the entity-body or,
+   if no body is present, about the resource identified by the request.
+   Some of this metainformation is OPTIONAL; some might be REQUIRED by
+   portions of this specification.
+
+       entity-header  = Allow                    ; Section 14.7
+                      | Content-Encoding         ; Section 14.11
+                      | Content-Language         ; Section 14.12
+                      | Content-Length           ; Section 14.13
+                      | Content-Location         ; Section 14.14
+                      | Content-MD5              ; Section 14.15
+                      | Content-Range            ; Section 14.16
+                      | Content-Type             ; Section 14.17
+                      | Expires                  ; Section 14.21
+                      | Last-Modified            ; Section 14.29
+                      | extension-header
+
+       extension-header = message-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 MUST be forwarded by
+   transparent proxies.
+
+
+
+Fielding, et al.            Standards Track                    [Page 42]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+7.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 is only present in a message when a message-body is
+   present, as described in section 4.3. The entity-body is obtained
+   from the message-body by decoding any Transfer-Encoding that might
+   have been applied to ensure safe and proper transfer of the message.
+
+7.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 and Content-
+   Encoding. These define a two-layer, ordered encoding model:
+
+       entity-body := Content-Encoding( Content-Type( data ) )
+
+   Content-Type specifies the media type of the underlying data.
+   Content-Encoding may be used to indicate any additional content
+   codings applied to the data, usually for the purpose of data
+   compression, that are a property of the requested resource. There is
+   no default encoding.
+
+   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 field, the
+   recipient MAY attempt to guess the media type via inspection of its
+   content and/or the name extension(s) of the URI used to identify the
+   resource. If the media type remains unknown, the recipient SHOULD
+   treat it as type "application/octet-stream".
+
+7.2.2 Entity Length
+
+   The entity-length of a message is the length of the message-body
+   before any transfer-codings have been applied. Section 4.4 defines
+   how the transfer-length of a message-body is determined.
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 43]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8 Connections
+
+8.1 Persistent Connections
+
+8.1.1 Purpose
+
+   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 require a client to make multiple
+   requests of the same server in a short amount of time. Analysis of
+   these performance problems and results from a prototype
+   implementation are available [26] [30]. Implementation experience and
+   measurements of actual HTTP/1.1 (RFC 2068) implementations show good
+   results [39]. Alternatives have also been explored, for example,
+   T/TCP [27].
+
+   Persistent HTTP connections have a number of advantages:
+
+      - By opening and closing fewer TCP connections, CPU time is saved
+        in routers and hosts (clients, servers, proxies, gateways,
+        tunnels, or caches), and memory used for TCP protocol control
+        blocks can be saved in hosts.
+
+      - HTTP requests and responses can be pipelined on a connection.
+        Pipelining 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.
+
+      - Latency on subsequent requests is reduced since there is no time
+        spent in TCP's connection opening handshake.
+
+      - 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.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 44]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.1.2 Overall Operation
+
+   A significant difference between HTTP/1.1 and earlier versions of
+   HTTP is that persistent connections are the default behavior of any
+   HTTP connection. That is, unless otherwise indicated, the client
+   SHOULD assume that the server will maintain a persistent connection,
+   even after error responses from the server.
+
+   Persistent connections provide a mechanism by which a client and a
+   server can signal the close of a TCP connection. This signaling takes
+   place using the Connection header field (section 14.10). Once a close
+   has been signaled, the client MUST NOT send any more requests on that
+   connection.
+
+8.1.2.1 Negotiation
+
+   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
+   maintain a persistent connection unless a Connection header including
+   the connection-token "close" was sent in the request. If the server
+   chooses to close the connection immediately after sending the
+   response, it SHOULD send a Connection header including the
+   connection-token close.
+
+   An HTTP/1.1 client MAY expect a connection to remain open, but would
+   decide to keep it open based on whether the response from a server
+   contains a Connection header with the connection-token close. In case
+   the client does not want to maintain a connection for more than that
+   request, it SHOULD send a Connection header including the
+   connection-token close.
+
+   If either the client or the server sends the close token in the
+   Connection header, that request becomes the last one for the
+   connection.
+
+   Clients and servers SHOULD NOT assume that a persistent connection is
+   maintained for HTTP versions less than 1.1 unless it is explicitly
+   signaled. See section 19.6.2 for more information on backward
+   compatibility with HTTP/1.0 clients.
+
+   In order to remain persistent, all messages on the connection MUST
+   have a self-defined message length (i.e., one not defined by closure
+   of the connection), as described in section 4.4.
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 45]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.1.2.2 Pipelining
+
+   A client that supports persistent connections MAY "pipeline" its
+   requests (i.e., send multiple requests without waiting for each
+   response). A server MUST send its responses to those requests in the
+   same order that the requests were received.
+
+   Clients which assume persistent connections and pipeline immediately
+   after connection establishment SHOULD be prepared to retry their
+   connection if the first pipelined attempt fails. If a client does
+   such a retry, it MUST NOT pipeline before it knows the connection is
+   persistent. Clients MUST also be prepared to resend their requests if
+   the server closes the connection before sending all of the
+   corresponding responses.
+
+   Clients SHOULD NOT pipeline requests using non-idempotent methods or
+   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
+   premature termination of the transport connection could lead to
+   indeterminate results. A client wishing to send a non-idempotent
+   request SHOULD wait to send that request until it has received the
+   response status for the previous request.
+
+8.1.3 Proxy Servers
+
+   It is especially important that proxies correctly implement the
+   properties of the Connection header field as specified in section
+   14.10.
+
+   The proxy server MUST signal 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 HTTP/1.1 persistent connection
+   with an HTTP/1.0 client (but see RFC 2068 [33] for information and
+   discussion of the problems with the Keep-Alive header implemented by
+   many HTTP/1.0 clients).
+
+8.1.4 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 (or existence) of
+   this time-out for either the client or the server.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 46]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 might 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 sequence of requests
+   without user interaction so long as the request sequence is
+   idempotent (see section 9.1.2). Non-idempotent methods or sequences
+   MUST NOT be automatically retried, although user agents MAY offer a
+   human operator the choice of retrying the request(s). Confirmation by
+   user-agent software with semantic understanding of the application
+   MAY substitute for user confirmation. The automatic retry SHOULD NOT
+   be repeated if the second sequence of requests 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.
+
+   Clients that use persistent connections SHOULD limit the number of
+   simultaneous connections that they maintain to a given server. A
+   single-user client SHOULD NOT maintain more than 2 connections with
+   any server or 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.
+
+8.2 Message Transmission Requirements
+
+8.2.1 Persistent Connections and Flow Control
+
+   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.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 47]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.2.2 Monitoring Connections for Error Status Messages
+
+   An HTTP/1.1 (or later) client sending a message-body 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 (section 3.6), a zero length chunk and
+   empty trailer MAY be used to prematurely mark the end of the message.
+   If the body was preceded by a Content-Length header, the client MUST
+   close the connection.
+
+8.2.3 Use of the 100 (Continue) Status
+
+   The purpose of the 100 (Continue) status (see section 10.1.1) is to
+   allow a client that is sending a request message with a request body
+   to determine if the origin server is willing to accept the request
+   (based on the request headers) before the client sends the request
+   body. In some cases, it might either be inappropriate or highly
+   inefficient for the client to send the body if the server will reject
+   the message without looking at the body.
+
+   Requirements for HTTP/1.1 clients:
+
+      - If a client will wait for a 100 (Continue) response before
+        sending the request body, it MUST send an Expect request-header
+        field (section 14.20) with the "100-continue" expectation.
+
+      - A client MUST NOT send an Expect request-header field (section
+        14.20) with the "100-continue" expectation if it does not intend
+        to send a request body.
+
+   Because of the presence of older implementations, the protocol allows
+   ambiguous situations in which a client may send "Expect: 100-
+   continue" without receiving either a 417 (Expectation Failed) status
+   or a 100 (Continue) status. Therefore, when a client sends this
+   header field to an origin server (possibly via a proxy) from which it
+   has never seen a 100 (Continue) status, the client SHOULD NOT wait
+   for an indefinite period before sending the request body.
+
+   Requirements for HTTP/1.1 origin servers:
+
+      - Upon receiving a request which includes an Expect request-header
+        field with the "100-continue" expectation, an origin server MUST
+        either respond with 100 (Continue) status and continue to read
+        from the input stream, or respond with a final status code. The
+        origin server MUST NOT wait for the request body before sending
+        the 100 (Continue) response. If it responds with a final status
+        code, it MAY close the transport connection or it MAY continue
+
+
+
+Fielding, et al.            Standards Track                    [Page 48]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+        to read and discard the rest of the request.  It MUST NOT
+        perform the requested method if it returns a final status code.
+
+      - An origin server SHOULD NOT send a 100 (Continue) response if
+        the request message does not include an Expect request-header
+        field with the "100-continue" expectation, and MUST NOT send a
+        100 (Continue) response if such a request comes from an HTTP/1.0
+        (or earlier) client. There is an exception to this rule: for
+        compatibility with RFC 2068, a server MAY send a 100 (Continue)
+        status in response to an HTTP/1.1 PUT or POST request that does
+        not include an Expect request-header field with the "100-
+        continue" expectation. This exception, the purpose of which is
+        to minimize any client processing delays associated with an
+        undeclared wait for 100 (Continue) status, applies only to
+        HTTP/1.1 requests, and not to requests with any other HTTP-
+        version value.
+
+      - An origin server MAY omit a 100 (Continue) response if it has
+        already received some or all of the request body for the
+        corresponding request.
+
+      - An origin server that sends a 100 (Continue) response MUST
+        ultimately send a final status code, once the request body is
+        received and processed, unless it terminates the transport
+        connection prematurely.
+
+      - If an origin server receives a request that does not include an
+        Expect request-header field with the "100-continue" expectation,
+        the request includes a request body, and the server responds
+        with a final status code before reading the entire request body
+        from the transport connection, then the server SHOULD NOT close
+        the transport connection until it has read the entire request,
+        or until the client closes the connection. Otherwise, the client
+        might not reliably receive the response message. However, this
+        requirement is not be construed as preventing a server from
+        defending itself against denial-of-service attacks, or from
+        badly broken client implementations.
+
+   Requirements for HTTP/1.1 proxies:
+
+      - If a proxy receives a request that includes an Expect request-
+        header field with the "100-continue" expectation, and the proxy
+        either knows that the next-hop server complies with HTTP/1.1 or
+        higher, or does not know the HTTP version of the next-hop
+        server, it MUST forward the request, including the Expect header
+        field.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 49]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - If the proxy knows that the version of the next-hop server is
+        HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
+        respond with a 417 (Expectation Failed) status.
+
+      - Proxies SHOULD maintain a cache recording the HTTP version
+        numbers received from recently-referenced next-hop servers.
+
+      - A proxy MUST NOT forward a 100 (Continue) response if the
+        request message was received from an HTTP/1.0 (or earlier)
+        client and did not include an Expect request-header field with
+        the "100-continue" expectation. This requirement overrides the
+        general rule for forwarding of 1xx responses (see section 10.1).
+
+8.2.4 Client Behavior if Server Prematurely Closes Connection
+
+   If an HTTP/1.1 client sends a request which includes a request body,
+   but which does not include an Expect request-header field with the
+   "100-continue" expectation, and if the client is not directly
+   connected to an HTTP/1.1 origin server, and if the client sees the
+   connection close before receiving any status from the server, the
+   client SHOULD retry the request.  If the client does retry this
+   request, it MAY 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
+         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 and
+         terminates the retry process.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 50]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If at any point an error status is received, the client
+
+      - SHOULD NOT continue and
+
+      - SHOULD close the connection if it has not completed sending the
+        request message.
+
+9 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 14.23) MUST accompany all
+   HTTP/1.1 requests.
+
+9.1 Safe and Idempotent Methods
+
+9.1.1 Safe Methods
+
+   Implementors 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 might 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 NOT have the significance of taking an action
+   other than retrieval. These methods ought to 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.
+
+9.1.2 Idempotent Methods
+
+   Methods can also have the property of "idempotence" in that (aside
+   from error or expiration issues) the side-effects of N > 0 identical
+   requests is the same as for a single request. The methods GET, HEAD,
+   PUT and DELETE share this property. Also, the methods OPTIONS and
+   TRACE SHOULD NOT have side effects, and so are inherently idempotent.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 51]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   However, it is possible that a sequence of several requests is non-
+   idempotent, even if all of the methods executed in that sequence are
+   idempotent. (A sequence is idempotent if a single execution of the
+   entire sequence always yields a result that is not changed by a
+   reexecution of all, or part, of that sequence.) For example, a
+   sequence is non-idempotent if its result depends on a value that is
+   later modified in the same sequence.
+
+   A sequence that never has side effects is idempotent, by definition
+   (provided that no concurrent operations are being executed on the
+   same set of resources).
+
+9.2 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.
+
+   Responses to this method are not cacheable.
+
+   If the OPTIONS request includes an entity-body (as indicated by the
+   presence of Content-Length or Transfer-Encoding), then the media type
+   MUST be indicated by a Content-Type field. Although this
+   specification does not define any use for such a body, future
+   extensions to HTTP might use the OPTIONS body to make more detailed
+   queries on the server. A server that does not support such an
+   extension MAY discard the request body.
+
+   If the Request-URI is an asterisk ("*"), the OPTIONS request is
+   intended to apply to the server in general rather than to a specific
+   resource. Since a server's communication options typically depend on
+   the resource, the "*" request is only useful as a "ping" or "no-op"
+   type of method; it does nothing beyond allowing the client to test
+   the capabilities of the server. For example, this can be used to test
+   a proxy for HTTP/1.1 compliance (or lack thereof).
+
+   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 that indicate
+   optional features implemented by the server and applicable to that
+   resource (e.g., Allow), possibly including extensions not defined by
+   this specification. The response body, if any, SHOULD also include
+   information about the communication options. The format for such a
+
+
+
+Fielding, et al.            Standards Track                    [Page 52]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   body is not defined by this specification, but might be defined by
+   future extensions to HTTP. Content negotiation MAY be used to select
+   the appropriate response format. If no response body is included, the
+   response MUST include a Content-Length field with a field-value of
+   "0".
+
+   The Max-Forwards request-header field MAY be used to target a
+   specific proxy in the request chain. When a proxy receives an OPTIONS
+   request on an absoluteURI for which request forwarding is permitted,
+   the proxy MUST check for a Max-Forwards field. If the Max-Forwards
+   field-value is zero ("0"), the proxy MUST NOT forward the message;
+   instead, the proxy SHOULD respond with its own communication options.
+   If the Max-Forwards field-value is an integer greater than zero, the
+   proxy MUST decrement the field-value when it forwards the request. If
+   no Max-Forwards field is present in the request, then the forwarded
+   request MUST NOT include a Max-Forwards field.
+
+9.3 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, If-Unmodified-Since,
+   If-Match, If-None-Match, or If-Range header field. A conditional GET
+   method requests that the entity be transferred only under the
+   circumstances described by the conditional header field(s). 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 entity be transferred, as described in section
+   14.35. 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 is cacheable if and only if it meets
+   the requirements for HTTP caching described in section 13.
+
+   See section 15.1.3 for security considerations when used for forms.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 53]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+9.4 HEAD
+
+   The HEAD method is identical to GET except that the server MUST NOT
+   return a message-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 entity implied by the
+   request 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 cacheable 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 entity (as
+   would be indicated by a change in Content-Length, Content-MD5, ETag
+   or Last-Modified), then the cache MUST treat the cache entry as
+   stale.
+
+9.5 POST
+
+   The POST method is used to request that the origin server accept the
+   entity enclosed in the request as a new subordinate of the resource
+   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.
+
+   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.
+
+
+
+Fielding, et al.            Standards Track                    [Page 54]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If a resource has been created on the origin server, the response
+   SHOULD be 201 (Created) and contain an entity which describes the
+   status of the request and refers to the new resource, and a Location
+   header (see section 14.30).
+
+   Responses to this method are not cacheable, unless the response
+   includes appropriate Cache-Control or Expires header fields. However,
+   the 303 (See Other) response can be used to direct the user agent to
+   retrieve a cacheable resource.
+
+   POST requests MUST obey the message transmission requirements set out
+   in section 8.2.
+
+   See section 15.1.3 for security considerations.
+
+9.6 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. The recipient of the entity MUST NOT ignore any Content-*
+   (e.g. Content-Range) headers that it does not understand or implement
+   and MUST return a 501 (Not Implemented) response in such cases.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries SHOULD be
+   treated as stale. Responses to this method are not cacheable.
+
+   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. That resource might 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,
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 55]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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.
+
+   A single resource MAY be identified by many different URIs. For
+   example, an article might 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 might result in
+   several other URIs being defined by the origin server.
+
+   HTTP/1.1 does not define how a PUT method affects the state of an
+   origin server.
+
+   PUT requests MUST obey the message transmission requirements set out
+   in section 8.2.
+
+   Unless otherwise specified for a particular entity-header, the
+   entity-headers in the PUT request SHOULD be applied to the resource
+   created or modified by the PUT.
+
+9.7 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 action has been enacted
+   but the response does not include an entity.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries SHOULD be
+   treated as stale. Responses to this method are not cacheable.
+
+9.8 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
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 56]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   origin server or the first proxy or gateway to receive a Max-Forwards
+   value of zero (0) in the request (see section 14.31). 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
+   information. The value of the Via header field (section 14.45) 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 the request is valid, the response SHOULD contain the entire
+   request message in the entity-body, with a Content-Type of
+   "message/http". Responses to this method MUST NOT be cached.
+
+9.9 CONNECT
+
+   This specification reserves the method name CONNECT for use with a
+   proxy that can dynamically switch to being a tunnel (e.g. SSL
+   tunneling [44]).
+
+10 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.
+
+10.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. There are no required headers for this
+   class of status code. 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.
+
+   A client MUST be prepared to accept one or more 1xx status responses
+   prior to a regular response, even if the client does not expect a 100
+   (Continue) status message. Unexpected 1xx status responses MAY be
+   ignored by a user agent.
+
+   Proxies MUST forward 1xx responses, unless the connection between the
+   proxy and its client has been closed, or unless the proxy itself
+   requested the generation of the 1xx response. (For example, if a
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 57]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   proxy adds a "Expect: 100-continue" field when it forwards a request,
+   then it need not forward the corresponding 100 (Continue)
+   response(s).)
+
+10.1.1 100 Continue
+
+   The client SHOULD 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. See
+   section 8.2.3 for detailed discussion of the use and handling of this
+   status code.
+
+10.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 14.42), 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 be switched only 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 might be advantageous when delivering resources that use
+   such features.
+
+10.2 Successful 2xx
+
+   This class of status code indicates that the client's request was
+   successfully received, understood, and accepted.
+
+10.2.1 200 OK
+
+   The request has succeeded. The information returned with the response
+   is dependent on the method used in the request, for example:
+
+   GET    an entity corresponding to the requested resource is sent in
+          the response;
+
+   HEAD   the entity-header fields corresponding to the requested
+          resource are sent in the response without any message-body;
+
+   POST   an entity describing or containing the result of the action;
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 58]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   TRACE  an entity containing the request message as received by the
+          end server.
+
+10.2.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 URI
+   for the resource given by a Location header field. The response
+   SHOULD include an entity containing a list of resource
+   characteristics and location(s) from which the user or user agent can
+   choose the one most appropriate. The entity format is specified by
+   the media type given in the Content-Type header field. The origin
+   server MUST create the resource before returning the 201 status code.
+   If the action cannot be carried out immediately, the server SHOULD
+   respond with 202 (Accepted) response instead.
+
+   A 201 response MAY contain an ETag response header field indicating
+   the current value of the entity tag for the requested variant just
+   created, see section 14.19.
+
+10.2.3 202 Accepted
+
+   The request has been accepted for processing, but the processing has
+   not been completed.  The request might or might not eventually be
+   acted upon, as it might 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.
+
+10.2.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 might 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).
+
+
+
+Fielding, et al.            Standards Track                    [Page 59]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.2.5 204 No Content
+
+   The server has fulfilled the request but does not need to return an
+   entity-body, and might want to return updated metainformation. The
+   response MAY include new or updated metainformation in the form of
+   entity-headers, which if present SHOULD be associated with the
+   requested variant.
+
+   If the client is a user agent, it SHOULD NOT change its document view
+   from that which caused the request to be sent. 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, although
+   any new or updated metainformation SHOULD be applied to the document
+   currently in the user agent's active view.
+
+   The 204 response MUST NOT include a message-body, and thus is always
+   terminated by the first empty line after the header fields.
+
+10.2.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 sent. 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 NOT include an entity.
+
+10.2.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 14.35)
+   indicating the desired range, and MAY have included an If-Range
+   header field (section 14.27) to make the request conditional.
+
+   The response MUST include the following header fields:
+
+      - Either a Content-Range header field (section 14.16) indicating
+        the range included with this response, or a multipart/byteranges
+        Content-Type including Content-Range fields for each part. If a
+        Content-Length header field is present in the response, its
+        value MUST match the actual number of OCTETs transmitted in the
+        message-body.
+
+      - Date
+
+      - ETag and/or Content-Location, if the header would have been sent
+        in a 200 response to the same request
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 60]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - Expires, Cache-Control, and/or Vary, if the field-value might
+        differ from that sent in any previous response for the same
+        variant
+
+   If the 206 response is the result of an If-Range request that used a
+   strong cache validator (see section 13.3.3), the response SHOULD NOT
+   include other entity-headers. If the response is the result of an
+   If-Range request that used a weak validator, the response MUST NOT
+   include other entity-headers; this prevents inconsistencies between
+   cached entity-bodies and updated headers. Otherwise, the response
+   MUST include all of the entity-headers that would have been returned
+   with a 200 (OK) response to the same request.
+
+   A cache MUST NOT combine a 206 response with other previously cached
+   content if the ETag or Last-Modified headers do not match exactly,
+   see 13.5.4.
+
+   A cache that does not support the Range and Content-Range headers
+   MUST NOT cache 206 (Partial) responses.
+
+10.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 client SHOULD detect infinite redirection loops, since
+   such loops generate network traffic for each redirection.
+
+      Note: previous versions of this specification recommended a
+      maximum of five redirections. Content developers should be aware
+      that there might be clients that implement such a fixed
+      limitation.
+
+10.3.1 300 Multiple Choices
+
+   The requested resource corresponds to any one of a set of
+   representations, each with its own specific location, and agent-
+   driven negotiation information (section 12) is being provided so that
+   the user (or user agent) can select a preferred representation and
+   redirect its request to that location.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of resource characteristics and location(s) from
+   which the user or user agent can choose the one most appropriate. The
+   entity format is specified by the media type given in the Content-
+   Type header field. Depending upon the format and the capabilities of
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 61]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the user agent, selection of the most appropriate choice MAY be
+   performed automatically. However, this specification does not define
+   any standard for such automatic selection.
+
+   If the server has a preferred choice of representation, it SHOULD
+   include the specific URI for that representation in the Location
+   field; user agents MAY use the Location field value for automatic
+   redirection. This response is cacheable unless indicated otherwise.
+
+10.3.2 301 Moved Permanently
+
+   The requested resource has been assigned a new permanent URI and any
+   future references to this resource SHOULD use one of the returned
+   URIs.  Clients with link editing capabilities ought to 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
+   cacheable unless indicated otherwise.
+
+   The new permanent URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity 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.
+
+10.3.3 302 Found
+
+   The requested resource resides temporarily under a different URI.
+   Since the redirection might be altered on occasion, the client SHOULD
+   continue to use the Request-URI for future requests.  This response
+   is only cacheable if indicated by a Cache-Control or Expires header
+   field.
+
+   The temporary URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 62]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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: RFC 1945 and RFC 2068 specify that the client is not allowed
+      to change the method on the redirected request.  However, most
+      existing user agent implementations treat 302 as if it were a 303
+      response, performing a GET on the Location field-value regardless
+      of the original request method. The status codes 303 and 307 have
+      been added for servers that wish to make unambiguously clear which
+      kind of reaction is expected of the client.
+
+10.3.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 URI is not a
+   substitute reference for the originally requested resource. The 303
+   response MUST NOT be cached, but the response to the second
+   (redirected) request might be cacheable.
+
+   The different URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+      Note: Many pre-HTTP/1.1 user agents do not understand the 303
+      status. When interoperability with such clients is a concern, the
+      302 status code may be used instead, since most user agents react
+      to a 302 response as described here for 303.
+
+10.3.5 304 Not Modified
+
+   If the client has performed a conditional GET request and access is
+   allowed, but the document has not been modified, the server SHOULD
+   respond with this status code. The 304 response MUST NOT contain a
+   message-body, and thus is always terminated by the first empty line
+   after the header fields.
+
+   The response MUST include the following header fields:
+
+      - Date, unless its omission is required by section 14.18.1
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 63]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If a clockless origin server obeys these rules, and proxies and
+   clients add their own Date to any response received without one (as
+   already specified by [RFC 2068], section 14.19), caches will operate
+   correctly.
+
+      - ETag and/or Content-Location, if the header would have been sent
+        in a 200 response to the same request
+
+      - Expires, Cache-Control, and/or Vary, if the field-value might
+        differ from that sent in any previous response for the same
+        variant
+
+   If the conditional GET used a strong cache validator (see section
+   13.3.3), the response SHOULD NOT include other entity-headers.
+   Otherwise (i.e., the conditional GET used a weak validator), the
+   response MUST NOT include other entity-headers; this prevents
+   inconsistencies between cached entity-bodies and updated headers.
+
+   If a 304 response indicates an entity not currently cached, then the
+   cache MUST disregard the response and repeat the request without the
+   conditional.
+
+   If a cache uses a received 304 response to update a cache entry, the
+   cache MUST update the entry to reflect any new field values given in
+   the response.
+
+10.3.6 305 Use Proxy
+
+   The requested resource MUST be accessed through the proxy given by
+   the Location field. The Location field gives the URI of the proxy.
+   The recipient is expected to repeat this single request via the
+   proxy. 305 responses MUST only be generated by origin servers.
+
+      Note: RFC 2068 was not clear that 305 was intended to redirect a
+      single request, and to be generated by origin servers only.  Not
+      observing these limitations has significant security consequences.
+
+10.3.7 306 (Unused)
+
+   The 306 status code was used in a previous version of the
+   specification, is no longer used, and the code is reserved.
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 64]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.3.8 307 Temporary Redirect
+
+   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 cacheable if indicated by a Cache-Control or Expires header
+   field.
+
+   The temporary URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s) , since many pre-HTTP/1.1 user agents do not
+   understand the 307 status. Therefore, the note SHOULD contain the
+   information necessary for a user to repeat the original request on
+   the new URI.
+
+   If the 307 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.
+
+10.4 Client Error 4xx
+
+   The 4xx class of status code is intended for cases in which the
+   client seems to have erred. 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.
+   User agents SHOULD display any included entity to the user.
+
+   If the client is sending data, a server implementation using TCP
+   SHOULD be careful to ensure that the client acknowledges receipt of
+   the packet(s) containing the response, before the server closes the
+   input connection. If the client continues sending data to the server
+   after the close, the server's TCP stack 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.
+
+10.4.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.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 65]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.2 401 Unauthorized
+
+   The request requires user authentication. The response MUST include a
+   WWW-Authenticate header field (section 14.47) containing a challenge
+   applicable to the requested resource. The client MAY repeat the
+   request with a suitable Authorization header field (section 14.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 might
+   include relevant diagnostic information. HTTP access authentication
+   is explained in "HTTP Authentication: Basic and Digest Access
+   Authentication" [43].
+
+10.4.3 402 Payment Required
+
+   This code is reserved for future use.
+
+10.4.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.  If the server does not wish to
+   make this information available to the client, the status code 404
+   (Not Found) can be used instead.
+
+10.4.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. 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.
+   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.
+
+10.4.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, et al.            Standards Track                    [Page 66]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.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.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of available entity characteristics and location(s)
+   from which the user or user agent can choose the one most
+   appropriate. The entity format is specified by the media type given
+   in the Content-Type header field. Depending upon the format and the
+   capabilities of the user agent, selection of the most appropriate
+   choice MAY be performed automatically. However, this specification
+   does not define any standard for such automatic selection.
+
+      Note: 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 could be unacceptable, a user agent SHOULD
+   temporarily stop receipt of more data and query the user for a
+   decision on further actions.
+
+10.4.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 14.33) 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 14.34). HTTP access authentication is explained
+   in "HTTP Authentication: Basic and Digest Access Authentication"
+   [43].
+
+10.4.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.
+
+10.4.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 might be able to resolve the conflict
+   and resubmit the request. The response body SHOULD include enough
+
+
+
+Fielding, et al.            Standards Track                    [Page 67]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 might not be
+   possible and is not required.
+
+   Conflicts are most likely to occur in response to a PUT request. For
+   example, if versioning were being used and the entity being PUT
+   included changes to a resource which conflict with those made by an
+   earlier (third-party) request, the server might use the 409 response
+   to indicate that it can't complete the request. In this case, the
+   response entity would likely contain a list of the differences
+   between the two versions in a format defined by the response
+   Content-Type.
+
+10.4.11 410 Gone
+
+   The requested resource is no longer available at the server and no
+   forwarding address is known. This condition is expected to be
+   considered permanent. Clients with link editing capabilities SHOULD
+   delete 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 cacheable 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.
+
+10.4.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 message-body
+   in the request message.
+
+10.4.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.
+
+
+
+Fielding, et al.            Standards Track                    [Page 68]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.14 413 Request Entity Too Large
+
+   The server is refusing to process a request because the request
+   entity is larger than the server is willing or able to process. The
+   server MAY close the connection to prevent the client from continuing
+   the request.
+
+   If the condition is temporary, the server SHOULD include a Retry-
+   After header field to indicate that it is temporary and after what
+   time the client MAY try again.
+
+10.4.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 URI "black hole" of
+   redirection (e.g., a redirected URI 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.
+
+10.4.16 415 Unsupported Media Type
+
+   The server is refusing to service the request because the entity of
+   the request is in a format not supported by the requested resource
+   for the requested method.
+
+10.4.17 416 Requested Range Not Satisfiable
+
+   A server SHOULD return a response with this status code if a request
+   included a Range request-header field (section 14.35), and none of
+   the range-specifier values in this field overlap the current extent
+   of the selected resource, and the request did not include an If-Range
+   request-header field. (For byte-ranges, this means that the first-
+   byte-pos of all of the byte-range-spec values were greater than the
+   current length of the selected resource.)
+
+   When this status code is returned for a byte-range request, the
+   response SHOULD include a Content-Range entity-header field
+   specifying the current length of the selected resource (see section
+   14.16). This response MUST NOT use the multipart/byteranges content-
+   type.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 69]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.18 417 Expectation Failed
+
+   The expectation given in an Expect request-header field (see section
+   14.20) could not be met by this server, or, if the server is a proxy,
+   the server has unambiguous evidence that the request could not be met
+   by the next-hop server.
+
+10.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. 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. User agents SHOULD display any included entity to the
+   user. These response codes are applicable to any request method.
+
+10.5.1 500 Internal Server Error
+
+   The server encountered an unexpected condition which prevented it
+   from fulfilling the request.
+
+10.5.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.
+
+10.5.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.
+
+10.5.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.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 70]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.5.5 504 Gateway Timeout
+
+   The server, while acting as a gateway or proxy, did not receive a
+   timely response from the upstream server specified by the URI (e.g.
+   HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
+   to access in attempting to complete the request.
+
+      Note: Note to implementors: some deployed proxies are known to
+      return 400 or 500 when DNS lookups time out.
+
+10.5.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
+   3.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.
+
+11 Access Authentication
+
+   HTTP provides several OPTIONAL challenge-response authentication
+   mechanisms which can be used by a server to challenge a client
+   request and by a client to provide authentication information. The
+   general framework for access authentication, and the specification of
+   "basic" and "digest" authentication, are specified in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. This
+   specification adopts the definitions of "challenge" and "credentials"
+   from that specification.
+
+12 Content Negotiation
+
+   Most HTTP responses include an entity which contains information for
+   interpretation by a human user. Naturally, it is desirable to supply
+   the user with the "best available" entity corresponding to the
+   request. Unfortunately for servers and caches, not all users have the
+   same preferences for what is "best," and not all user agents are
+   equally capable of rendering all entity types. For that reason, HTTP
+   has provisions for several mechanisms for "content negotiation" --
+   the process of selecting the best representation for a given response
+   when there are multiple representations available.
+
+      Note: This is not called "format negotiation" because the
+      alternate representations may be of the same media type, but use
+      different capabilities of that type, be in different languages,
+      etc.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 71]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Any response containing an entity-body MAY be subject to negotiation,
+   including error responses.
+
+   There are two kinds of content negotiation which are possible in
+   HTTP: server-driven and agent-driven negotiation. These two kinds of
+   negotiation are orthogonal and thus may be used separately or in
+   combination. One method of combination, referred to as transparent
+   negotiation, occurs when a cache uses the agent-driven negotiation
+   information provided by the origin server in order to provide
+   server-driven negotiation for subsequent requests.
+
+12.1 Server-driven Negotiation
+
+   If the selection of the best representation for a response is made by
+   an algorithm located at the server, it is called server-driven
+   negotiation. Selection is based on the available representations of
+   the response (the dimensions over which it can vary; e.g. language,
+   content-coding, etc.) and the contents of particular header fields in
+   the request message or on other information pertaining to the request
+   (such as the network address of the client).
+
+   Server-driven negotiation is advantageous when the algorithm for
+   selecting from among the available representations is difficult to
+   describe to the user agent, or when the server desires to send its
+   "best guess" to the client along with the first response (hoping to
+   avoid the round-trip delay of a subsequent request if the "best
+   guess" is good enough for the user). In order to improve the server's
+   guess, the user agent MAY include request header fields (Accept,
+   Accept-Language, Accept-Encoding, etc.) which describe its
+   preferences for such a response.
+
+   Server-driven negotiation has disadvantages:
+
+      1. It is impossible for the server to accurately determine what
+         might be "best" for any given user, since that would require
+         complete knowledge of both the capabilities of the user agent
+         and the intended use for the response (e.g., does the user want
+         to view it on screen or print it on paper?).
+
+      2. Having the user agent describe its capabilities in every
+         request can be both very inefficient (given that only a small
+         percentage of responses have multiple representations) and a
+         potential violation of the user's privacy.
+
+      3. It complicates the implementation of an origin server and the
+         algorithms for generating responses to a request.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 72]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      4. It may limit a public cache's ability to use the same response
+         for multiple user's requests.
+
+   HTTP/1.1 includes the following request-header fields for enabling
+   server-driven negotiation through description of user agent
+   capabilities and user preferences: Accept (section 14.1), Accept-
+   Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
+   Language (section 14.4), and User-Agent (section 14.43). However, an
+   origin server is not limited to these dimensions and MAY vary the
+   response based on any aspect of the request, including information
+   outside the request-header fields or within extension header fields
+   not defined by this specification.
+
+   The Vary  header field can be used to express the parameters the
+   server uses to select a representation that is subject to server-
+   driven negotiation. See section 13.6 for use of the Vary header field
+   by caches and section 14.44 for use of the Vary header field by
+   servers.
+
+12.2 Agent-driven Negotiation
+
+   With agent-driven negotiation, selection of the best representation
+   for a response is performed by the user agent after receiving an
+   initial response from the origin server. Selection is based on a list
+   of the available representations of the response included within the
+   header fields or entity-body of the initial response, with each
+   representation identified by its own URI. Selection from among the
+   representations may be performed automatically (if the user agent is
+   capable of doing so) or manually by the user selecting from a
+   generated (possibly hypertext) menu.
+
+   Agent-driven negotiation is advantageous when the response would vary
+   over commonly-used dimensions (such as type, language, or encoding),
+   when the origin server is unable to determine a user agent's
+   capabilities from examining the request, and generally when public
+   caches are used to distribute server load and reduce network usage.
+
+   Agent-driven negotiation suffers from the disadvantage of needing a
+   second request to obtain the best alternate representation. This
+   second request is only efficient when caching is used. In addition,
+   this specification does not define any mechanism for supporting
+   automatic selection, though it also does not prevent any such
+   mechanism from being developed as an extension and used within
+   HTTP/1.1.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 73]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
+   status codes for enabling agent-driven negotiation when the server is
+   unwilling or unable to provide a varying response using server-driven
+   negotiation.
+
+12.3 Transparent Negotiation
+
+   Transparent negotiation is a combination of both server-driven and
+   agent-driven negotiation. When a cache is supplied with a form of the
+   list of available representations of the response (as in agent-driven
+   negotiation) and the dimensions of variance are completely understood
+   by the cache, then the cache becomes capable of performing server-
+   driven negotiation on behalf of the origin server for subsequent
+   requests on that resource.
+
+   Transparent negotiation has the advantage of distributing the
+   negotiation work that would otherwise be required of the origin
+   server and also removing the second request delay of agent-driven
+   negotiation when the cache is able to correctly guess the right
+   response.
+
+   This specification does not define any mechanism for transparent
+   negotiation, though it also does not prevent any such mechanism from
+   being developed as an extension that could be used within HTTP/1.1.
+
+13 Caching in HTTP
+
+   HTTP is typically used for distributed information systems, where
+   performance can be improved by the use of response caches. 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.
+
+   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 13.2). The
+   latter reduces network bandwidth requirements; we use a "validation"
+   mechanism for this purpose (see section 13.3).
+
+   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,
+
+
+
+Fielding, et al.            Standards Track                    [Page 74]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   and clients to explicitly reduce transparency when necessary.
+   However, because non-transparent operation may confuse non-expert
+   users, and might be incompatible with certain server applications
+   (such as those for ordering merchandise), the protocol requires that
+   transparency be relaxed
+
+      - only by an explicit protocol-level request when relaxed by
+        client or origin server
+
+      - only with an explicit warning to the end user when relaxed by
+        cache or client
+
+   Therefore, the HTTP/1.1 protocol provides these important elements:
+
+      1. Protocol features that provide full semantic transparency when
+         this is required by all parties.
+
+      2. Protocol features that allow an origin server or user agent to
+         explicitly request and control non-transparent operation.
+
+      3. Protocol features that allow a cache to attach warnings to
+         responses that do not preserve the requested approximation of
+         semantic transparency.
+
+   A basic principle is that it must be possible for the clients to
+   detect any potential relaxation of semantic transparency.
+
+      Note: The server, cache, or client implementor might be faced with
+      design decisions not explicitly discussed in this specification.
+      If a decision might affect semantic transparency, the implementor
+      ought to err on the side of maintaining transparency unless a
+      careful and complete analysis shows significant benefits in
+      breaking transparency.
+
+13.1.1 Cache Correctness
+
+   A correct cache MUST respond to a request with the most up-to-date
+   response held by the cache that is appropriate to the request (see
+   sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
+   conditions:
+
+      1. It has been checked for equivalence with what the origin server
+         would have returned by revalidating the response with the
+         origin server (section 13.3);
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 75]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      2. It is "fresh enough" (see section 13.2). In the default case,
+         this means it meets the least restrictive freshness requirement
+         of the client, origin server, and cache (see section 14.9); if
+         the origin server so specifies, it is the freshness requirement
+         of the origin server alone.
+
+         If a stored response is not "fresh enough" by the most
+         restrictive freshness requirement of both the client and the
+         origin server, in carefully considered circumstances the cache
+         MAY still return the response with the appropriate Warning
+         header (see section 13.1.5 and 14.46), unless such a response
+         is prohibited (e.g., by a "no-store" cache-directive, or by a
+         "no-cache" cache-request-directive; see section 14.9).
+
+      3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
+         or error (4xx or 5xx) response message.
+
+   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 failure.
+
+   If a cache receives a response (either an entire response, or a 304
+   (Not Modified) response) that it would normally forward to the
+   requesting client, and the received response is no longer fresh, the
+   cache SHOULD forward it to the requesting client without adding a new
+   Warning (but without removing any existing Warning headers). A cache
+   SHOULD NOT attempt to revalidate a response simply because that
+   response became stale in transit; this might lead to an infinite
+   loop. A user agent that receives a stale response without a Warning
+   MAY display a warning indication to the user.
+
+13.1.2 Warnings
+
+   Whenever a cache returns a response that is neither first-hand nor
+   "fresh enough" (in the sense of condition 2 in section 13.1.1), it
+   MUST attach a warning to that effect, using a Warning general-header.
+   The Warning header and the currently defined warnings are described
+   in section 14.46. The warning allows clients 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 assigned three digit warn-codes. The first digit
+   indicates whether the Warning MUST or MUST NOT be deleted from a
+   stored cache entry after a successful revalidation:
+
+
+
+Fielding, et al.            Standards Track                    [Page 76]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   1xx  Warnings that describe the freshness or revalidation status of
+     the response, and so MUST be deleted after a successful
+     revalidation. 1XX warn-codes MAY be generated by a cache only when
+     validating a cached entry. It MUST NOT be generated by clients.
+
+   2xx  Warnings that describe some aspect of the entity body or entity
+     headers that is not rectified by a revalidation (for example, a
+     lossy compression of the entity bodies) and which MUST NOT be
+     deleted after a successful revalidation.
+
+   See section 14.46 for the definitions of the codes themselves.
+
+   HTTP/1.0 caches will cache all Warnings in responses, without
+   deleting the ones in the first category. Warnings in responses that
+   are passed to HTTP/1.0 caches carry an extra warning-date field,
+   which prevents a future HTTP/1.1 recipient from believing an
+   erroneously cached Warning.
+
+   Warnings also carry a warning text. The text MAY be in any
+   appropriate natural language (perhaps based on the client's Accept
+   headers), and include an OPTIONAL indication of what character set is
+   used.
+
+   Multiple warnings 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 might provide the same warning with
+   texts in both English and Basque.
+
+   When multiple warnings are attached to a response, it might 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.
+
+13.1.3 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 might 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 is applied (that is, the
+   one that is most likely to preserve semantic transparency). However,
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 77]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   in some cases, cache-control directives are explicitly specified as
+   weakening the approximation of semantic transparency (for example,
+   "max-stale" or "public").
+
+   The cache-control directives are described in detail in section 14.9.
+
+13.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 might 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" to every request. The user agent SHOULD NOT
+   default to either non-transparent behavior, or behavior that results
+   in abnormally ineffective caching, but MAY be explicitly configured
+   to do so by an explicit action of the user.
+
+   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 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 indicate this state to the user (for example, by a
+   display of a picture of currency in flames) so that the user does not
+   inadvertently consume excess resources or suffer from excessive
+   latency.
+
+13.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 ought 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) enabling
+   the client software to alert the user that there might be a potential
+   problem.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 78]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   It also allows the user agent to take steps to obtain a first-hand or
+   fresh response. For this reason, a cache SHOULD NOT return a stale
+   response if the client explicitly requests a first-hand or fresh one,
+   unless it is impossible to comply for technical or policy reasons.
+
+13.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 might 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 of an unvalidated response; specifying a value of zero forces
+   the 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
+   further relax the cache's approximation of 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 might violate the origin server's specified
+   constraints on semantic transparency, but might be necessary to
+   support disconnected operation, or high availability in the face of
+   poor connectivity.
+
+13.2 Expiration Model
+
+13.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.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 79]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The expiration mechanism applies only to responses taken from a cache
+   and not to first-hand responses forwarded immediately to the
+   requesting client.
+
+   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 14.9.4 for a more restrictive way to force revalidation.
+
+   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 14.9).
+
+   Servers specify explicit expiration times using either the Expires
+   header, or the max-age directive of the Cache-Control header.
+
+   An expiration time cannot be used to force a user agent to refresh
+   its display or reload a resource; 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.
+   See section 13.13 for an explanation of the difference between caches
+   and history mechanisms.
+
+13.2.2 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 might compromise semantic transparency, they ought to used
+   cautiously, and we encourage origin servers to provide explicit
+   expiration times as much as possible.
+
+13.2.3 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 13.2.4; 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." Hosts that use
+   HTTP, but especially hosts running origin servers and caches, SHOULD
+   use NTP [28] or some similar protocol to synchronize their clocks to
+   a globally accurate time standard.
+
+
+
+Fielding, et al.            Standards Track                    [Page 80]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 requires origin servers to send a Date header, if possible,
+   with every response, giving the time at which the response was
+   generated (see section 14.18). We use the term "date_value" to denote
+   the value of the Date header, in a form appropriate for arithmetic
+   operations.
+
+   HTTP/1.1 uses the Age response-header to convey the estimated age of
+   the response message when obtained from a cache. The Age field value
+   is the cache's estimate of the amount of time since the response was
+   generated or revalidated by the origin server.
+
+   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 the value of the Age header, in
+   a form appropriate for arithmetic operations.
+
+   A response's age can be calculated in two entirely independent ways:
+
+      1. now minus date_value, if the local clock is reasonably well
+         synchronized to the origin server's clock. If the result is
+         negative, the result 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.
+
+   Because of network-imposed delays, some significant interval might
+   pass between 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
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 81]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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
+       *      is the current (local) time
+       */
+
+      apparent_age = max(0, response_time - date_value);
+      corrected_received_age = max(apparent_age, age_value);
+      response_delay = response_time - request_time;
+      corrected_initial_age = corrected_received_age + response_delay;
+      resident_time = now - response_time;
+      current_age   = corrected_initial_age + resident_time;
+
+   The current_age of a cache entry is calculated by adding the amount
+   of time (in seconds) since the cache entry was last validated by the
+   origin server to the corrected_initial_age. When a response is
+   generated from a cache entry, the cache MUST include a single Age
+   header field in the response with a value equal to the cache entry's
+   current_age.
+
+   The presence of an Age header field in a response implies that a
+   response is not first-hand. However, the converse is not true, since
+   the lack of an Age header field in a response does not imply that the
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 82]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   response is first-hand unless all caches along the request path are
+   compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
+   the Age header field).
+
+13.2.4 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 13.2.3; this section describes how to calculate
+   the freshness lifetime, and to determine if a response has expired.
+   In the discussion below, the values can be represented in any form
+   appropriate for arithmetic operations.
+
+   We use the term "expires_value" to denote the value of the Expires
+   header. We use the term "max_age_value" to denote an appropriate
+   value of the number of seconds carried by the "max-age" directive of
+   the Cache-Control header in a response (see section 14.9.3).
+
+   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 none of Expires, Cache-Control: max-age, or Cache-Control: s-
+   maxage (see section 14.9.3) appears in the response, and the response
+   does not include other restrictions on caching, the cache MAY compute
+   a freshness lifetime using a heuristic. The cache MUST attach Warning
+   113 to any response whose age is more than 24 hours if such warning
+   has not already been added.
+
+   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%.
+
+   The calculation to determine if a response has expired is quite
+   simple:
+
+      response_is_fresh = (freshness_lifetime > current_age)
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 83]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.2.5 Disambiguating Expiration Values
+
+   Because expiration values are assigned optimistically, it is possible
+   for two caches to contain fresh values for the same resource that are
+   different.
+
+   If a client performing a retrieval receives a non-first-hand response
+   for a request 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 14.9), to force a check with the origin server.
+
+   If a cache has two fresh responses for the same representation with
+   different validators, it MUST use the one with the more recent Date
+   header. This situation might arise because the cache is pooling
+   responses from other caches, or because a client has asked for a
+   reload or a revalidation of an apparently fresh cache entry.
+
+13.2.6 Disambiguating Multiple Responses
+
+   Because a client might 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 might
+   receive responses in an order different from that in which the origin
+   server sent 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. The Date values are
+   ordered to a granularity of one second.
+
+   When a client tries to revalidate a cache entry, and the response it
+   receives contains a Date header that appears to be older than the one
+   for the existing entry, then the client SHOULD repeat the request
+   unconditionally, and include
+
+       Cache-Control: max-age=0
+
+   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.
+
+
+
+Fielding, et al.            Standards Track                    [Page 84]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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.
+
+13.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 (user agent or
+   proxy 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 entity, and, if they match (see section 13.3.3), 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.
+
+   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 a validator matches or if and
+   only if no validators match.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 85]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      Note: a response that lacks a 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 validator for the
+      entity, which means it will not be refreshable after it expires.
+
+13.3.1 Last-Modified Dates
+
+   The Last-Modified entity-header field value is often used as a cache
+   validator. In simple terms, a cache entry is considered to be valid
+   if the entity has not been modified since the Last-Modified value.
+
+13.3.2 Entity Tag Cache Validators
+
+   The ETag response-header field value, an entity tag, provides for an
+   "opaque" cache validator. This might allow more reliable validation
+   in situations where it is inconvenient to store modification dates,
+   where the one-second resolution of HTTP date values is not
+   sufficient, or where the origin server wishes to avoid certain
+   paradoxes that might arise from the use of modification dates.
+
+   Entity Tags are described in section 3.11. The headers used with
+   entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
+
+13.3.3 Weak and Strong Validators
+
+   Since both origin servers and caches will compare two validators to
+   decide if they represent the same or different entities, one normally
+   would expect that if the 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 might be cases when a server prefers to change the
+   validator only on semantically significant changes, and not when
+   insignificant aspects of the entity change. A validator that does not
+   always change when the resource changes is a "weak validator."
+
+   Entity tags are normally "strong validators," but the protocol
+   provides a mechanism to tag an entity tag as "weak." 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.
+
+
+
+Fielding, et al.            Standards Track                    [Page 86]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      An entity's modification time, if represented with one-second
+      resolution, could be a weak validator, since it is possible that
+      the resource might be modified twice during a single second.
+
+      Support for weak validators is optional. However, weak validators
+      allow for more efficient caching of equivalent objects; for
+      example, a hit counter on a site is probably good enough if it is
+      updated every few days or weeks, and any value during that period
+      is likely "good enough" to be equivalent.
+
+   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 might end up with an internally
+   inconsistent entity.
+
+   Clients MAY issue simple (non-subrange) GET requests with either weak
+   validators or strong validators. Clients MUST NOT use weak validators
+   in other forms of request.
+
+   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 both MUST
+        NOT 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.
+
+   An entity tag is strong unless it is explicitly tagged as weak.
+   Section 3.11 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, et al.            Standards Track                    [Page 87]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - 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 sent 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 sent 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
+   sent 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 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
+
+
+
+Fielding, et al.            Standards Track                    [Page 88]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   servers.
+
+13.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 ought to
+   be used, and for what purposes.
+
+   HTTP/1.1 origin servers:
+
+      - SHOULD send an entity tag validator unless it is not feasible to
+        generate one.
+
+      - MAY send a weak entity tag instead of a strong entity tag, if
+        performance considerations support the use of weak entity tags,
+        or if it is unfeasible to send a strong entity tag.
+
+      - 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 must avoid reusing a specific strong entity tag
+      value for two different entities, or reusing a specific weak
+      entity tag value for two semantically different entities. Cache
+      entries might persist for arbitrarily long periods, regardless of
+      expiration times, so it might 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-None-Match).
+
+      - 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).
+
+
+
+Fielding, et al.            Standards Track                    [Page 89]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - 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 origin server, upon receiving a conditional request that
+   includes both a Last-Modified date (e.g., in an If-Modified-Since or
+   If-Unmodified-Since header field) and one or more entity tags (e.g.,
+   in an If-Match, If-None-Match, or If-Range header field) as cache
+   validators, MUST NOT return a response status of 304 (Not Modified)
+   unless doing so is consistent with all of the conditional header
+   fields in the request.
+
+   An HTTP/1.1 caching proxy, upon receiving a conditional request that
+   includes both a Last-Modified date and one or more entity tags as
+   cache validators, MUST NOT return a locally cached response to the
+   client unless that cached response is consistent with all of the
+   conditional header fields in the request.
+
+      Note: 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 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.
+
+13.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.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 90]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.4 Response Cacheability
+
+   Unless specifically constrained by a cache-control (section 14.9)
+   directive, a caching system MAY always store a successful response
+   (see section 13.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: some HTTP/1.0 caches are known to violate this expectation
+      without providing any Warning.
+
+   However, in some cases it might be inappropriate for a cache to
+   retain an entity, or to return it in response to a subsequent
+   request. This might 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, are not to be cached
+   regardless of other considerations.
+
+   Note that section 14.8 normally prevents a shared cache from saving
+   and returning a response to a previous request if that request
+   included an Authorization header.
+
+   A response received with a status code of 200, 203, 206, 300, 301 or
+   410 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. However, a cache that does not support
+   the Range and Content-Range headers MUST NOT cache 206 (Partial
+   Content) responses.
+
+   A response received with any other status code (e.g. status codes 302
+   and 307) MUST NOT be returned in a reply to a subsequent request
+   unless there are cache-control directives or another header(s) that
+   explicitly allow it. For example, these include the following: an
+   Expires header (section 14.21); a "max-age", "s-maxage",  "must-
+   revalidate", "proxy-revalidate", "public" or "private" cache-control
+   directive (section 14.9).
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 91]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5 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 might have to combine parts of a new
+   response with what is held in the cache entry.
+
+13.5.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 are  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 MUST be
+        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
+      - Proxy-Authenticate
+      - Proxy-Authorization
+      - TE
+      - Trailers
+      - Transfer-Encoding
+      - Upgrade
+
+   All other headers defined by HTTP/1.1 are end-to-end headers.
+
+   Other hop-by-hop headers MUST be listed in a Connection header,
+   (section 14.10) to be introduced into HTTP/1.1 (or later).
+
+13.5.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
+   transparent proxy SHOULD NOT modify an end-to-end header unless the
+   definition of that header requires or specifically allows that.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 92]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A transparent proxy MUST NOT modify any of the following fields in a
+   request or response, and it MUST NOT add any of these fields if not
+   already present:
+
+      - Content-Location
+
+      - Content-MD5
+
+      - ETag
+
+      - Last-Modified
+
+   A transparent proxy MUST NOT modify any of the following fields in a
+   response:
+
+      - Expires
+
+   but it MAY add any of these fields if not already present. If an
+   Expires header is added, it MUST be given a field-value identical to
+   that of the Date header in that response.
+
+   A  proxy MUST NOT modify or add any of the following fields in a
+   message that contains the no-transform cache-control directive, or in
+   any request:
+
+      - Content-Encoding
+
+      - Content-Range
+
+      - Content-Type
+
+   A non-transparent proxy MAY modify or add these fields to a message
+   that does not include no-transform, but if it does so, it MUST add a
+   Warning 214 (Transformation applied) if one does not already appear
+   in the message (see section 14.46).
+
+      Warning: unnecessary modification of end-to-end headers might
+      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.
+
+   The Content-Length field of a request or response is added or deleted
+   according to the rules in section 4.4. A transparent proxy MUST
+   preserve the entity-length (section 7.2.2) of the entity-body,
+   although it MAY change the transfer-length (section 4.4).
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 93]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5.3 Combining Headers
+
+   When a cache makes a validating request to a server, and the server
+   provides a 304 (Not Modified) response or a 206 (Partial Content)
+   response, the cache then constructs a response to send to the
+   requesting client.
+
+   If the status code is 304 (Not Modified), the cache uses the entity-
+   body stored in the cache entry as the entity-body of this outgoing
+   response. If the status code is 206 (Partial Content) and the ETag or
+   Last-Modified headers match exactly, the cache MAY combine the
+   contents stored in the cache entry with the new contents received in
+   the response and use the result as the entity-body of this outgoing
+   response, (see 13.5.4).
+
+   The end-to-end headers stored in the cache entry are used for the
+   constructed response, except that
+
+      - any stored Warning headers with warn-code 1xx (see section
+        14.46) MUST be deleted from the cache entry and the forwarded
+        response.
+
+      - any stored Warning headers with warn-code 2xx MUST be retained
+        in the cache entry and the forwarded response.
+
+      - any end-to-end headers provided in the 304 or 206 response MUST
+        replace the corresponding headers from the cache entry.
+
+   Unless the cache decides to remove the cache entry, it MUST also
+   replace the end-to-end headers stored with the cache entry with
+   corresponding headers received in the incoming response, except for
+   Warning headers as described immediately above. If a header field-
+   name in the incoming response matches more than one header in the
+   cache entry, all such old headers MUST be replaced.
+
+   In other words, the set of end-to-end headers received in the
+   incoming response overrides all corresponding end-to-end headers
+   stored with the cache entry (except for stored Warning headers with
+   warn-code 1xx, which are deleted even if not overridden).
+
+      Note: this rule allows an origin server to use a 304 (Not
+      Modified) or a 206 (Partial Content) response to update any header
+      associated with a previous response for the same entity or sub-
+      ranges thereof, although it might not always be meaningful or
+      correct to do so. This rule does not allow an origin server to use
+      a 304 (Not Modified) or a 206 (Partial Content) response to
+      entirely delete a header that it had provided with a previous
+      response.
+
+
+
+Fielding, et al.            Standards Track                    [Page 94]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5.4 Combining Byte Ranges
+
+   A response might transfer only a subrange of the bytes of an entity-
+   body, either because the request included one or more Range
+   specifications, or because a connection was broken prematurely. After
+   several such transfers, a cache might have received several ranges of
+   the same entity-body.
+
+   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:
+
+      - Both the incoming response and the cache entry have a cache
+        validator.
+
+      - The two cache validators match using the strong comparison
+        function (see section 13.3.3).
+
+   If either requirement is not met, 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.
+
+13.6 Caching Negotiated Responses
+
+   Use of server-driven content negotiation (section 12.1), as indicated
+   by the presence of a Vary header field in a response, alters the
+   conditions and procedure by which a cache can use the response for
+   subsequent requests. See section 14.44 for use of the Vary header
+   field by servers.
+
+   A server SHOULD use the Vary header field to inform a cache of what
+   request-header fields were used to select among multiple
+   representations of a cacheable response subject to server-driven
+   negotiation. The set of header fields named by the Vary field value
+   is known as the "selecting" request-headers.
+
+   When the cache receives a subsequent request whose Request-URI
+   specifies one or more cache entries including a Vary header field,
+   the cache MUST NOT use such a cache entry to construct a response to
+   the new request unless all of the selecting request-headers present
+   in the new request match the corresponding stored request-headers in
+   the original request.
+
+   The selecting request-headers from two requests are defined to match
+   if and only if the selecting request-headers in the first request can
+   be transformed to the selecting request-headers in the second request
+
+
+
+Fielding, et al.            Standards Track                    [Page 95]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   by adding or removing linear white space (LWS) at places where this
+   is allowed by the corresponding BNF, and/or combining multiple
+   message-header fields with the same field name following the rules
+   about message headers in section 4.2.
+
+   A Vary header field-value of "*" always fails to match and subsequent
+   requests on that resource can only be properly interpreted by the
+   origin server.
+
+   If the selecting request header fields for the cached entry do not
+   match the selecting request header fields of the new request, then
+   the cache MUST NOT use a cached entry to satisfy the request unless
+   it first relays the new request to the origin server in a conditional
+   request and the server responds with 304 (Not Modified), including an
+   entity tag or Content-Location that indicates the entity to be used.
+
+   If an entity tag was assigned to a cached representation, the
+   forwarded request SHOULD be conditional and include the entity tags
+   in an If-None-Match header field from all its cache entries for the
+   resource. This conveys to the server the set of entities currently
+   held by the cache, so that if any one of these entities matches the
+   requested entity, the server can use the ETag header field in its 304
+   (Not Modified) response to tell the cache which entry is appropriate.
+   If the entity-tag of the new response matches that of an existing
+   entry, the new response SHOULD be used to update the header fields of
+   the existing entry, and the result MUST be returned to the client.
+
+   If any of the existing cache entries contains only partial content
+   for the associated entity, its entity-tag SHOULD NOT be included in
+   the If-None-Match header field unless the request is for a range that
+   would be fully satisfied by that entry.
+
+   If a cache receives a successful response whose Content-Location
+   field matches that of an existing cache entry for the same Request-
+   ]URI, whose entity-tag differs from that of the existing entry, and
+   whose Date is more recent than that of the existing entry, the
+   existing entry SHOULD NOT be returned in response to future requests
+   and SHOULD be deleted from the cache.
+
+13.7 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
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 96]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   this specification place certain constraints on the operation of
+   shared caches in order to prevent loss of privacy or failure of
+   access controls.
+
+13.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
+   13.5.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).
+
+   If a cache receives a 5xx response while attempting to revalidate an
+   entry, 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 unless the cached entry
+   includes the "must-revalidate" cache-control directive (see section
+   14.9).
+
+13.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 URIs 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 9.1.1 for related information.
+
+13.10 Invalidation After Updates or Deletions
+
+   The effect of certain methods performed on a resource at the origin
+   server might cause one or more existing cache entries to become non-
+   transparently invalid. That is, although they might continue to be
+   "fresh," they do not accurately reflect what the origin server would
+   return for a new request on that resource.
+
+
+
+Fielding, et al.            Standards Track                    [Page 97]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 change at the origin server might 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 will either remove all instances of that entity from its
+   storage, or will 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 MUST cause a cache to invalidate an entity. This is
+   either the entity referred to by the Request-URI, or by the Location
+   or Content-Location 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.
+
+   A cache that passes through requests for methods it does not
+   understand SHOULD invalidate any entities referred to by the
+   Request-URI.
+
+13.11 Write-Through Mandatory
+
+   All methods that might 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. This does not prevent
+   a proxy cache from sending a 100 (Continue) response before the
+   inbound server has sent its final reply.
+
+   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.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 98]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.12 Cache Replacement
+
+   If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
+   response is received from a resource while any existing responses for
+   the same resource are cached, 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  the
+   rules in section 13.5.3 apply.
+
+      Note: a new response that has an older Date header value than
+      existing cached responses is not cacheable.
+
+13.13 History Lists
+
+   User agents often have history mechanisms, such as "Back" buttons and
+   history lists, which can be used to redisplay an entity retrieved
+   earlier in a session.
+
+   History mechanisms and caches are different. In particular history
+   mechanisms SHOULD NOT try to show a semantically transparent view of
+   the current state of a resource. Rather, a history mechanism is meant
+   to show exactly what the user saw at the time when the resource was
+   retrieved.
+
+   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.
+
+   This is not to be construed to prohibit the history mechanism from
+   telling the user that a view might be stale.
+
+      Note: if history list mechanisms unnecessarily prevent users from
+      viewing stale resources, this will tend to force service authors
+      to avoid using HTTP expiration controls and cache controls when
+      they would otherwise like to. Service authors may consider it
+      important that users not be presented with error messages or
+      warning messages when they use navigation controls (such as BACK)
+      to view previously fetched resources. Even though sometimes such
+      resources ought not to cached, or ought to expire quickly, user
+      interface considerations may force service authors to resort to
+      other means of preventing caching (e.g. "once-only" URLs) in order
+      not to suffer the effects of improperly functioning history
+      mechanisms.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 99]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14 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.
+
+14.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.
+
+       Accept         = "Accept" ":"
+                        #( media-range [ accept-params ] )
+
+       media-range    = ( "*/*"
+                        | ( type "/" "*" )
+                        | ( type "/" subtype )
+                        ) *( ";" parameter )
+       accept-params  = ";" "q" "=" qvalue *( accept-extension )
+       accept-extension = ";" token [ "=" ( token | quoted-string ) ]
+
+   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 media-range MAY include media type
+   parameters that are applicable to that range.
+
+   Each media-range MAY be followed by one or more accept-params,
+   beginning with the "q" parameter for indicating a relative quality
+   factor. The first "q" parameter (if any) separates the media-range
+   parameter(s) from the accept-params. Quality factors allow the user
+   or user agent to indicate the relative degree of preference for that
+   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
+   default value is q=1.
+
+      Note: Use of the "q" parameter name to separate media type
+      parameters from Accept extension parameters is due to historical
+      practice. Although this prevents any media type parameter named
+      "q" from being used with a media range, such an event is believed
+      to be unlikely given the lack of any "q" parameters in the IANA
+      media type registry and the rare usage of any media type
+      parameters in Accept. Future media types are discouraged from
+      registering any parameter named "q".
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 100]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 field is present, then it is assumed that the
+   client accepts all media types. If an Accept header field is present,
+   and if the server cannot send a response which is acceptable
+   according to the combined Accept field value, then the server SHOULD
+   send a 406 (not acceptable) response.
+
+   A more elaborate example is
+
+       Accept: text/plain; q=0.5, text/html,
+               text/x-dvi; q=0.8, text/x-c
+
+   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,
+               text/html;level=2;q=0.4, */*;q=0.5
+
+   would cause the following values to be associated:
+
+       text/html;level=1         = 1
+       text/html                 = 0.7
+       text/plain                = 0.3
+
+
+
+Fielding, et al.            Standards Track                   [Page 101]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       image/jpeg                = 0.5
+       text/html;level=2         = 0.4
+       text/html;level=3         = 0.7
+
+      Note: A user agent might 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 ought to be configurable by the user.
+
+14.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.
+
+      Accept-Charset = "Accept-Charset" ":"
+              1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
+
+
+   Character set values are described in section 3.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
+
+   The special value "*", if present in the Accept-Charset field,
+   matches every character set (including ISO-8859-1) which is not
+   mentioned elsewhere in the Accept-Charset field. If no "*" is present
+   in an Accept-Charset field, then all character sets not explicitly
+   mentioned get a quality value of 0, except for ISO-8859-1, which gets
+   a quality value of 1 if not explicitly mentioned.
+
+   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.
+
+14.3 Accept-Encoding
+
+   The Accept-Encoding request-header field is similar to Accept, but
+   restricts the content-codings (section 3.5) that are acceptable in
+   the response.
+
+       Accept-Encoding  = "Accept-Encoding" ":"
+
+
+
+Fielding, et al.            Standards Track                   [Page 102]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                          1#( codings [ ";" "q" "=" qvalue ] )
+       codings          = ( content-coding | "*" )
+
+   Examples of its use are:
+
+       Accept-Encoding: compress, gzip
+       Accept-Encoding:
+       Accept-Encoding: *
+       Accept-Encoding: compress;q=0.5, gzip;q=1.0
+       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
+
+   A server tests whether a content-coding is acceptable, according to
+   an Accept-Encoding field, using these rules:
+
+      1. If the content-coding is one of the content-codings listed in
+         the Accept-Encoding field, then it is acceptable, unless it is
+         accompanied by a qvalue of 0. (As defined in section 3.9, a
+         qvalue of 0 means "not acceptable.")
+
+      2. The special "*" symbol in an Accept-Encoding field matches any
+         available content-coding not explicitly listed in the header
+         field.
+
+      3. If multiple content-codings are acceptable, then the acceptable
+         content-coding with the highest non-zero qvalue is preferred.
+
+      4. The "identity" content-coding is always acceptable, unless
+         specifically refused because the Accept-Encoding field includes
+         "identity;q=0", or because the field includes "*;q=0" and does
+         not explicitly include the "identity" content-coding. If the
+         Accept-Encoding field-value is empty, then only the "identity"
+         encoding is acceptable.
+
+   If an Accept-Encoding field is present in a request, 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.
+
+   If no Accept-Encoding field is present in a request, the server MAY
+   assume that the client will accept any content coding. In this case,
+   if "identity" is one of the available content-codings, then the
+   server SHOULD use the "identity" content-coding, unless it has
+   additional information that a different content-coding is meaningful
+   to the client.
+
+      Note: If the request does not include an Accept-Encoding field,
+      and if the "identity" content-coding is unavailable, then
+      content-codings commonly understood by HTTP/1.0 clients (i.e.,
+
+
+
+Fielding, et al.            Standards Track                   [Page 103]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      "gzip" and "compress") are preferred; some older clients
+      improperly display messages sent with other content-codings.  The
+      server might also make this decision based on information about
+      the particular user-agent or client.
+
+      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
+      associated with content-codings. This means that qvalues will not
+      work and are not permitted with x-gzip or x-compress.
+
+14.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. Language tags are defined in section 3.10.
+
+       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 preference for the languages
+   specified by that range. The quality value defaults to "q=1". For
+   example,
+
+       Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+   would mean: "I prefer Danish, but will accept British English and
+   other types of English." A language-range matches a language-tag if
+   it exactly equals the tag, or if it exactly equals a prefix 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 range 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-tag. 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
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 104]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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.
+
+   It might 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 15.1.4.
+
+   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.
+
+      Note: When making the choice of linguistic preference available to
+      the user, we remind implementors of  the fact that users are not
+      familiar with the details of language matching as described above,
+      and should provide appropriate guidance. As an example, users
+      might assume that on selecting "en-gb", they will be served any
+      kind of English document if British English is not available. A
+      user agent might suggest in such a case to add "en" to get the
+      best matching behavior.
+
+14.5 Accept-Ranges
+
+      The Accept-Ranges response-header field allows the server to
+      indicate its acceptance of range requests for a resource:
+
+          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
+          acceptable-ranges = 1#range-unit | "none"
+
+      Origin servers that accept byte-range requests MAY send
+
+          Accept-Ranges: bytes
+
+      but are not required to do so. Clients MAY generate byte-range
+      requests without having received this header for the resource
+      involved. Range units are defined in section 3.12.
+
+      Servers that do not accept any kind of range request for a
+      resource MAY send
+
+          Accept-Ranges: none
+
+      to advise the client not to attempt a range request.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 105]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.6 Age
+
+      The Age response-header field conveys the sender's estimate of the
+      amount of time since the response (or its revalidation) was
+      generated at the origin server. A cached response is "fresh" if
+      its age does not exceed its freshness lifetime. Age values are
+      calculated as specified in section 13.2.3.
+
+           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). An HTTP/1.1 server that includes a cache MUST
+      include an Age header field in every response generated from its
+      own cache. Caches SHOULD use an arithmetic type of at least 31
+      bits of range.
+
+14.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.
+
+          Allow   = "Allow" ":" #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 is not required to support these methods and
+      SHOULD include an Allow header in the response giving the actual
+      supported methods.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 106]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      A proxy MUST NOT modify the Allow header field even if it does not
+      understand all the methods specified, since the user agent might
+      have other means of communicating with the origin server.
+
+14.8 Authorization
+
+      A user agent that wishes to authenticate itself with a server--
+      usually, but not necessarily, after receiving a 401 response--does
+      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
+
+      HTTP access authentication is described in "HTTP Authentication:
+      Basic and Digest Access Authentication" [43]. If a request is
+      authenticated and a realm specified, the same credentials SHOULD
+      be valid for all other requests within this realm (assuming that
+      the authentication scheme itself does not require otherwise, such
+      as credentials that vary according to a challenge value or using
+      synchronized clocks).
+
+      When a shared cache (see section 13.7) 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 "s-maxage" cache-control
+         directive, the cache MAY use that response in replying to a
+         subsequent request. But (if the specified maximum age has
+         passed) 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. (This is the
+         defined behavior for s-maxage.) If the response includes "s-
+         maxage=0", the proxy MUST always revalidate it before re-using
+         it.
+
+      2. If the response includes the "must-revalidate" cache-control
+         directive, the cache MAY use that response in replying to a
+         subsequent request. But if the response is stale, 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.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 107]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.9 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 is
+   to be given in the response.
+
+      Note that HTTP/1.0 caches might not implement Cache-Control and
+      might only implement Pragma: no-cache (see section 14.32).
+
+   Cache directives MUST be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives might 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 = cache-request-directive
+         | cache-response-directive
+
+    cache-request-directive =
+           "no-cache"                          ; Section 14.9.1
+         | "no-store"                          ; Section 14.9.2
+         | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4
+         | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3
+         | "min-fresh" "=" delta-seconds       ; Section 14.9.3
+         | "no-transform"                      ; Section 14.9.5
+         | "only-if-cached"                    ; Section 14.9.4
+         | cache-extension                     ; Section 14.9.6
+
+     cache-response-directive =
+           "public"                               ; Section 14.9.1
+         | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
+         | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
+         | "no-store"                             ; Section 14.9.2
+         | "no-transform"                         ; Section 14.9.5
+         | "must-revalidate"                      ; Section 14.9.4
+         | "proxy-revalidate"                     ; Section 14.9.4
+         | "max-age" "=" delta-seconds            ; Section 14.9.3
+         | "s-maxage" "=" delta-seconds           ; Section 14.9.3
+         | cache-extension                        ; Section 14.9.6
+
+    cache-extension = token [ "=" ( token | quoted-string ) ]
+
+
+
+Fielding, et al.            Standards Track                   [Page 108]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   When a directive appears without any 1#field-name parameter, the
+   directive applies to the entire request or response. When such a
+   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 might 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 are cacheable; 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 user agent.
+
+      - Modifications of the basic expiration mechanism; these may be
+        imposed by either the origin server or the user agent.
+
+      - Controls over cache revalidation and reload; these may only be
+        imposed by a user agent.
+
+      - Control over transformation of entities.
+
+      - Extensions to the caching system.
+
+14.9.1 What is Cacheable
+
+   By default, a response is cacheable if the requirements of the
+   request method, request header fields, and the response status
+   indicate that it is cacheable. Section 13.4 summarizes these defaults
+   for cacheability. The following Cache-Control response directives
+   allow an origin server to override the default cacheability of a
+   response:
+
+   public
+      Indicates that the response MAY be cached by any cache, even if it
+      would normally be non-cacheable or cacheable only within a non-
+      shared cache. (See also Authorization, section 14.8, for
+      additional details.)
+
+   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
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 109]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      response are intended for only one user and are not a valid
+      response for requests by other users. A private (non-shared) cache
+      MAY cache the response.
+
+       Note: This usage of the word private only controls where the
+       response may be cached, and cannot ensure the privacy of the
+       message content.
+
+   no-cache
+       If the no-cache directive does not specify a field-name, then a
+      cache MUST NOT use the response to satisfy a subsequent request
+      without successful revalidation with the origin server. This
+      allows an origin server to prevent caching even by caches that
+      have been configured to return stale responses to client requests.
+
+      If the no-cache directive does specify one or more field-names,
+      then a cache MAY use the response to satisfy a subsequent request,
+      subject to any other restrictions on caching. However, the
+      specified field-name(s) MUST NOT be sent in the response to a
+      subsequent request without successful revalidation with the origin
+      server. This allows an origin server to prevent the re-use of
+      certain header fields in a response, while still allowing caching
+      of the rest of the response.
+
+       Note: Most HTTP/1.0 caches will not recognize or obey this
+       directive.
+
+14.9.2 What May be Stored by Caches
+
+   no-store
+      The purpose of the no-store directive is to prevent the
+      inadvertent release or retention of sensitive information (for
+      example, on backup tapes). 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. "MUST NOT store" in this context means
+      that the cache MUST NOT intentionally store the information in
+      non-volatile storage, and MUST make a best-effort attempt to
+      remove the information from volatile storage as promptly as
+      possible after forwarding it.
+
+      Even when this directive is associated with a response, users
+      might 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.
+
+
+
+Fielding, et al.            Standards Track                   [Page 110]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      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 might
+      improve privacy in some cases, we caution that it is NOT in any
+      way a reliable or sufficient mechanism for ensuring privacy. In
+      particular, malicious or compromised caches might not recognize or
+      obey this directive, and communications networks might be
+      vulnerable to eavesdropping.
+
+14.9.3 Modifications of the Basic Expiration Mechanism
+
+   The expiration time of an entity MAY be specified by the origin
+   server using the Expires header (see section 14.21). Alternatively,
+   it MAY be specified using the max-age directive in a response. When
+   the max-age cache-control directive is present in a cached response,
+   the response is stale if its current age is greater than the age
+   value given (in seconds) at the time of a new request for that
+   resource. The max-age directive on a response implies that the
+   response is cacheable (i.e., "public") unless some other, more
+   restrictive cache directive is also present.
+
+   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 might be
+   useful if certain HTTP/1.0 caches improperly calculate ages or
+   expiration times, perhaps due to desynchronized clocks.
+
+   Many HTTP/1.0 cache implementations will treat an Expires value that
+   is less than or equal to the response Date value as being equivalent
+   to the Cache-Control response directive "no-cache". If an HTTP/1.1
+   cache receives such a response, and the response does not include a
+   Cache-Control header field, it SHOULD consider the response to be
+   non-cacheable in order to retain compatibility with HTTP/1.0 servers.
+
+       Note: An origin server might wish to use a relatively new HTTP
+       cache control feature, such as the "private" directive, on a
+       network including older caches that do not understand that
+       feature. The origin server will need to combine the new feature
+       with an Expires field whose value is less than or equal to the
+       Date value. This will prevent older caches from improperly
+       caching the response.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 111]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   s-maxage
+       If a response includes an s-maxage directive, then for a shared
+       cache (but not for a private cache), the maximum age specified by
+       this directive overrides the maximum age specified by either the
+       max-age directive or the Expires header. The s-maxage directive
+       also implies the semantics of the proxy-revalidate directive (see
+       section 14.9.4), i.e., that the shared cache must not use the
+       entry after it becomes stale to respond to a subsequent request
+       without first revalidating it with the origin server. The s-
+       maxage directive is always ignored by a private cache.
+
+   Note that most older caches, not compliant with this specification,
+   do not implement any cache-control directives. An origin server
+   wishing to use a cache-control directive that restricts, but does not
+   prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
+   requirement that the max-age directive overrides the Expires header,
+   and the fact that pre-HTTP/1.1-compliant caches do not observe the
+   max-age directive.
+
+   Other directives allow a user agent to modify the basic expiration
+   mechanism. 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 directive is also included, the client is not willing to
+      accept a stale response.
+
+   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 response
+      that 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. If max-stale is assigned a value,
+      then the client is willing to accept a response that has exceeded
+      its expiration time by no more than the specified number of
+      seconds. If no value is assigned to max-stale, then the client is
+      willing to accept a stale response of any age.
+
+   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 the expiration time of a response, the cache MUST attach a
+   Warning header to the stale response, using Warning 110 (Response is
+   stale).
+
+
+
+Fielding, et al.            Standards Track                   [Page 112]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A cache MAY be configured to return stale responses without
+   validation, but only if this does not conflict with any "MUST"-level
+   requirements concerning cache validation (e.g., a "must-revalidate"
+   cache-control directive).
+
+   If both the new request and the cached entry include "max-age"
+   directives, then the lesser of the two values is used for determining
+   the freshness of the cached entry for that request.
+
+14.9.4 Cache Revalidation and Reload Controls
+
+   Sometimes a user agent might 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 might 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 entry has become corrupted for some reason.
+
+   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 a "no-cache" cache-control directive or, for
+      compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
+      names MUST NOT 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 a "max-age=0" cache-control directive, 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 "max-age=0" cache-control directive, 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
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 113]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      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.
+
+   max-age
+      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
+      might 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.
+
+      However, the choice of validator might 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 can return its now validated copy
+      to the client with a 200 (OK) response. If the server replies with
+      a new entity and cache validator, however, the intermediate cache
+      can 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 with a 200 (OK) response.
+
+      If a request includes the no-cache directive, it SHOULD NOT
+      include min-fresh, max-stale, or max-age.
+
+   only-if-cached
+      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.
+
+   must-revalidate
+      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
+
+
+
+Fielding, et al.            Standards Track                   [Page 114]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      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.
+
+      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. The warning MUST be provided on each unvalidated
+      access, and SHOULD require explicit user confirmation.
+
+   proxy-revalidate
+      The proxy-revalidate directive has the same meaning as the must-
+      revalidate directive, except that it does not apply to non-shared
+      user agent caches. It can be used on a response to an
+      authenticated request to permit the user's cache to store and
+      later return the response without needing to revalidate it (since
+      it has already been authenticated once by that user), while still
+      requiring proxies that service many users to revalidate each time
+      (in order to make sure that each user has been authenticated).
+      Note that such authenticated responses also need the public cache
+      control directive in order to allow them to be cached at all.
+
+14.9.5 No-Transform Directive
+
+   no-transform
+      Implementors of intermediate caches (proxies) have found it useful
+      to convert the media type of certain entity bodies. A non-
+      transparent proxy might, for example, convert between image
+      formats in order to save cache space or to reduce the amount of
+      traffic on a slow link.
+
+      Serious operational problems occur, however, when these
+      transformations are applied to entity bodies intended for certain
+      kinds of applications. For example, applications for medical
+
+
+
+Fielding, et al.            Standards Track                   [Page 115]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      imaging, scientific data analysis and those using end-to-end
+      authentication, all depend on receiving an entity body that is bit
+      for bit identical to the original entity-body.
+
+      Therefore, if a message includes the no-transform directive, an
+      intermediate cache or proxy MUST NOT change those headers that are
+      listed in section 13.5.2 as being subject to the no-transform
+      directive. This implies that the cache or proxy MUST NOT change
+      any aspect of the entity-body that is specified by these headers,
+      including the value of the entity-body itself.
+
+14.9.6 Cache Control Extensions
+
+   The Cache-Control header field can be extended through the use of one
+   or more cache-extension tokens, each with an optional assigned value.
+   Informational extensions (those which do not require a change in
+   cache behavior) MAY be added without changing the semantics of other
+   directives. Behavioral extensions are designed to work by acting as
+   modifiers to the existing base of cache directives. Both the new
+   directive and the standard directive are supplied, such that
+   applications which do not understand the new directive will default
+   to the behavior specified by the standard directive, and those that
+   understand the new directive will recognize it as modifying the
+   requirements associated with the standard directive. In this way,
+   extensions to the cache-control directives can be made without
+   requiring changes to the base protocol.
+
+   This extension mechanism depends on an HTTP cache obeying all of the
+   cache-control directives defined for its native HTTP-version, obeying
+   certain extensions, and ignoring all directives that it does not
+   understand.
+
+   For example, consider a hypothetical new response directive called
+   community which acts as a modifier to the private directive. We
+   define this new directive to mean that, in addition to any non-shared
+   cache, any cache which is shared only by members of the community
+   named within its value may cache the response. An origin server
+   wishing to allow the UCI community to use an otherwise private
+   response in their shared cache(s) could do so by including
+
+       Cache-Control: private, community="UCI"
+
+   A cache seeing this header field will act correctly even if the cache
+   does not understand the community cache-extension, since it will also
+   see and understand the private directive and thus default to the safe
+   behavior.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 116]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Unrecognized cache-directives MUST be ignored; it is assumed that any
+   cache-directive likely to be unrecognized by an HTTP/1.1 cache will
+   be combined with standard directives (or the response's default
+   cacheability) such that the cache behavior will remain minimally
+   correct even if the cache does not understand the extension(s).
+
+14.10 Connection
+
+   The Connection general-header field allows the sender to specify
+   options that are desired for that particular connection and MUST NOT
+   be communicated by proxies over further connections.
+
+   The Connection header has the following grammar:
+
+       Connection = "Connection" ":" 1#(connection-token)
+       connection-token  = token
+
+   HTTP/1.1 proxies MUST parse the Connection header field before a
+   message is forwarded and, for each connection-token in this field,
+   remove any header field(s) from the message with the same name as the
+   connection-token. Connection options are signaled by the presence of
+   a connection-token in the Connection header field, not by any
+   corresponding additional header field(s), since the additional header
+   field may not be sent if there are no parameters associated with that
+   connection option.
+
+   Message headers listed in the Connection header MUST NOT include
+   end-to-end headers, such as Cache-Control.
+
+   HTTP/1.1 defines the "close" connection option for the sender to
+   signal that the connection will be closed after completion of the
+   response. For example,
+
+       Connection: close
+
+   in either the request or the response header fields indicates that
+   the connection SHOULD NOT be considered `persistent' (section 8.1)
+   after the current request/response is complete.
+
+   HTTP/1.1 applications that do not support persistent connections MUST
+   include the "close" connection option in every message.
+
+   A system receiving an HTTP/1.0 (or lower-version) message that
+   includes a Connection header MUST, for each connection-token in this
+   field, remove and ignore any header field(s) from the message with
+   the same name as the connection-token. This protects against mistaken
+   forwarding of such header fields by pre-HTTP/1.1 proxies. See section
+   19.6.2.
+
+
+
+Fielding, et al.            Standards Track                   [Page 117]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.11 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 entity-body, 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 3.5. An example of its use is
+
+       Content-Encoding: gzip
+
+   The content-coding is a characteristic of the entity identified by
+   the Request-URI. Typically, the entity-body is stored with this
+   encoding and is only decoded before rendering or analogous usage.
+   However, a non-transparent proxy MAY modify the content-coding if the
+   new coding is known to be acceptable to the recipient, unless the
+   "no-transform" cache-control directive is present in the message.
+
+   If the content-coding of an entity is not "identity", then the
+   response MUST include a Content-Encoding entity-header (section
+   14.11) that lists the non-identity content-coding(s) used.
+
+   If the content-coding of an entity in a request message is not
+   acceptable to the origin server, the server SHOULD respond with a
+   status code of 415 (Unsupported Media Type).
+
+   If multiple encodings have been applied to an 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.
+
+14.12 Content-Language
+
+   The Content-Language entity-header field describes the natural
+   language(s) of the intended audience for the enclosed entity. Note
+   that this might not be equivalent to all the languages used within
+   the entity-body.
+
+       Content-Language  = "Content-Language" ":" 1#language-tag
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 118]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Language tags are defined in section 3.10. The primary purpose of
+   Content-Language is to allow a user to identify and differentiate
+   entities according to the user's own preferred language. Thus, if the
+   body content is intended only for a Danish-literate audience, the
+   appropriate field is
+
+       Content-Language: da
+
+   If no Content-Language is specified, the default is that the content
+   is intended for all language audiences. This might 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 would
+   properly only include "en".
+
+   Content-Language MAY be applied to any media type -- it is not
+   limited to textual documents.
+
+14.13 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 transfer-length of
+   the message-body, unless this is prohibited by the rules in section
+   4.4.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 119]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Any Content-Length greater than or equal to zero is a valid value.
+   Section 4.4 describes how to determine the length of a message-body
+   if a Content-Length is not given.
+
+   Note that 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 sent whenever the message's length can be determined prior
+   to being transferred, unless this is prohibited by the rules in
+   section 4.4.
+
+14.14 Content-Location
+
+   The Content-Location entity-header field MAY be used to supply the
+   resource location for the entity enclosed in the message when that
+   entity is accessible from a location separate from the requested
+   resource's URI. A server SHOULD provide a Content-Location for the
+   variant corresponding to the response entity; especially in the case
+   where a resource has multiple entities associated with it, and those
+   entities actually have separate locations by which they might be
+   individually accessed, the server SHOULD provide a Content-Location
+   for the particular variant which is returned.
+
+       Content-Location = "Content-Location" ":"
+                         ( absoluteURI | relativeURI )
+
+   The value of Content-Location also defines the base URI for the
+   entity.
+
+   The Content-Location value is not a replacement for the original
+   requested URI; it is only a statement of the location of the resource
+   corresponding to this particular entity at the time of the request.
+   Future requests MAY specify the Content-Location URI as the request-
+   URI if the desire is to identify the source of that particular
+   entity.
+
+   A cache cannot assume that an entity with a Content-Location
+   different from the URI used to retrieve it can be used to respond to
+   later requests on that Content-Location URI. However, the Content-
+   Location can be used to differentiate between multiple entities
+   retrieved from a single requested resource, as described in section
+   13.6.
+
+   If the Content-Location is a relative URI, the relative URI is
+   interpreted relative to the Request-URI.
+
+   The meaning of the Content-Location header in PUT or POST requests is
+   undefined; servers are free to ignore it in those cases.
+
+
+
+Fielding, et al.            Standards Track                   [Page 120]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.15 Content-MD5
+
+   The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
+   an MD5 digest of the entity-body for the purpose of providing an
+   end-to-end message integrity check (MIC) of the entity-body. (Note: a
+   MIC is good for detecting accidental modification of the entity-body
+   in transit, but is not proof against malicious attacks.)
+
+        Content-MD5   = "Content-MD5" ":" md5-digest
+        md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>
+
+   The Content-MD5 header field MAY be generated by an origin server or
+   client to function as an integrity check of the entity-body. Only
+   origin servers or clients 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-coding that has been applied, but not including
+   any transfer-encoding applied to the message-body. If the message 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.
+
+   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.
+
+   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. The Transfer-Encoding header field is not allowed within
+   body-parts.
+
+   Conversion of all line breaks to CRLF MUST NOT be done before
+   computing or checking the digest: the line break convention used in
+   the text actually transmitted MUST be left unaltered when computing
+   the digest.
+
+
+
+Fielding, et al.            Standards Track                   [Page 121]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      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.
+
+14.16 Content-Range
+
+   The Content-Range entity-header is sent with a partial entity-body to
+   specify where in the full entity-body the partial body should be
+   applied. Range units are defined in section 3.12.
+
+       Content-Range = "Content-Range" ":" content-range-spec
+
+       content-range-spec      = byte-content-range-spec
+       byte-content-range-spec = bytes-unit SP
+                                 byte-range-resp-spec "/"
+                                 ( instance-length | "*" )
+
+       byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
+                                      | "*"
+       instance-length           = 1*DIGIT
+
+   The header SHOULD indicate the total length of the full entity-body,
+   unless this length is unknown or difficult to determine. The asterisk
+   "*" character means that the instance-length is unknown at the time
+   when the response was generated.
+
+   Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
+   range-resp-spec MUST 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 with a byte-range-resp-spec whose last-
+   byte-pos value is less than its first-byte-pos value, or whose
+   instance-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.
+
+   A server sending a response with status code 416 (Requested range not
+   satisfiable) SHOULD include a Content-Range field with a byte-range-
+   resp-spec of "*". The instance-length specifies the current length of
+
+
+
+Fielding, et al.            Standards Track                   [Page 122]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the selected resource. A response with status code 206 (Partial
+   Content) MUST NOT include a Content-Range field with a byte-range-
+   resp-spec of "*".
+
+   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
+
+   When an HTTP message includes the content of a single range (for
+   example, a response to a request for a single range, or to a 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.1 206 Partial content
+       Date: Wed, 15 Nov 1995 06:25:24 GMT
+       Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+       Content-Range: bytes 21010-47021/47022
+       Content-Length: 26012
+       Content-Type: image/gif
+
+   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 message. The multipart
+   media type used for this purpose is "multipart/byteranges" as defined
+   in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
+
+   A response to a request for a single range MUST NOT be sent using the
+   multipart/byteranges media type.  A response to a request for
+   multiple ranges, whose result is a single range, MAY be sent as a
+   multipart/byteranges media type with one part. A client that cannot
+   decode a multipart/byteranges message MUST 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.
+
+
+
+Fielding, et al.            Standards Track                   [Page 123]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the server ignores a byte-range-spec because it is syntactically
+   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 entity).
+
+   If the server receives a request (other than one including an If-
+   Range request-header field) with an unsatisfiable Range request-
+   header field (that is, all of whose byte-range-spec values have a
+   first-byte-pos value greater than the current length of the selected
+   resource), it SHOULD return a response code of 416 (Requested range
+   not satisfiable) (section 10.4.17).
+
+      Note: clients cannot depend on servers to send a 416 (Requested
+      range not satisfiable) response instead of a 200 (OK) response for
+      an unsatisfiable Range request-header, since not all servers
+      implement this request-header.
+
+14.17 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
+
+   Media types are defined in section 3.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 7.2.1.
+
+14.18 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
+   3.3.1; it MUST be sent in RFC 1123 [8]-date format.
+
+       Date  = "Date" ":" HTTP-date
+
+   An example is
+
+       Date: Tue, 15 Nov 1994 08:12:31 GMT
+
+   Origin servers MUST include a Date header field in all responses,
+   except in these cases:
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 124]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      1. If the response status code is 100 (Continue) or 101 (Switching
+         Protocols), the response MAY include a Date header field, at
+         the server's option.
+
+      2. If the response status code conveys a server error, e.g. 500
+         (Internal Server Error) or 503 (Service Unavailable), and it is
+         inconvenient or impossible to generate a valid Date.
+
+      3. If the server does not have a clock that can provide a
+         reasonable approximation of the current time, its responses
+         MUST NOT include a Date header field. In this case, the rules
+         in section 14.18.1 MUST be followed.
+
+   A received message that does not have a Date header field MUST be
+   assigned one by the recipient if the message will be cached by that
+   recipient or gatewayed via a protocol which requires a Date. An HTTP
+   implementation without a clock MUST NOT cache responses without
+   revalidating them on every use. An HTTP cache, especially a shared
+   cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
+   clock with a reliable external standard.
+
+   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 client without a clock MUST NOT send a Date
+   header field in a request.
+
+   The HTTP-date sent in a Date header SHOULD NOT represent a date and
+   time subsequent to the generation of the message. It SHOULD represent
+   the best available approximation of the date and time of message
+   generation, unless the implementation has no means of generating a
+   reasonably accurate date and time. In theory, the date ought to
+   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.
+
+14.18.1 Clockless Origin Server Operation
+
+   Some origin server implementations might not have a clock available.
+   An origin server without a clock MUST NOT assign Expires or Last-
+   Modified values to a response, unless these values were associated
+   with the resource by a system or user with a reliable clock. It MAY
+   assign an Expires value that is known, at or before server
+   configuration time, to be in the past (this allows "pre-expiration"
+   of responses without storing separate Expires values for each
+   resource).
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 125]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.19 ETag
+
+   The ETag response-header field provides the current value of the
+   entity tag for the requested variant. The headers used with entity
+   tags are described in sections 14.24, 14.26 and 14.44. The entity tag
+   MAY be used for comparison with other entities from the same resource
+   (see section 13.3.3).
+
+      ETag = "ETag" ":" entity-tag
+
+   Examples:
+
+      ETag: "xyzzy"
+      ETag: W/"xyzzy"
+      ETag: ""
+
+14.20 Expect
+
+   The Expect request-header field is used to indicate that particular
+   server behaviors are required by the client.
+
+      Expect       =  "Expect" ":" 1#expectation
+
+      expectation  =  "100-continue" | expectation-extension
+      expectation-extension =  token [ "=" ( token | quoted-string )
+                               *expect-params ]
+      expect-params =  ";" token [ "=" ( token | quoted-string ) ]
+
+
+   A server that does not understand or is unable to comply with any of
+   the expectation values in the Expect field of a request MUST respond
+   with appropriate error status. The server MUST respond with a 417
+   (Expectation Failed) status if any of the expectations cannot be met
+   or, if there are other problems with the request, some other 4xx
+   status.
+
+   This header field is defined with extensible syntax to allow for
+   future extensions. If a server receives a request containing an
+   Expect field that includes an expectation-extension that it does not
+   support, it MUST respond with a 417 (Expectation Failed) status.
+
+   Comparison of expectation values is case-insensitive for unquoted
+   tokens (including the 100-continue token), and is case-sensitive for
+   quoted-string expectation-extensions.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 126]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
+   return a 417 (Expectation Failed) status if it receives a request
+   with an expectation that it cannot meet. However, the Expect
+   request-header itself is end-to-end; it MUST be forwarded if the
+   request is forwarded.
+
+   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
+   Expect header.
+
+   See section 8.2.3 for the use of the 100 (continue) status.
+
+14.21 Expires
+
+   The Expires entity-header field gives the date/time after which the
+   response is considered stale. A stale cache entry may not normally be
+   returned by a cache (either a proxy cache or a user agent cache)
+   unless it is first validated with the origin server (or with an
+   intermediate cache that has a fresh copy of the entity). See section
+   13.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 3.3.1; it MUST be in RFC 1123 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 (see section 14.9.3), 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 sends an
+   Expires date that is equal to the Date header value. (See the rules
+   for expiration calculations in section 13.2.4.)
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 127]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   To mark a response as "never expires," an origin server sends an
+   Expires date approximately one year from the time the response is
+   sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
+   year in the future.
+
+   The presence of an Expires header field with a date value of some
+   time in the future on a response that otherwise would by default be
+   non-cacheable indicates that the response is cacheable, unless
+   indicated otherwise by a Cache-Control header field (section 14.9).
+
+14.22 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 [9] as updated by RFC 1123 [8]:
+
+       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.
+
+   The client SHOULD NOT send the From header field without the user's
+   approval, as it might 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.
+
+14.23 Host
+
+   The Host request-header field specifies the Internet host and port
+   number of the resource being requested, as obtained from the original
+   URI given by the user or referring resource (generally an HTTP URL,
+
+
+
+Fielding, et al.            Standards Track                   [Page 128]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   as described in section 3.2.2). The Host field value MUST represent
+   the naming authority 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 3.2.2
+
+   A "host" without any trailing port information implies the default
+   port for the service requested (e.g., "80" for an HTTP URL). For
+   example, a request on the origin server for
+   <http://www.w3.org/pub/WWW/> would properly include:
+
+       GET /pub/WWW/ HTTP/1.1
+       Host: www.w3.org
+
+   A client MUST include a Host header field in all HTTP/1.1 request
+   messages . If the requested URI does not include an Internet host
+   name for the service being requested, then the Host header field MUST
+   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
+   request message it forwards does contain an appropriate Host header
+   field that identifies the service being requested by the proxy. All
+   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
+   status code to any HTTP/1.1 request message which lacks a Host header
+   field.
+
+   See sections 5.2 and 19.6.1.1 for other requirements relating to
+   Host.
+
+14.24 If-Match
+
+   The If-Match request-header field is used with a method to make it
+   conditional. A client that has one or more entities previously
+   obtained from the resource can verify that one of those entities is
+   current by including a list of their associated entity tags in the
+   If-Match header field. Entity tags are defined in section 3.11. 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 version of a resource. As a special case, the value "*"
+   matches any current entity of the resource.
+
+       If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-Match header) on that resource, or if "*" is given
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 129]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   and any current entity exists for that resource, then the server MAY
+   perform the requested method as if the If-Match header field did not
+   exist.
+
+   A server MUST use the strong comparison function (see section 13.3.3)
+   to compare the entity tags in If-Match.
+
+   If none of the entity tags match, or if "*" is given and no current
+   entity exists, the server MUST NOT perform the requested method, and
+   MUST return a 412 (Precondition Failed) response. This behavior is
+   most useful when the client wants to prevent an updating method, such
+   as PUT, from modifying a resource that has changed since the client
+   last retrieved it.
+
+   If the request would, without the If-Match header field, result in
+   anything other than a 2xx or 412 status, then the If-Match header
+   MUST be ignored.
+
+   The meaning of "If-Match: *" is that the method SHOULD be performed
+   if the representation selected by the origin server (or by a cache,
+   possibly using the Vary mechanism, see section 14.44) exists, and
+   MUST NOT be performed if the representation does not exist.
+
+   A request intended to update a resource (e.g., a PUT) MAY include an
+   If-Match header field to signal that the request method MUST NOT be
+   applied if the entity corresponding to the If-Match value (a single
+   entity tag) is no longer a representation of that resource. This
+   allows the user to indicate that they do not wish the request to be
+   successful if the resource has been changed without their knowledge.
+   Examples:
+
+       If-Match: "xyzzy"
+       If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+       If-Match: *
+
+   The result of a request having both an If-Match header field and
+   either an If-None-Match or an If-Modified-Since header fields is
+   undefined by this specification.
+
+14.25 If-Modified-Since
+
+   The If-Modified-Since request-header field is used with a method to
+   make it conditional: if the requested variant has not been modified
+   since the time specified in this field, an entity will not be
+   returned from the server; instead, a 304 (not modified) response will
+   be returned without any message-body.
+
+       If-Modified-Since = "If-Modified-Since" ":" HTTP-date
+
+
+
+Fielding, et al.            Standards Track                   [Page 130]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 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 variant has been modified since the If-Modified-Since
+         date, the response is exactly the same as for a normal GET.
+
+      c) If the variant has not been modified since a valid If-
+         Modified-Since date, the server SHOULD 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: The Range request-header field modifies the meaning of If-
+      Modified-Since; see section 14.35 for full details.
+
+      Note: If-Modified-Since times are interpreted by the server, whose
+      clock might not be synchronized with the client.
+
+      Note: When handling an If-Modified-Since header field, some
+      servers will use an exact date comparison function, rather than a
+      less-than function, for deciding whether to send a 304 (Not
+      Modified) response. To get best results when sending an If-
+      Modified-Since header field for cache validation, clients are
+      advised to use the exact date string received in a previous Last-
+      Modified header field whenever possible.
+
+      Note: 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 problems
+      due to the different encodings 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
+
+
+
+Fielding, et al.            Standards Track                   [Page 131]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      possibility of clock-skew-related problems if the If-Modified-
+      Since 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.
+
+   The result of a request having both an If-Modified-Since header field
+   and either an If-Match or an If-Unmodified-Since header fields is
+   undefined by this specification.
+
+14.26 If-None-Match
+
+   The If-None-Match request-header field is used with a method to make
+   it conditional. A client that has one or more entities previously
+   obtained from the resource can verify that none of those entities is
+   current by including a list of their associated entity tags in the
+   If-None-Match header field. The purpose of this feature is to allow
+   efficient updates of cached information with a minimum amount of
+   transaction overhead. It is also used to prevent a method (e.g. PUT)
+   from inadvertently modifying an existing resource when the client
+   believes that the resource does not exist.
+
+   As a special case, the value "*" matches any current entity of the
+   resource.
+
+       If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-None-Match header) on that resource, or if "*" is
+   given and any current entity exists for that resource, then the
+   server MUST NOT perform the requested method, unless required to do
+   so because the resource's modification date fails to match that
+   supplied in an If-Modified-Since header field in the request.
+   Instead, if the request method was GET or HEAD, the server SHOULD
+   respond with a 304 (Not Modified) response, including the cache-
+   related header fields (particularly ETag) of one of the entities that
+   matched. For all other request methods, the server MUST respond with
+   a status of 412 (Precondition Failed).
+
+   See section 13.3.3 for rules on how to determine if two entities tags
+   match. The weak comparison function can only be used with GET or HEAD
+   requests.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 132]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If none of the entity tags match, then the server MAY perform the
+   requested method as if the If-None-Match header field did not exist,
+   but MUST also ignore any If-Modified-Since header field(s) in the
+   request. That is, if no entity tags match, then the server MUST NOT
+   return a 304 (Not Modified) response.
+
+   If the request would, without the If-None-Match header field, result
+   in anything other than a 2xx or 304 status, then the If-None-Match
+   header MUST be ignored. (See section 13.3.4 for a discussion of
+   server behavior when both If-Modified-Since and If-None-Match appear
+   in the same request.)
+
+   The meaning of "If-None-Match: *" is that the method MUST NOT be
+   performed if the representation selected by the origin server (or by
+   a cache, possibly using the Vary mechanism, see section 14.44)
+   exists, and SHOULD be performed if the representation does not exist.
+   This feature is intended to be useful in preventing races between PUT
+   operations.
+
+   Examples:
+
+       If-None-Match: "xyzzy"
+       If-None-Match: W/"xyzzy"
+       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
+       If-None-Match: *
+
+   The result of a request having both an If-None-Match header field and
+   either an If-Match or an If-Unmodified-Since header fields is
+   undefined by this specification.
+
+14.27 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'.
+
+        If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 133]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the client has no entity tag for an entity, but does have a Last-
+   Modified date, it MAY use that date in an If-Range header. (The
+   server can distinguish between a valid HTTP-date and any form of
+   entity-tag by examining no more than two characters.) 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.
+
+14.28 If-Unmodified-Since
+
+   The If-Unmodified-Since request-header field is used with a method to
+   make it conditional. If the requested resource 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 variant has been modified since the specified time,
+   the server MUST NOT perform the requested operation, and MUST return
+   a 412 (Precondition Failed).
+
+      If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
+
+   An example of the field is:
+
+       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 or 412 status, the
+   If-Unmodified-Since header SHOULD be ignored.
+
+   If the specified date is invalid, the header is ignored.
+
+   The result of a request having both an If-Unmodified-Since header
+   field and either an If-None-Match or an If-Modified-Since header
+   fields is undefined by this specification.
+
+14.29 Last-Modified
+
+   The Last-Modified entity-header field indicates the date and time at
+   which the origin server believes the variant was last modified.
+
+       Last-Modified  = "Last-Modified" ":" HTTP-date
+
+
+
+Fielding, et al.            Standards Track                   [Page 134]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 origin server 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.
+
+   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
+
+14.30 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 URI for automatic redirection to the resource. The
+   field value consists of a single absolute URI.
+
+       Location       = "Location" ":" absoluteURI
+
+   An example is:
+
+       Location: http://www.w3.org/pub/WWW/People.html
+
+      Note: The Content-Location header field (section 14.14) 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. Also see section 13.10 for cache
+      requirements of some methods.
+
+
+
+Fielding, et al.            Standards Track                   [Page 135]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.31 Max-Forwards
+
+   The Max-Forwards request-header field provides a mechanism with the
+   TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
+   number of proxies or gateways that 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 or OPTIONS request
+   containing a Max-Forwards header field MUST check and update its
+   value prior to forwarding the request. If the received value is zero
+   (0), the recipient MUST NOT forward the request; instead, it MUST
+   respond as the final recipient. If the received Max-Forwards value is
+   greater than zero, then the forwarded message MUST contain an updated
+   Max-Forwards field with a value decremented by one (1).
+
+   The Max-Forwards header field MAY 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.
+
+14.32 Pragma
+
+   The Pragma general-header field is used to include implementation-
+   specific directives that might 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 [ "=" ( token | quoted-string ) ]
+
+   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 14.9) and is defined here for backward 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.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 136]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Pragma directives MUST be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives might 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 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.
+
+      Note: because the meaning of "Pragma: no-cache as a response
+      header field is not actually specified, it does not provide a
+      reliable replacement for "Cache-Control: no-cache" in a response
+
+14.33 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-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. Unlike
+   WWW-Authenticate, the Proxy-Authenticate header field applies only to
+   the current connection and SHOULD NOT be passed on to downstream
+   clients. However, an intermediate proxy might need to obtain its own
+   credentials by requesting them from the downstream client, which in
+   some circumstances will appear as if the proxy is forwarding the
+   Proxy-Authenticate header field.
+
+14.34 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
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43] . Unlike
+   Authorization, the Proxy-Authorization header field applies only to
+   the next outbound proxy that demanded authentication using the Proxy-
+   Authenticate field. When multiple proxies are used in a chain, the
+
+
+
+Fielding, et al.            Standards Track                   [Page 137]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Proxy-Authorization header field is consumed by the first outbound
+   proxy that was expecting to receive credentials. A proxy MAY relay
+   the credentials from the client request to the next proxy if that is
+   the mechanism by which the proxies cooperatively authenticate a given
+   request.
+
+14.35 Range
+
+14.35.1 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 in
+   the entity-body (not necessarily the same as the message-body).
+
+   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 syntactically invalid. The recipient of a byte-range-
+   set that includes one or more syntactically invalid byte-range-spec
+   values MUST ignore the header field that includes that byte-range-
+   set.
+
+   If the last-byte-pos value is absent, or if the value is greater than
+   or equal to the current length of the entity-body, last-byte-pos is
+   taken to be equal to one less than the current length of the entity-
+   body in bytes.
+
+   By its choice of last-byte-pos, a client can limit the number of
+   bytes retrieved without knowing the size of the entity.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 138]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       suffix-byte-range-spec = "-" suffix-length
+       suffix-length = 1*DIGIT
+
+   A suffix-byte-range-spec is used to specify the suffix of the
+   entity-body, of a length given by the suffix-length value. (That is,
+   this form specifies the last N bytes of an entity-body.) If the
+   entity is shorter than the specified suffix-length, the entire
+   entity-body is used.
+
+   If a syntactically valid byte-range-set includes at least one byte-
+   range-spec whose first-byte-pos is less than the current length of
+   the entity-body, or at least one suffix-byte-range-spec with a non-
+   zero suffix-length, then the byte-range-set is satisfiable.
+   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
+   is unsatisfiable, the server SHOULD return a response with a status
+   of 416 (Requested range not satisfiable). Otherwise, the server
+   SHOULD return a response with a status of 206 (Partial Content)
+   containing the satisfiable ranges of the entity-body.
+
+   Examples of byte-ranges-specifier values (assuming an entity-body 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
+
+14.35.2 Range Retrieval Requests
+
+   HTTP retrieval requests using conditional or unconditional GET
+   methods MAY request one or more sub-ranges of the entity, instead of
+   the entire entity, using the Range request header, which applies to
+   the entity returned as the result of the request:
+
+      Range = "Range" ":" ranges-specifier
+
+
+
+Fielding, et al.            Standards Track                   [Page 139]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A server MAY ignore the Range header. However, HTTP/1.1 origin
+   servers and intermediate caches ought to support byte ranges when
+   possible, since Range supports efficient recovery from partially
+   failed transfers, and 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-None-Match, 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.
+
+   In some cases, it might be more appropriate to use the If-Range
+   header (see section 14.27) in addition to the Range header.
+
+   If a proxy that supports ranges receives a Range request, forwards
+   the request to an inbound server, and receives an entire entity in
+   reply, it SHOULD only return the requested range to its client. It
+   SHOULD store the entire received response in its cache if that is
+   consistent with its cache allocation policies.
+
+14.36 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 (the "referrer", although the
+   header field is misspelled.) The Referer request-header 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
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 140]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the field value is a relative URI, it SHOULD be interpreted
+   relative to the Request-URI. The URI MUST NOT include a fragment. See
+   section 15.1.3 for security considerations.
+
+14.37 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. This field MAY also be used
+   with any 3xx (Redirection) response to indicate the minimum time the
+   user-agent is asked wait before issuing the redirected request. 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: Fri, 31 Dec 1999 23:59:59 GMT
+       Retry-After: 120
+
+   In the latter example, the delay is 2 minutes.
+
+14.38 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 3.8) and comments
+   identifying the server and any significant subproducts. The product
+   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 modify the Server response-header. Instead, it
+   SHOULD include a Via field (as described in section 14.45).
+
+      Note: Revealing the specific software version of the server might
+      allow the server machine to become more vulnerable to attacks
+      against software that is known to contain security holes. Server
+      implementors are encouraged to make this field a configurable
+      option.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 141]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.39 TE
+
+   The TE request-header field indicates what extension transfer-codings
+   it is willing to accept in the response and whether or not it is
+   willing to accept trailer fields in a chunked transfer-coding. Its
+   value may consist of the keyword "trailers" and/or a comma-separated
+   list of extension transfer-coding names with optional accept
+   parameters (as described in section 3.6).
+
+       TE        = "TE" ":" #( t-codings )
+       t-codings = "trailers" | ( transfer-extension [ accept-params ] )
+
+   The presence of the keyword "trailers" indicates that the client is
+   willing to accept trailer fields in a chunked transfer-coding, as
+   defined in section 3.6.1. This keyword is reserved for use with
+   transfer-coding values even though it does not itself represent a
+   transfer-coding.
+
+   Examples of its use are:
+
+       TE: deflate
+       TE:
+       TE: trailers, deflate;q=0.5
+
+   The TE header field only applies to the immediate connection.
+   Therefore, the keyword MUST be supplied within a Connection header
+   field (section 14.10) whenever TE is present in an HTTP/1.1 message.
+
+   A server tests whether a transfer-coding is acceptable, according to
+   a TE field, using these rules:
+
+      1. The "chunked" transfer-coding is always acceptable. If the
+         keyword "trailers" is listed, the client indicates that it is
+         willing to accept trailer fields in the chunked response on
+         behalf of itself and any downstream clients. The implication is
+         that, if given, the client is stating that either all
+         downstream clients are willing to accept trailer fields in the
+         forwarded response, or that it will attempt to buffer the
+         response on behalf of downstream recipients.
+
+         Note: HTTP/1.1 does not define any means to limit the size of a
+         chunked response such that a client can be assured of buffering
+         the entire response.
+
+      2. If the transfer-coding being tested is one of the transfer-
+         codings listed in the TE field, then it is acceptable unless it
+         is accompanied by a qvalue of 0. (As defined in section 3.9, a
+         qvalue of 0 means "not acceptable.")
+
+
+
+Fielding, et al.            Standards Track                   [Page 142]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      3. If multiple transfer-codings are acceptable, then the
+         acceptable transfer-coding with the highest non-zero qvalue is
+         preferred.  The "chunked" transfer-coding always has a qvalue
+         of 1.
+
+   If the TE field-value is empty or if no TE field is present, the only
+   transfer-coding  is "chunked". A message with no transfer-coding is
+   always acceptable.
+
+14.40 Trailer
+
+   The Trailer general field value indicates that the given set of
+   header fields is present in the trailer of a message encoded with
+   chunked transfer-coding.
+
+       Trailer  = "Trailer" ":" 1#field-name
+
+   An HTTP/1.1 message SHOULD include a Trailer header field in a
+   message using chunked transfer-coding with a non-empty trailer. Doing
+   so allows the recipient to know which header fields to expect in the
+   trailer.
+
+   If no Trailer header field is present, the trailer SHOULD NOT include
+   any header fields. See section 3.6.1 for restrictions on the use of
+   trailer fields in a "chunked" transfer-coding.
+
+   Message header fields listed in the Trailer header field MUST NOT
+   include the following header fields:
+
+      . Transfer-Encoding
+
+      . Content-Length
+
+      . Trailer
+
+14.41 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-coding in that the transfer-coding is a
+   property of the message, not of the entity.
+
+     Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding
+
+   Transfer-codings are defined in section 3.6. An example is:
+
+     Transfer-Encoding: chunked
+
+
+
+Fielding, et al.            Standards Track                   [Page 143]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If multiple encodings have been applied to an entity, the transfer-
+   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.
+
+   Many older HTTP/1.0 applications do not understand the Transfer-
+   Encoding header.
+
+14.42 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 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 14.10) whenever Upgrade is present in an
+   HTTP/1.1 message.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 144]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 3.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.
+
+14.43 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. User agents SHOULD include this field with
+   requests. The field can contain multiple product tokens (section 3.8)
+   and comments identifying the agent and any subproducts 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
+
+14.44 Vary
+
+   The Vary field value indicates the set of request-header fields that
+   fully determines, while the response is fresh, whether a cache is
+   permitted to use the response to reply to a subsequent request
+   without revalidation. For uncacheable or stale responses, the Vary
+   field value advises the user agent about the criteria that were used
+   to select the representation. A Vary field value of "*" implies that
+   a cache cannot determine from the request headers of a subsequent
+   request whether this response is the appropriate representation. See
+   section 13.6 for use of the Vary header field by caches.
+
+       Vary  = "Vary" ":" ( "*" | 1#field-name )
+
+   An HTTP/1.1 server SHOULD include a Vary header field with any
+   cacheable response that is subject to server-driven negotiation.
+   Doing so allows a cache to properly interpret future requests on that
+   resource and informs the user agent about the presence of negotiation
+
+
+
+Fielding, et al.            Standards Track                   [Page 145]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   on that resource. A server MAY include a Vary header field with a
+   non-cacheable response that is subject to server-driven negotiation,
+   since this might provide the user agent with useful information about
+   the dimensions over which the response varies at the time of the
+   response.
+
+   A Vary field value consisting of a list of field-names signals that
+   the representation selected for the response is based on a selection
+   algorithm which considers ONLY the listed request-header field values
+   in selecting the most appropriate representation. A cache MAY assume
+   that the same selection will be made for future requests with the
+   same values for the listed field names, for the duration of time for
+   which the response is fresh.
+
+   The field-names given are not limited to the set of standard
+   request-header fields defined by this specification. Field names are
+   case-insensitive.
+
+   A Vary field value of "*" signals that unspecified parameters not
+   limited to the request-headers (e.g., the network address of the
+   client), play a role in the selection of the response representation.
+   The "*" value MUST NOT be generated by a proxy server; it may only be
+   generated by an origin server.
+
+14.45  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 [9] and is intended to be used for tracking message forwards,
+   avoiding 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.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 146]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 represents 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 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
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 147]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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.
+
+14.46 Warning
+
+   The Warning general-header field is used to carry additional
+   information about the status or transformation of a message which
+   might not be reflected in the message. This information is typically
+   used to warn about a possible lack of semantic transparency from
+   caching operations or transformations applied to the entity body of
+   the message.
+
+   Warning headers are sent with responses using:
+
+       Warning    = "Warning" ":" 1#warning-value
+
+       warning-value = warn-code SP warn-agent SP warn-text
+                                             [SP warn-date]
+
+       warn-code  = 3DIGIT
+       warn-agent = ( host [ ":" port ] ) | pseudonym
+                       ; the name or pseudonym of the server adding
+                       ; the Warning header, for use in debugging
+       warn-text  = quoted-string
+       warn-date  = <"> HTTP-date <">
+
+   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-8859-1.
+
+   If a character set other than ISO-8859-1 is used, it MUST be encoded
+   in the warn-text using the method described in RFC 2047 [14].
+
+   Warning headers can in general be applied to any message, however
+   some specific warn-codes are specific to caches and can only be
+   applied to response messages. New Warning headers SHOULD be added
+   after any existing Warning headers. A cache MUST NOT delete any
+   Warning header that it received with a message. However, if a cache
+   successfully validates a cache entry, it SHOULD remove any Warning
+   headers previously attached to that entry except as specified for
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 148]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   specific Warning codes. 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 ought to inform the user of as many of them as possible, in the
+   order that they appear in the response. If it is not possible to
+   inform the user of all of the warnings, the user agent SHOULD follow
+   these heuristics:
+
+      - 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.
+
+   Requirements for the behavior of caches with respect to Warnings are
+   stated in section 13.1.2.
+
+   This is a list of the currently-defined warn-codes, each with a
+   recommended warn-text in English, and a description of its meaning.
+
+   110 Response is stale
+     MUST be included whenever the returned response is stale.
+
+   111 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.
+
+   112 Disconnected operation
+     SHOULD be included if the cache is intentionally disconnected from
+     the rest of the network for a period of time.
+
+   113 Heuristic expiration
+     MUST be included if the cache heuristically chose a freshness
+     lifetime greater than 24 hours and the response's age is greater
+     than 24 hours.
+
+   199 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, besides presenting the warning to
+     the user.
+
+
+
+Fielding, et al.            Standards Track                   [Page 149]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   214 Transformation applied
+     MUST be added by an intermediate cache or proxy if it applies any
+     transformation changing the content-coding (as specified in the
+     Content-Encoding header) or media-type (as specified in the
+     Content-Type header) of the response, or the entity-body of the
+     response, unless this Warning code already appears in the response.
+
+   299 Miscellaneous persistent 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.
+
+   If an implementation sends a message with one or more Warning headers
+   whose version is HTTP/1.0 or lower, then the sender MUST include in
+   each warning-value a warn-date that matches the date in the response.
+
+   If an implementation receives a message with a warning-value that
+   includes a warn-date, and that warn-date is different from the Date
+   value in the response, then that warning-value MUST be deleted from
+   the message before storing, forwarding, or using it. (This prevents
+   bad consequences of naive caching of Warning header fields.) If all
+   of the warning-values are deleted for this reason, the Warning header
+   MUST be deleted as well.
+
+14.47 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 "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. User
+   agents are advised to take special care in parsing the WWW-
+   Authenticate field value as it might contain more than one challenge,
+   or if more than one WWW-Authenticate header field is provided, the
+   contents of a challenge itself can contain a comma-separated list of
+   authentication parameters.
+
+15 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 solutions to the problems revealed, though it does make
+   some suggestions for reducing security risks.
+
+
+
+Fielding, et al.            Standards Track                   [Page 150]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.1 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 implementors be particularly careful in this area.
+   History shows that errors in this area often create serious security
+   and/or privacy problems and generate highly adverse publicity for the
+   implementor's company.
+
+15.1.1 Abuse of Server Log Information
+
+   A server is in the position to save personal data about a user's
+   requests which might identify their reading patterns or subjects of
+   interest. This information is clearly confidential in nature and its
+   handling can 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.
+
+15.1.2 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 might allow the
+   server machine to become more vulnerable to attacks against software
+   that is known to contain security holes. Implementors 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.
+
+   The Referer header 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
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 151]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the Referer. Even when the personal information has been removed, the
+   Referer header might 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.
+
+   The User-Agent (section 14.43) or Server (section 14.38) header
+   fields can sometimes be used to determine that a specific client or
+   server have a particular security hole which might be exploited.
+   Unfortunately, this same information is often used for other valuable
+   purposes for which HTTP currently has no better mechanism.
+
+15.1.3 Encoding Sensitive Information in URI's
+
+   Because the source of a link might be private information or might
+   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.
+
+   Clients SHOULD NOT include a Referer header field in a (non-secure)
+   HTTP request if the referring page was transferred with a secure
+   protocol.
+
+   Authors of services which use the HTTP protocol SHOULD NOT use GET
+   based forms for the submission of sensitive data, because this will
+   cause this data to be encoded in the Request-URI. Many existing
+   servers, proxies, and user agents will log the request URI in some
+   place where it might be visible to third parties. Servers can use
+   POST-based form submission instead
+
+15.1.4 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
+   nature, because the understanding of particular languages is often
+
+
+
+Fielding, et al.            Standards Track                   [Page 152]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 or not to start sending Accept-Language headers to a
+   server if it detects, by looking for any Vary response-header fields
+   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 ought to 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.
+
+15.2 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.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 153]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.3 DNS Spoofing
+
+   Clients using HTTP rely heavily on the Domain Name Service, and are
+   thus generally prone to security attacks based on the deliberate
+   mis-association of IP addresses and DNS names. 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. It is proper for these lookups to
+   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 network
+   renumbering is expected to become increasingly common [24], the
+   possibility of this form of 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.
+
+15.4 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.
+
+15.5 Content-Disposition Issues
+
+   RFC 1806 [35], from which the often implemented Content-Disposition
+   (see section 19.5.1) header in HTTP is derived, has a number of very
+   serious security considerations. Content-Disposition is not part of
+   the HTTP standard, but since it is widely implemented, we are
+   documenting its use and risks for implementors. See RFC 2183 [49]
+   (which updates RFC 1806) for details.
+
+
+
+Fielding, et al.            Standards Track                   [Page 154]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.6 Authentication Credentials and Idle Clients
+
+   Existing HTTP clients and user agents typically retain authentication
+   information indefinitely. HTTP/1.1. does not provide a method for a
+   server to direct clients to discard these cached credentials. This is
+   a significant defect that requires further extensions to HTTP.
+   Circumstances under which credential caching can interfere with the
+   application's security model include but are not limited to:
+
+      - Clients which have been idle for an extended period following
+        which the server might wish to cause the client to reprompt the
+        user for credentials.
+
+      - Applications which include a session termination indication
+        (such as a `logout' or `commit' button on a page) after which
+        the server side of the application `knows' that there is no
+        further reason for the client to retain the credentials.
+
+   This is currently under separate study. There are a number of work-
+   arounds to parts of this problem, and we encourage the use of
+   password protection in screen savers, idle time-outs, and other
+   methods which mitigate the security problems inherent in this
+   problem. In particular, user agents which cache credentials are
+   encouraged to provide a readily accessible mechanism for discarding
+   cached credentials under user control.
+
+15.7 Proxies and Caching
+
+   By their very nature, HTTP proxies are men-in-the-middle, and
+   represent an opportunity for man-in-the-middle attacks. Compromise of
+   the systems on which the proxies run can result in serious security
+   and privacy problems. Proxies have access to security-related
+   information, personal information about individual users and
+   organizations, and proprietary information belonging to users and
+   content providers. A compromised proxy, or a proxy implemented or
+   configured without regard to security and privacy considerations,
+   might be used in the commission of a wide range of potential attacks.
+
+   Proxy operators should protect the systems on which proxies run as
+   they would protect any system that contains or transports sensitive
+   information. In particular, log information gathered at proxies often
+   contains highly sensitive personal information, and/or information
+   about organizations. Log information should be carefully guarded, and
+   appropriate guidelines for use developed and followed. (Section
+   15.1.1).
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 155]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Caching proxies provide additional potential vulnerabilities, since
+   the contents of the cache represent an attractive target for
+   malicious exploitation. Because cache contents persist after an HTTP
+   request is complete, an attack on the cache can reveal information
+   long after a user believes that the information has been removed from
+   the network. Therefore, cache contents should be protected as
+   sensitive information.
+
+   Proxy implementors should consider the privacy and security
+   implications of their design and coding decisions, and of the
+   configuration options they provide to proxy operators (especially the
+   default configuration).
+
+   Users of a proxy need to be aware that they are no trustworthier than
+   the people who run the proxy; HTTP itself cannot solve this problem.
+
+   The judicious use of cryptography, when appropriate, may suffice to
+   protect against a broad range of security and privacy attacks. Such
+   cryptography is beyond the scope of the HTTP/1.1 specification.
+
+15.7.1 Denial of Service Attacks on Proxies
+
+   They exist. They are hard to defend against. Research continues.
+   Beware.
+
+16 Acknowledgments
+
+   This specification makes heavy use of the augmented BNF and generic
+   constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
+   reuses many of the definitions provided by Nathaniel Borenstein and
+   Ned Freed for MIME [7]. 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 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:
+
+
+
+Fielding, et al.            Standards Track                   [Page 156]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       Gary Adams                  Ross Patterson
+       Harald Tveit Alvestrand     Albert Lunde
+       Keith Ball                  John C. Mallery
+       Brian Behlendorf            Jean-Philippe Martin-Flatin
+       Paul Burchard               Mitra
+       Maurizio Codogno            David Morris
+       Mike Cowlishaw              Gavin Nicol
+       Roman Czyborra              Bill Perry
+       Michael A. Dolan            Jeffrey Perry
+       David J. Fiander            Scott Powers
+       Alan Freier                 Owen Rees
+       Marc Hedlund                Luigi Rizzo
+       Greg Herlihy                David Robinson
+       Koen Holtman                Marc Salomon
+       Alex Hopmann                Rich Salz
+       Bob Jernigan                Allan M. Schiffman
+       Shel Kaphan                 Jim Seidman
+       Rohit Khare                 Chuck Shotton
+       John Klensin                Eric W. Sink
+       Martijn Koster              Simon E. Spero
+       Alexei Kosut                Richard N. Taylor
+       David M. Kristol            Robert S. Thau
+       Daniel LaLiberte            Bill (BearHeart) Weinman
+       Ben Laurie                  Francois Yergeau
+       Paul J. Leach               Mary Ellen Zurko
+       Daniel DuBois               Josh Cohen
+
+
+   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, and Larry Masinter.
+
+   Most of the specification of ranges is based on work originally done
+   by Ari Luotonen and John Franks, with additional input from Steve
+   Zilles.
+
+   Thanks to the "cave men" of Palo Alto. You know who you are.
+
+   Jim Gettys (the current editor of this document) wishes particularly
+   to thank Roy Fielding, the previous editor of this document, along
+   with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
+   Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
+   Larry Masinter for their help. And thanks go particularly to Jeff
+   Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 157]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
+   Frystyk implemented RFC 2068 early, and we wish to thank them for the
+   discovery of many of the problems that this document attempts to
+   rectify.
+
+17 References
+
+   [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
+       1766, March 1995.
+
+   [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
+       D. and B. Alberti, "The Internet Gopher Protocol (a distributed
+       document search and retrieval protocol)", RFC 1436, March 1993.
+
+   [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
+       1630, June 1994.
+
+   [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+       Locators (URL)", RFC 1738, December 1994.
+
+   [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
+       2.0", RFC 1866, November 1995.
+
+   [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
+       Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+       Extensions (MIME) Part One: Format of Internet Message Bodies",
+       RFC 2045, November 1996.
+
+   [8] Braden, R., "Requirements for Internet Hosts -- Communication
+       Layers", STD 3, RFC 1123, October 1989.
+
+   [9] Crocker, D., "Standard for The Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, August 1982.
+
+   [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
+        Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
+        Functional Specification," (v1.5), Thinking Machines
+        Corporation, April 1990.
+
+   [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
+        June 1995.
+
+   [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
+        Messages", RFC 1036, December 1987.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 158]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
+        977, February 1986.
+
+   [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+        November 1996.
+
+   [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
+        1867, November 1995.
+
+   [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+        August 1982.
+
+   [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
+        November 1996.
+
+   [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
+        959, October 1985.
+
+   [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+        October 1994.
+
+   [20] Sollins, K. and L. Masinter, "Functional Requirements for
+        Uniform Resource Names", RFC 1737, 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, J. and M. Rose, "The Content-MD5 Header Field", RFC
+        1864, October 1995.
+
+   [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
+        1900, February 1996.
+
+   [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
+        1952, May 1996.
+
+
+
+Fielding, et al.            Standards Track                   [Page 159]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
+        Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
+        Dec. 1995. Slightly revised version of paper in Proc. 2nd
+        International WWW Conference '94: Mosaic and the Web, Oct. 1994,
+        which is available at
+        http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
+        ency.html.
+
+   [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
+        Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
+        ISI Research Report ISI/RR-98-463, (original report dated Aug.
+        1996), USC/Information Sciences Institute, August 1998.
+
+   [28] Mills, D., "Network Time Protocol (Version 3) Specification,
+        Implementation and Analysis", RFC 1305, March 1992.
+
+   [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
+        version 1.3", RFC 1951, May 1996.
+
+   [30] S. Spero, "Analysis of HTTP Performance Problems,"
+        http://sunsite.unc.edu/mdma-release/http-prob.html.
+
+   [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
+        Specification version 3.3", RFC 1950, May 1996.
+
+   [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
+        Digest Access Authentication", RFC 2069, January 1997.
+
+   [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+        2068, January 1997.
+
+   [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [35] Troost, R. and Dorner, S., "Communicating Presentation
+        Information in Internet Messages: The Content-Disposition
+        Header", RFC 1806, June 1995.
+
+   [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
+        Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
+        [jg639]
+
+   [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
+        1997. [jg640]
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 160]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
+        ISO-10646", RFC 2279, January 1998. [jg641]
+
+   [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
+        Lie, H., and C. Lilley. "Network Performance Effects of
+        HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
+        France, September 1997.[jg642]
+
+   [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Two: Media Types", RFC 2046, November
+        1996. [jg643]
+
+   [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
+        BCP 18, RFC 2277, January 1998. [jg644]
+
+   [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
+        August 1998. [jg645]
+
+   [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+        Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
+        Authentication: Basic and Digest Access Authentication", RFC
+        2617, June 1999. [jg646]
+
+   [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
+        servers," Work in Progress. [jg647]
+
+   [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
+        Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
+        1997.
+
+   [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
+        (HTCPCP/1.0)", RFC 2324, 1 April 1998.
+
+   [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Five: Conformance Criteria and Examples",
+        RFC 2049, November 1996.
+
+   [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
+        Information in Internet Messages: The Content-Disposition Header
+        Field", RFC 2183, August 1997.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 161]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+18 Authors' Addresses
+
+   Roy T. Fielding
+   Information and Computer Science
+   University of California, Irvine
+   Irvine, CA 92697-3425, USA
+
+   Fax: +1 (949) 824-1715
+   EMail: fielding@ics.uci.edu
+
+
+   James Gettys
+   World Wide Web Consortium
+   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
+   Compaq Computer Corporation
+   250 University Avenue
+   Palo Alto, California, 94305, USA
+
+   EMail: mogul@wrl.dec.com
+
+
+   Henrik Frystyk Nielsen
+   World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: frystyk@w3.org
+
+
+   Larry Masinter
+   Xerox Corporation
+   3333 Coyote Hill Road
+   Palo Alto, CA 94034, USA
+
+   EMail: masinter@parc.xerox.com
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 162]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Paul J. Leach
+   Microsoft Corporation
+   1 Microsoft Way
+   Redmond, WA 98052, USA
+
+   EMail: paulle@microsoft.com
+
+
+   Tim Berners-Lee
+   Director, World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: timbl@w3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 163]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+19 Appendices
+
+19.1 Internet Media Type message/http and application/http
+
+   In addition to defining the HTTP/1.1 protocol, this document serves
+   as the specification for the Internet media type "message/http" and
+   "application/http". The message/http type can be used to enclose a
+   single HTTP request or response message, provided that it obeys the
+   MIME restrictions for all "message" types regarding line length and
+   encodings. The application/http type can be used to enclose a
+   pipeline of one or more HTTP request or response messages (not
+   intermixed). The following is to be registered with IANA [17].
+
+       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
+
+       Media Type name:         application
+       Media subtype name:      http
+       Required parameters:     none
+       Optional parameters:     version, msgtype
+        version: The HTTP-Version number of the enclosed messages
+                 (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: HTTP messages enclosed by this type
+                 are in "binary" format; use of an appropriate
+                 Content-Transfer-Encoding is required when
+                 transmitted via E-mail.
+       Security considerations: none
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 164]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+19.2 Internet Media Type multipart/byteranges
+
+   When an HTTP 206 (Partial Content) response message includes the
+   content of multiple ranges (a response to a request for multiple
+   non-overlapping ranges), these are transmitted as a multipart
+   message-body. The media type for this purpose is called
+   "multipart/byteranges".
+
+   The multipart/byteranges media type includes two or more parts, each
+   with its own Content-Type and Content-Range fields. The required
+   boundary parameter specifies the boundary string used to separate
+   each body-part.
+
+       Media Type name:         multipart
+       Media subtype name:      byteranges
+       Required parameters:     boundary
+       Optional parameters:     none
+       Encoding considerations: only "7bit", "8bit", or "binary" are
+                                permitted
+       Security considerations: none
+
+
+   For example:
+
+   HTTP/1.1 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--
+
+      Notes:
+
+      1) Additional CRLFs may precede the first boundary string in the
+         entity.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 165]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      2) Although RFC 2046 [40] permits the boundary string to be
+         quoted, some existing implementations handle a quoted boundary
+         string incorrectly.
+
+      3) A number of browsers and servers were coded to an early draft
+         of the byteranges specification to use a media type of
+         multipart/x-byteranges, which is almost, but not quite
+         compatible with the version documented in HTTP/1.1.
+
+19.3 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 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 message-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.
+
+   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 not labeling the entity is preferred over labeling
+   the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
+   and 3.4.1.
+
+   Additional rules for requirements on parsing and encoding of dates
+   and other potential problems with date encodings 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).
+
+      - 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 GMT. The
+        local time zone MUST NOT influence the calculation or comparison
+        of an age or expiration time.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 166]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - 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.
+
+19.4 Differences Between HTTP Entities and RFC 2045 Entities
+
+   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
+   822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
+   allow entities to be transmitted in an open variety of
+   representations and with extensible mechanisms. However, RFC 2045
+   discusses mail, and HTTP has a few features that are different from
+   those described in RFC 2045. 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.
+
+   This appendix describes specific areas where HTTP differs from RFC
+   2045. 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
+   might be required.
+
+19.4.1 MIME-Version
+
+   HTTP is not a MIME-compliant protocol. 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 RFC 2045[7]).
+   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.
+
+19.4.2 Conversion to Canonical Form
+
+   RFC 2045 [7] requires that an Internet mail entity be converted to
+   canonical form prior to being transferred, as described in section 4
+   of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
+   allowed for subtypes of the "text" media type when transmitted over
+   HTTP. RFC 2046 requires that content with a type of "text" represent
+   line breaks as CRLF and forbids the use of CR or LF outside of line
+
+
+
+Fielding, et al.            Standards Track                   [Page 167]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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 MIME
+   environment SHOULD translate all line breaks within the text media
+   types described in section 3.7.1 of this document to the RFC 2049
+   canonical form of CRLF. Note, however, that this might 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.
+
+   Implementors should note that conversion will break any cryptographic
+   checksums applied to the original content unless the original content
+   is already in canonical form. Therefore, the canonical form is
+   recommended for any content that uses such checksums in HTTP.
+
+19.4.3 Conversion of Date Formats
+
+   HTTP/1.1 uses a restricted set of date formats (section 3.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.
+
+19.4.4 Introduction of Content-Encoding
+
+   RFC 2045 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
+   a function equivalent to Content-Encoding. However, this parameter is
+   not part of RFC 2045.)
+
+19.4.5 No Content-Transfer-Encoding
+
+   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
+   2045. 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
+
+
+
+Fielding, et al.            Standards Track                   [Page 168]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   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.
+
+19.4.6 Introduction of Transfer-Encoding
+
+   HTTP/1.1 introduces the Transfer-Encoding header field (section
+   14.41). Proxies/gateways MUST remove any transfer-coding prior to
+   forwarding a message via a MIME-compliant protocol.
+
+   A process for decoding the "chunked" transfer-coding (section 3.6)
+   can be represented in pseudo-code as:
+
+       length := 0
+       read chunk-size, chunk-extension (if any) and CRLF
+       while (chunk-size > 0) {
+          read chunk-data and CRLF
+          append chunk-data to entity-body
+          length := length + chunk-size
+          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
+
+19.4.7 MHTML and Line Length Limitations
+
+   HTTP implementations which share code with MHTML [45] implementations
+   need to be aware of MIME line length limitations. Since HTTP does not
+   have this limitation, HTTP does not fold long lines. MHTML messages
+   being transported by HTTP follow all conventions of MHTML, including
+   line length limitations and folding, canonicalization, etc., since
+   HTTP transports all message-bodies as payload (see section 3.7.2) and
+   does not interpret the content or any MIME header lines that might be
+   contained therein.
+
+19.5 Additional Features
+
+   RFC 1945 and RFC 2068 document protocol elements used by some
+   existing HTTP implementations, but not consistently and correctly
+   across most HTTP/1.1 applications. Implementors are advised to be
+   aware of these features, but cannot rely upon their presence in, or
+   interoperability with, other HTTP/1.1 applications. Some of these
+
+
+
+Fielding, et al.            Standards Track                   [Page 169]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   describe proposed experimental features, and some describe features
+   that experimental deployment found lacking that are now addressed in
+   the base HTTP/1.1 specification.
+
+   A number of other headers, such as Content-Disposition and Title,
+   from SMTP and MIME are also often implemented (see RFC 2076 [37]).
+
+19.5.1 Content-Disposition
+
+   The Content-Disposition response-header field has been proposed as a
+   means for the origin server to suggest a default filename if the user
+   requests that the content is saved to a file. This usage is derived
+   from the definition of Content-Disposition in RFC 1806 [35].
+
+        content-disposition = "Content-Disposition" ":"
+                              disposition-type *( ";" disposition-parm )
+        disposition-type = "attachment" | disp-extension-token
+        disposition-parm = filename-parm | disp-extension-parm
+        filename-parm = "filename" "=" quoted-string
+        disp-extension-token = token
+        disp-extension-parm = token "=" ( token | quoted-string )
+
+   An example is
+
+        Content-Disposition: attachment; filename="fname.ext"
+
+   The receiving user agent SHOULD NOT respect any directory path
+   information present in the filename-parm parameter, which is the only
+   parameter believed to apply to HTTP implementations at this time. The
+   filename SHOULD be treated as a terminal component only.
+
+   If this header is used in a response with the application/octet-
+   stream content-type, the implied suggestion is that the user agent
+   should not display the response, but directly enter a `save response
+   as...' dialog.
+
+   See section 15.5 for Content-Disposition security issues.
+
+19.6 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. It is
+   worth noting that, at the time of composing this specification
+   (1996), 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;
+
+
+
+Fielding, et al.            Standards Track                   [Page 170]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - 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. Some implementations implement the Keep-Alive
+   version of persistent connections described in section 19.7.1 of RFC
+   2068 [33].
+
+19.6.1 Changes from HTTP/1.0
+
+   This section summarizes major differences between versions HTTP/1.0
+   and HTTP/1.1.
+
+19.6.1.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 14.23) is
+   missing from an HTTP/1.1 request, and accept absolute URIs (section
+   5.1.2) are among the most important changes defined by this
+   specification.
+
+   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+   addresses and servers; there was no other established mechanism for
+   distinguishing the intended server of a request than the IP address
+   to which that request was directed. The changes outlined above will
+   allow the Internet, once older HTTP clients 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
+   allocated for the sole purpose of allowing special-purpose domain
+   names to be used in root-level HTTP URLs. Given the rate of growth of
+   the Web, and the number of servers already deployed, it is extremely
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 171]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   important that all implementations of HTTP (including updates to
+   existing HTTP/1.0 applications) correctly implement these
+   requirements:
+
+      - Both clients and servers MUST support the Host request-header.
+
+      - A client that sends an HTTP/1.1 request MUST send a Host header.
+
+      - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
+        request does not include a Host request-header.
+
+      - Servers MUST accept absolute URIs.
+
+19.6.2 Compatibility with HTTP/1.0 Persistent Connections
+
+   Some clients and servers might wish to be compatible with some
+   previous implementations of persistent connections in HTTP/1.0
+   clients and servers. Persistent connections in HTTP/1.0 are
+   explicitly negotiated as they are not the default behavior. HTTP/1.0
+   experimental implementations of persistent connections are faulty,
+   and the new facilities in HTTP/1.1 are designed to rectify these
+   problems. The problem 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 it to the next
+   inbound server, which would establish the Keep-Alive connection and
+   result in a hung HTTP/1.0 proxy waiting for the close on the
+   response. The result is that HTTP/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 prohibition 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. Persistent connections are the default for
+   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
+   declaring non-persistence. See section 14.10.
+
+   The original HTTP/1.0 form of persistent connections (the Connection:
+   Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
+
+19.6.3 Changes from RFC 2068
+
+   This specification has been carefully audited to correct and
+   disambiguate key word usage; RFC 2068 had many problems in respect to
+   the conventions laid out in RFC 2119 [34].
+
+   Clarified which error code should be used for inbound server failures
+   (e.g. DNS failures). (Section 10.5.5).
+
+
+
+Fielding, et al.            Standards Track                   [Page 172]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   CREATE had a race that required an Etag be sent when a resource is
+   first created. (Section 10.2.2).
+
+   Content-Base was deleted from the specification: it was not
+   implemented widely, and there is no simple, safe way to introduce it
+   without a robust extension mechanism. In addition, it is used in a
+   similar, but not identical fashion in MHTML [45].
+
+   Transfer-coding and message lengths all interact in ways that
+   required fixing exactly when chunked encoding is used (to allow for
+   transfer encoding that may not be self delimiting); it was important
+   to straighten out exactly how message lengths are computed. (Sections
+   3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
+
+   A content-coding of "identity" was introduced, to solve problems
+   discovered in caching. (section 3.5)
+
+   Quality Values of zero should indicate that "I don't want something"
+   to allow clients to refuse a representation. (Section 3.9)
+
+   The use and interpretation of HTTP version numbers has been clarified
+   by RFC 2145. Require proxies to upgrade requests to highest protocol
+   version they support to deal with problems discovered in HTTP/1.0
+   implementations (Section 3.1)
+
+   Charset wildcarding is introduced to avoid explosion of character set
+   names in accept headers. (Section 14.2)
+
+   A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
+   was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
+   14.9.3)
+
+   The Cache-Control: max-age directive was not properly defined for
+   responses. (Section 14.9.3)
+
+   There are situations where a server (especially a proxy) does not
+   know the full length of a response but is capable of serving a
+   byterange request. We therefore need a mechanism to allow byteranges
+   with a content-range not indicating the full length of the message.
+   (Section 14.16)
+
+   Range request responses would become very verbose if all meta-data
+   were always returned; by allowing the server to only send needed
+   headers in a 206 response, this problem can be avoided. (Section
+   10.2.7, 13.5.3, and 14.27)
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 173]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Fix problem with unsatisfiable range requests; there are two cases:
+   syntactic problems, and range doesn't exist in the document. The 416
+   status code was needed to resolve this ambiguity needed to indicate
+   an error for a byte range request that falls outside of the actual
+   contents of a document. (Section 10.4.17, 14.16)
+
+   Rewrite of message transmission requirements to make it much harder
+   for implementors to get it wrong, as the consequences of errors here
+   can have significant impact on the Internet, and to deal with the
+   following problems:
+
+      1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
+         this was incorrectly placing a requirement on the behavior of
+         an implementation of a future version of HTTP/1.x
+
+      2. Made it clear that user-agents should retry requests, not
+         "clients" in general.
+
+      3. Converted requirements for clients to ignore unexpected 100
+         (Continue) responses, and for proxies to forward 100 responses,
+         into a general requirement for 1xx responses.
+
+      4. Modified some TCP-specific language, to make it clearer that
+         non-TCP transports are possible for HTTP.
+
+      5. Require that the origin server MUST NOT wait for the request
+         body before it sends a required 100 (Continue) response.
+
+      6. Allow, rather than require, a server to omit 100 (Continue) if
+         it has already seen some of the request body.
+
+      7. Allow servers to defend against denial-of-service attacks and
+         broken clients.
+
+   This change adds the Expect header and 417 status code. The message
+   transmission requirements fixes are in sections 8.2, 10.4.18,
+   8.1.2.2, 13.11, and 14.20.
+
+   Proxies should be able to add Content-Length when appropriate.
+   (Section 13.5.2)
+
+   Clean up confusion between 403 and 404 responses. (Section 10.4.4,
+   10.4.5, and 10.4.11)
+
+   Warnings could be cached incorrectly, or not updated appropriately.
+   (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
+   also needed to be a general header, as PUT or other methods may have
+   need for it in requests.
+
+
+
+Fielding, et al.            Standards Track                   [Page 174]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Transfer-coding had significant problems, particularly with
+   interactions with chunked encoding. The solution is that transfer-
+   codings become as full fledged as content-codings. This involves
+   adding an IANA registry for transfer-codings (separate from content
+   codings), a new header field (TE) and enabling trailer headers in the
+   future. Transfer encoding is a major performance benefit, so it was
+   worth fixing [39]. TE also solves another, obscure, downward
+   interoperability problem that could have occurred due to interactions
+   between authentication trailers, chunked encoding and HTTP/1.0
+   clients.(Section 3.6, 3.6.1, and 14.39)
+
+   The PATCH, LINK, UNLINK methods were defined but not commonly
+   implemented in previous versions of this specification. See RFC 2068
+   [33].
+
+   The Alternates, Content-Version, Derived-From, Link, URI, Public and
+   Content-Base header fields were defined in previous versions of this
+   specification, but not commonly implemented. See RFC 2068 [33].
+
+20 Index
+
+   Please see the PostScript version of this RFC for the INDEX.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 175]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+21.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 176]
+
diff --git a/standards/rfc2617.txt b/standards/rfc2617.txt
new file mode 100644
index 000000000..771aa924a
--- /dev/null
+++ b/standards/rfc2617.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group                                          J. Franks
+Request for Comments: 2617                       Northwestern University
+Obsoletes: 2069                                          P. Hallam-Baker
+Category: Standards Track                                 Verisign, Inc.
+                                                            J. Hostetler
+                                                         AbiSource, Inc.
+                                                             S. Lawrence
+                                                   Agranat Systems, Inc.
+                                                                P. Leach
+                                                   Microsoft Corporation
+                                                             A. Luotonen
+                                     Netscape Communications Corporation
+                                                              L. Stewart
+                                                       Open Market, Inc.
+                                                               June 1999
+
+
+      HTTP Authentication: Basic and Digest Access Authentication
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   "HTTP/1.0", includes the specification for a Basic Access
+   Authentication scheme. This scheme is not considered to be a secure
+   method of user authentication (unless used in conjunction with some
+   external secure system such as SSL [5]), as the user name and
+   password are passed over the network as cleartext.
+
+   This document also provides the specification for HTTP's
+   authentication framework, the original Basic authentication scheme
+   and a scheme based on cryptographic hashes, referred to as "Digest
+   Access Authentication".  It is therefore also intended to serve as a
+   replacement for RFC 2069 [6].  Some optional elements specified by
+   RFC 2069 have been removed from this specification due to problems
+   found since its publication; other new elements have been added for
+   compatibility, those new elements have been made optional, but are
+   strongly recommended.
+
+
+
+Franks, et al.              Standards Track                     [Page 1]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   Like Basic, Digest access authentication verifies that both parties
+   to a communication know a shared secret (a password); unlike Basic,
+   this verification can be done without sending the password in the
+   clear, which is Basic's biggest weakness. As with most other
+   authentication protocols, the greatest sources of risks are usually
+   found not in the core protocol itself but in policies and procedures
+   surrounding its use.
+
+Table of Contents
+
+   1   Access Authentication................................   3
+    1.1   Reliance on the HTTP/1.1 Specification............   3
+    1.2   Access Authentication Framework...................   3
+   2   Basic Authentication Scheme..........................   5
+   3   Digest Access Authentication Scheme..................   6
+    3.1   Introduction......................................   6
+     3.1.1  Purpose.........................................   6
+     3.1.2  Overall Operation...............................   6
+     3.1.3  Representation of digest values.................   7
+     3.1.4  Limitations.....................................   7
+    3.2   Specification of Digest Headers...................   7
+     3.2.1  The WWW-Authenticate Response Header............   8
+     3.2.2  The Authorization Request Header................  11
+     3.2.3  The Authentication-Info Header..................  15
+    3.3   Digest Operation..................................  17
+    3.4   Security Protocol Negotiation.....................  18
+    3.5   Example...........................................  18
+    3.6   Proxy-Authentication and Proxy-Authorization......  19
+   4   Security Considerations..............................  19
+    4.1   Authentication of Clients using Basic
+          Authentication....................................  19
+    4.2   Authentication of Clients using Digest
+          Authentication....................................  20
+    4.3   Limited Use Nonce Values..........................  21
+    4.4   Comparison of Digest with Basic Authentication....  22
+    4.5   Replay Attacks....................................  22
+    4.6   Weakness Created by Multiple Authentication
+          Schemes...........................................  23
+    4.7   Online dictionary attacks.........................  23
+    4.8   Man in the Middle.................................  24
+    4.9   Chosen plaintext attacks..........................  24
+    4.10  Precomputed dictionary attacks....................  25
+    4.11  Batch brute force attacks.........................  25
+    4.12  Spoofing by Counterfeit Servers...................  25
+    4.13  Storing passwords.................................  26
+    4.14  Summary...........................................  26
+   5   Sample implementation................................  27
+   6   Acknowledgments......................................  31
+
+
+
+Franks, et al.              Standards Track                     [Page 2]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   7   References...........................................  31
+   8   Authors' Addresses...................................  32
+   9   Full Copyright Statement.............................  34
+
+1 Access Authentication
+
+1.1 Reliance on the HTTP/1.1 Specification
+
+   This specification is a companion to the HTTP/1.1 specification [2].
+   It uses the augmented BNF section 2.1 of that document, and relies on
+   both the non-terminals defined in that document and other aspects of
+   the HTTP/1.1 specification.
+
+1.2 Access Authentication Framework
+
+   HTTP provides a simple challenge-response authentication mechanism
+   that 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 "=" ( 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. The 407 (Proxy
+   Authentication Required) response message is used by a proxy to
+   challenge the authorization of a client and MUST include a Proxy-
+   Authenticate header field containing at least one challenge
+   applicable to the proxy for the requested resource.
+
+      challenge   = auth-scheme 1*SP 1#auth-param
+
+   Note: User agents will need to take special care in parsing the WWW-
+   Authenticate or Proxy-Authenticate header 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.
+
+   The authentication parameter realm is defined for all authentication
+   schemes:
+
+      realm       = "realm" "=" realm-value
+      realm-value = quoted-string
+
+
+
+Franks, et al.              Standards Track                     [Page 3]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   The realm directive (case-insensitive) is required for all
+   authentication schemes that issue a challenge. The realm value
+   (case-sensitive), in combination with the canonical root URL (the
+   absoluteURI for the server whose abs_path is empty; see section 5.1.2
+   of [2]) 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. Note that
+   there may be multiple challenges with the same auth-scheme but
+   different realms.
+
+   A user agent that wishes to authenticate itself with an origin
+   server--usually, but not necessarily, after receiving a 401
+   (Unauthorized)--MAY do so by including an Authorization header field
+   with the request. A client that wishes to authenticate itself with a
+   proxy--usually, but not necessarily, after receiving a 407 (Proxy
+   Authentication Required)--MAY do so by including a Proxy-
+   Authorization header field with the request.  Both the Authorization
+   field value and the Proxy-Authorization field value consist of
+   credentials containing the authentication information of the client
+   for the realm of the resource being requested. The user agent MUST
+   choose to use one of the challenges with the strongest auth-scheme it
+   understands and request credentials from the user based upon that
+   challenge.
+
+   credentials = auth-scheme #auth-param
+
+      Note that many browsers will only recognize Basic and will require
+      that it be the first auth-scheme presented. Servers should only
+      include Basic if it is minimally acceptable.
+
+   The protection space determines the domain over which credentials can
+   be automatically applied. 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 origin 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 at
+   least one (possibly new) challenge applicable to the requested
+   resource. If a proxy does not accept the credentials sent with a
+   request, it SHOULD return a 407 (Proxy Authentication Required). The
+   response MUST include a Proxy-Authenticate header field containing a
+
+
+
+Franks, et al.              Standards Track                     [Page 4]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   (possibly new) challenge applicable to the proxy for the requested
+   resource.
+
+   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 by origin servers. That is, they must forward the
+   WWW-Authenticate and Authorization headers untouched, and follow the
+   rules found in section 14.8 of [2]. Both the Proxy-Authenticate and
+   the Proxy-Authorization header fields are hop-by-hop headers (see
+   section 13.5.1 of [2]).
+
+2 Basic Authentication Scheme
+
+   The "basic" authentication scheme is based on the model that the
+   client 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.
+
+   For Basic, the framework above is utilized as follows:
+
+      challenge   = "Basic" realm
+      credentials = "Basic" basic-credentials
+
+   Upon receipt of an unauthorized request for a URI within the
+   protection space, the origin server MAY 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. A proxy may respond with the
+   same challenge using the Proxy-Authenticate header field.
+
+   To receive authorization, the client sends the userid and password,
+   separated by a single colon (":") character, within a base64 [7]
+   encoded string in the credentials.
+
+      basic-credentials = base64-user-pass
+      base64-user-pass  = <base64 [4] encoding of user-pass,
+
+
+
+Franks, et al.              Standards Track                     [Page 5]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+                       except not limited to 76 char/line>
+      user-pass   = userid ":" password
+      userid      = *<TEXT excluding ":">
+      password    = *TEXT
+
+   Userids might be case sensitive.
+
+   If the user agent wishes to send the userid "Aladdin" and password
+   "open sesame", it would use the following header field:
+
+      Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+
+   A client SHOULD assume that all paths at or deeper than the depth of
+   the last symbolic element in the path field of the Request-URI also
+   are within the protection space specified by the Basic realm value of
+   the current challenge. A client MAY preemptively send the
+   corresponding Authorization header with requests for resources in
+   that space without receipt of another challenge from the server.
+   Similarly, when a client sends a request to a proxy, it may reuse a
+   userid and password in the Proxy-Authorization header field without
+   receiving another challenge from the proxy server. See section 4 for
+   security considerations associated with Basic authentication.
+
+3 Digest Access Authentication Scheme
+
+3.1 Introduction
+
+3.1.1 Purpose
+
+   The protocol referred to as "HTTP/1.0" includes the specification for
+   a Basic Access Authentication scheme[1]. That scheme is not
+   considered to be a secure method of user authentication, as the user
+   name and password are passed over the network in an unencrypted form.
+   This section provides the specification for a scheme that does not
+   send the password in cleartext,  referred to as "Digest Access
+   Authentication".
+
+   The Digest Access Authentication scheme is not intended to be a
+   complete answer to the need for security in the World Wide Web. This
+   scheme provides no encryption of message content. The intent is
+   simply to create an access authentication method that avoids the most
+   serious flaws of Basic authentication.
+
+3.1.2 Overall Operation
+
+   Like Basic Access Authentication, the Digest scheme is based on a
+   simple challenge-response paradigm. The Digest scheme challenges
+   using a nonce value. A valid response contains a checksum (by
+
+
+
+Franks, et al.              Standards Track                     [Page 6]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   default, the MD5 checksum) of the username, the password, the given
+   nonce value, the HTTP method, and the requested URI. In this way, the
+   password is never sent in the clear. Just as with the Basic scheme,
+   the username and password must be prearranged in some fashion not
+   addressed by this document.
+
+3.1.3 Representation of digest values
+
+   An optional header allows the server to specify the algorithm used to
+   create the checksum or digest. By default the MD5 algorithm is used
+   and that is the only algorithm described in this document.
+
+   For the purposes of this document, an MD5 digest of 128 bits is
+   represented as 32 ASCII printable characters. The bits in the 128 bit
+   digest are converted from most significant to least significant bit,
+   four bits at a time to their ASCII presentation as follows. Each four
+   bits is represented by its familiar hexadecimal notation from the
+   characters 0123456789abcdef. That is, binary 0000 gets represented by
+   the character '0', 0001, by '1', and so on up to the representation
+   of 1111 as 'f'.
+
+3.1.4 Limitations
+
+   The Digest authentication scheme described in this document suffers
+   from many known limitations. It is intended as a replacement for
+   Basic authentication and nothing more. It is a password-based system
+   and (on the server side) suffers from all the same problems of any
+   password system. In particular, no provision is made in this protocol
+   for the initial secure arrangement between user and server to
+   establish the user's password.
+
+   Users and implementors should be aware that this protocol is not as
+   secure as Kerberos, and not as secure as any client-side private-key
+   scheme. Nevertheless it is better than nothing, better than what is
+   commonly used with telnet and ftp, and better than Basic
+   authentication.
+
+3.2 Specification of Digest Headers
+
+   The Digest Access Authentication scheme is conceptually similar to
+   the Basic scheme. The formats of the modified WWW-Authenticate header
+   line and the Authorization header line are specified below. In
+   addition, a new header, Authentication-Info, is specified.
+
+
+
+
+
+
+
+
+Franks, et al.              Standards Track                     [Page 7]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+3.2.1 The WWW-Authenticate Response Header
+
+   If a server receives a request for an access-protected object, and an
+   acceptable Authorization header is not sent, the server responds with
+   a "401 Unauthorized" status code, and a WWW-Authenticate header as
+   per the framework defined above, which for the digest scheme is
+   utilized as follows:
+
+      challenge        =  "Digest" digest-challenge
+
+      digest-challenge  = 1#( realm | [ domain ] | nonce |
+                          [ opaque ] |[ stale ] | [ algorithm ] |
+                          [ qop-options ] | [auth-param] )
+
+
+      domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
+      URI               = absoluteURI | abs_path
+      nonce             = "nonce" "=" nonce-value
+      nonce-value       = quoted-string
+      opaque            = "opaque" "=" quoted-string
+      stale             = "stale" "=" ( "true" | "false" )
+      algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" |
+                           token )
+      qop-options       = "qop" "=" <"> 1#qop-value <">
+      qop-value         = "auth" | "auth-int" | token
+
+   The meanings of the values of the directives used above are as
+   follows:
+
+   realm
+     A string to be displayed to users so they know which username and
+     password to use. This string should contain at least the name of
+     the host performing the authentication and might additionally
+     indicate the collection of users who might have access. An example
+     might be "registered_users@gotham.news.com".
+
+   domain
+     A quoted, space-separated list of URIs, as specified in RFC XURI
+     [7], that define the protection space.  If a URI is an abs_path, it
+     is relative to the canonical root URL (see section 1.2 above) of
+     the server being accessed. An absoluteURI in this list may refer to
+     a different server than the one being accessed. The client can use
+     this list to determine the set of URIs for which the same
+     authentication information may be sent: any URI that has a URI in
+     this list as a prefix (after both have been made absolute) may be
+     assumed to be in the same protection space. If this directive is
+     omitted or its value is empty, the client should assume that the
+     protection space consists of all URIs on the responding server.
+
+
+
+Franks, et al.              Standards Track                     [Page 8]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+     This directive is not meaningful in Proxy-Authenticate headers, for
+     which the protection space is always the entire proxy; if present
+     it should be ignored.
+
+   nonce
+     A server-specified data string which should be uniquely generated
+     each time a 401 response is made. It is recommended that this
+     string be base64 or hexadecimal data. Specifically, since the
+     string is passed in the header lines as a quoted string, the
+     double-quote character is not allowed.
+
+     The contents of the nonce are implementation dependent. The quality
+     of the implementation depends on a good choice. A nonce might, for
+     example, be constructed as the base 64 encoding of
+
+         time-stamp H(time-stamp ":" ETag ":" private-key)
+
+     where time-stamp is a server-generated time or other non-repeating
+     value, ETag is the value of the HTTP ETag header associated with
+     the requested entity, and private-key is data known only to the
+     server.  With a nonce of this form a server would recalculate the
+     hash portion after receiving the client authentication header and
+     reject the request if it did not match the nonce from that header
+     or if the time-stamp value is not recent enough. In this way the
+     server can limit the time of the nonce's validity. The inclusion of
+     the ETag prevents a replay request for an updated version of the
+     resource.  (Note: including the IP address of the client in the
+     nonce would appear to offer the server the ability to limit the
+     reuse of the nonce to the same client that originally got it.
+     However, that would break proxy farms, where requests from a single
+     user often go through different proxies in the farm. Also, IP
+     address spoofing is not that hard.)
+
+     An implementation might choose not to accept a previously used
+     nonce or a previously used digest, in order to protect against a
+     replay attack. Or, an implementation might choose to use one-time
+     nonces or digests for POST or PUT requests and a time-stamp for GET
+     requests.  For more details on the issues involved see section 4.
+     of this document.
+
+     The nonce is opaque to the client.
+
+   opaque
+     A string of data, specified by the server, which should be returned
+     by the client unchanged in the Authorization header of subsequent
+     requests with URIs in the same protection space. It is recommended
+     that this string be base64 or hexadecimal data.
+
+
+
+
+Franks, et al.              Standards Track                     [Page 9]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   stale
+     A flag, indicating that the previous request from the client was
+     rejected because the nonce value was stale. If stale is TRUE
+     (case-insensitive), the client may wish to simply retry the request
+     with a new encrypted response, without reprompting the user for a
+     new username and password. The server should only set stale to TRUE
+     if it receives a request for which the nonce is invalid but with a
+     valid digest for that nonce (indicating that the client knows the
+     correct username/password). If stale is FALSE, or anything other
+     than TRUE, or the stale directive is not present, the username
+     and/or password are invalid, and new values must be obtained.
+
+   algorithm
+     A string indicating a pair of algorithms used to produce the digest
+     and a checksum. If this is not present it is assumed to be "MD5".
+     If the algorithm is not understood, the challenge should be ignored
+     (and a different one used, if there is more than one).
+
+     In this document the string obtained by applying the digest
+     algorithm to the data "data" with secret "secret" will be denoted
+     by KD(secret, data), and the string obtained by applying the
+     checksum algorithm to the data "data" will be denoted H(data). The
+     notation unq(X) means the value of the quoted-string X without the
+     surrounding quotes.
+
+     For the "MD5" and "MD5-sess" algorithms
+
+         H(data) = MD5(data)
+
+     and
+
+         KD(secret, data) = H(concat(secret, ":", data))
+
+     i.e., the digest is the MD5 of the secret concatenated with a colon
+     concatenated with the data. The "MD5-sess" algorithm is intended to
+     allow efficient 3rd party authentication servers; for the
+     difference in usage, see the description in section 3.2.2.2.
+
+   qop-options
+     This directive is optional, but is made so only for backward
+     compatibility with RFC 2069 [6]; it SHOULD be used by all
+     implementations compliant with this version of the Digest scheme.
+     If present, it is a quoted string of one or more tokens indicating
+     the "quality of protection" values supported by the server.  The
+     value "auth" indicates authentication; the value "auth-int"
+     indicates authentication with integrity protection; see the
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 10]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+     descriptions below for calculating the response directive value for
+     the application of this choice. Unrecognized options MUST be
+     ignored.
+
+   auth-param
+     This directive allows for future extensions. Any unrecognized
+     directive MUST be ignored.
+
+3.2.2 The Authorization Request Header
+
+   The client is expected to retry the request, passing an Authorization
+   header line, which is defined according to the framework above,
+   utilized as follows.
+
+       credentials      = "Digest" digest-response
+       digest-response  = 1#( username | realm | nonce | digest-uri
+                       | response | [ algorithm ] | [cnonce] |
+                       [opaque] | [message-qop] |
+                           [nonce-count]  | [auth-param] )
+
+       username         = "username" "=" username-value
+       username-value   = quoted-string
+       digest-uri       = "uri" "=" digest-uri-value
+       digest-uri-value = request-uri   ; As specified by HTTP/1.1
+       message-qop      = "qop" "=" qop-value
+       cnonce           = "cnonce" "=" cnonce-value
+       cnonce-value     = nonce-value
+       nonce-count      = "nc" "=" nc-value
+       nc-value         = 8LHEX
+       response         = "response" "=" request-digest
+       request-digest = <"> 32LHEX <">
+       LHEX             =  "0" | "1" | "2" | "3" |
+                           "4" | "5" | "6" | "7" |
+                           "8" | "9" | "a" | "b" |
+                           "c" | "d" | "e" | "f"
+
+   The values of the opaque and algorithm fields must be those supplied
+   in the WWW-Authenticate response header for the entity being
+   requested.
+
+   response
+     A string of 32 hex digits computed as defined below, which proves
+     that the user knows a password
+
+   username
+     The user's name in the specified realm.
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 11]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   digest-uri
+     The URI from Request-URI of the Request-Line; duplicated here
+     because proxies are allowed to change the Request-Line in transit.
+
+   qop
+     Indicates what "quality of protection" the client has applied to
+     the message. If present, its value MUST be one of the alternatives
+     the server indicated it supports in the WWW-Authenticate header.
+     These values affect the computation of the request-digest. Note
+     that this is a single token, not a quoted list of alternatives as
+     in WWW- Authenticate.  This directive is optional in order to
+     preserve backward compatibility with a minimal implementation of
+     RFC 2069 [6], but SHOULD be used if the server indicated that qop
+     is supported by providing a qop directive in the WWW-Authenticate
+     header field.
+
+   cnonce
+     This MUST be specified if a qop directive is sent (see above), and
+     MUST NOT be specified if the server did not send a qop directive in
+     the WWW-Authenticate header field.  The cnonce-value is an opaque
+     quoted string value provided by the client and used by both client
+     and server to avoid chosen plaintext attacks, to provide mutual
+     authentication, and to provide some message integrity protection.
+     See the descriptions below of the calculation of the response-
+     digest and request-digest values.
+
+   nonce-count
+     This MUST be specified if a qop directive is sent (see above), and
+     MUST NOT be specified if the server did not send a qop directive in
+     the WWW-Authenticate header field.  The nc-value is the hexadecimal
+     count of the number of requests (including the current request)
+     that the client has sent with the nonce value in this request.  For
+     example, in the first request sent in response to a given nonce
+     value, the client sends "nc=00000001".  The purpose of this
+     directive is to allow the server to detect request replays by
+     maintaining its own copy of this count - if the same nc-value is
+     seen twice, then the request is a replay.   See the description
+     below of the construction of the request-digest value.
+
+   auth-param
+     This directive allows for future extensions. Any unrecognized
+     directive MUST be ignored.
+
+   If a directive or its value is improper, or required directives are
+   missing, the proper response is 400 Bad Request. If the request-
+   digest is invalid, then a login failure should be logged, since
+   repeated login failures from a single client may indicate an attacker
+   attempting to guess passwords.
+
+
+
+Franks, et al.              Standards Track                    [Page 12]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   The definition of request-digest above indicates the encoding for its
+   value. The following definitions show how the value is computed.
+
+3.2.2.1 Request-Digest
+
+   If the "qop" value is "auth" or "auth-int":
+
+      request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
+                                          ":" nc-value
+                                          ":" unq(cnonce-value)
+                                          ":" unq(qop-value)
+                                          ":" H(A2)
+                                  ) <">
+
+   If the "qop" directive is not present (this construction is for
+   compatibility with RFC 2069):
+
+      request-digest  =
+                 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
+   <">
+
+   See below for the definitions for A1 and A2.
+
+3.2.2.2 A1
+
+   If the "algorithm" directive's value is "MD5" or is unspecified, then
+   A1 is:
+
+      A1       = unq(username-value) ":" unq(realm-value) ":" passwd
+
+   where
+
+      passwd   = < user's password >
+
+   If the "algorithm" directive's value is "MD5-sess", then A1 is
+   calculated only once - on the first request by the client following
+   receipt of a WWW-Authenticate challenge from the server.  It uses the
+   server nonce from that challenge, and the first client nonce value to
+   construct A1 as follows:
+
+      A1       = H( unq(username-value) ":" unq(realm-value)
+                     ":" passwd )
+                     ":" unq(nonce-value) ":" unq(cnonce-value)
+
+   This creates a 'session key' for the authentication of subsequent
+   requests and responses which is different for each "authentication
+   session", thus limiting the amount of material hashed with any one
+   key.  (Note: see further discussion of the authentication session in
+
+
+
+Franks, et al.              Standards Track                    [Page 13]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   section 3.3.) Because the server need only use the hash of the user
+   credentials in order to create the A1 value, this construction could
+   be used in conjunction with a third party authentication service so
+   that the web server would not need the actual password value.  The
+   specification of such a protocol is beyond the scope of this
+   specification.
+
+3.2.2.3 A2
+
+   If the "qop" directive's value is "auth" or is unspecified, then A2
+   is:
+
+      A2       = Method ":" digest-uri-value
+
+   If the "qop" value is "auth-int", then A2 is:
+
+      A2       = Method ":" digest-uri-value ":" H(entity-body)
+
+3.2.2.4 Directive values and quoted-string
+
+   Note that the value of many of the directives, such as "username-
+   value", are defined as a "quoted-string". However, the "unq" notation
+   indicates that surrounding quotation marks are removed in forming the
+   string A1. Thus if the Authorization header includes the fields
+
+     username="Mufasa", realm=myhost@testrealm.com
+
+   and the user Mufasa has password "Circle Of Life" then H(A1) would be
+   H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks
+   in the digested string.
+
+   No white space is allowed in any of the strings to which the digest
+   function H() is applied unless that white space exists in the quoted
+   strings or entity body whose contents make up the string to be
+   digested. For example, the string A1 illustrated above must be
+
+        Mufasa:myhost@testrealm.com:Circle Of Life
+
+   with no white space on either side of the colons, but with the white
+   space between the words used in the password value.  Likewise, the
+   other strings digested by H() must not have white space on either
+   side of the colons which delimit their fields unless that white space
+   was in the quoted strings or entity body being digested.
+
+   Also note that if integrity protection is applied (qop=auth-int), the
+   H(entity-body) is the hash of the entity body, not the message body -
+   it is computed before any transfer encoding is applied by the sender
+
+
+
+
+Franks, et al.              Standards Track                    [Page 14]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   and after it has been removed by the recipient. Note that this
+   includes multipart boundaries and embedded headers in each part of
+   any multipart content-type.
+
+3.2.2.5 Various considerations
+
+   The "Method" value is the HTTP request method as specified in section
+   5.1.1 of [2]. The "request-uri" value is the Request-URI from the
+   request line as specified in section 5.1.2 of [2]. This may be "*",
+   an "absoluteURL" or an "abs_path" as specified in section 5.1.2 of
+   [2], but it MUST agree with the Request-URI. In particular, it MUST
+   be an "absoluteURL" if the Request-URI is an "absoluteURL". The
+   "cnonce-value" is an optional  client-chosen value whose purpose is
+   to foil chosen plaintext attacks.
+
+   The authenticating server must assure that the resource designated by
+   the "uri" directive is the same as the resource specified in the
+   Request-Line; if they are not, the server SHOULD return a 400 Bad
+   Request error. (Since this may be a symptom of an attack, server
+   implementers may want to consider logging such errors.) The purpose
+   of duplicating information from the request URL in this field is to
+   deal with the possibility that an intermediate proxy may alter the
+   client's Request-Line. This altered (but presumably semantically
+   equivalent) request would not result in the same digest as that
+   calculated by the client.
+
+   Implementers should be aware of how authenticated transactions
+   interact with shared caches. The HTTP/1.1 protocol specifies that
+   when a shared cache (see section 13.7 of [2]) has received a request
+   containing an Authorization header and a response from relaying that
+   request, it MUST NOT return that response as a reply to any other
+   request, unless one of two Cache-Control (see section 14.9 of [2])
+   directives was present in the response. If the original response
+   included the "must-revalidate" Cache-Control directive, the cache MAY
+   use the entity of that response in replying to a subsequent request,
+   but 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. Alternatively, if the original response
+   included the "public" Cache-Control directive, the response entity
+   MAY be returned in reply to any subsequent request.
+
+3.2.3 The Authentication-Info Header
+
+   The Authentication-Info header is used by the server to communicate
+   some information regarding the successful authentication in the
+   response.
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 15]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+        AuthenticationInfo = "Authentication-Info" ":" auth-info
+        auth-info          = 1#(nextnonce | [ message-qop ]
+                               | [ response-auth ] | [ cnonce ]
+                               | [nonce-count] )
+        nextnonce          = "nextnonce" "=" nonce-value
+        response-auth      = "rspauth" "=" response-digest
+        response-digest    = <"> *LHEX <">
+
+   The value of the nextnonce directive is the nonce the server wishes
+   the client to use for a future authentication response.  The server
+   may send the Authentication-Info header with a nextnonce field as a
+   means of implementing one-time or otherwise changing  nonces. If the
+   nextnonce field is present the client SHOULD use it when constructing
+   the Authorization header for its next request. Failure of the client
+   to do so may result in a request to re-authenticate from the server
+   with the "stale=TRUE".
+
+     Server implementations should carefully consider the performance
+     implications of the use of this mechanism; pipelined requests will
+     not be possible if every response includes a nextnonce directive
+     that must be used on the next request received by the server.
+     Consideration should be given to the performance vs. security
+     tradeoffs of allowing an old nonce value to be used for a limited
+     time to permit request pipelining.  Use of the nonce-count can
+     retain most of the security advantages of a new server nonce
+     without the deleterious affects on pipelining.
+
+   message-qop
+     Indicates the "quality of protection" options applied to the
+     response by the server.  The value "auth" indicates authentication;
+     the value "auth-int" indicates authentication with integrity
+     protection. The server SHOULD use the same value for the message-
+     qop directive in the response as was sent by the client in the
+     corresponding request.
+
+   The optional response digest in the "response-auth" directive
+   supports mutual authentication -- the server proves that it knows the
+   user's secret, and with qop=auth-int also provides limited integrity
+   protection of the response. The "response-digest" value is calculated
+   as for the "request-digest" in the Authorization header, except that
+   if "qop=auth" or is not specified in the Authorization header for the
+   request, A2 is
+
+      A2       = ":" digest-uri-value
+
+   and if "qop=auth-int", then A2 is
+
+      A2       = ":" digest-uri-value ":" H(entity-body)
+
+
+
+Franks, et al.              Standards Track                    [Page 16]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   where "digest-uri-value" is the value of the "uri" directive on the
+   Authorization header in the request. The "cnonce-value" and "nc-
+   value" MUST be the ones for the client request to which this message
+   is the response. The "response-auth", "cnonce", and "nonce-count"
+   directives MUST BE present if "qop=auth" or "qop=auth-int" is
+   specified.
+
+   The Authentication-Info header is allowed in the trailer of an HTTP
+   message transferred via chunked transfer-coding.
+
+3.3 Digest Operation
+
+   Upon receiving the Authorization header, the server may check its
+   validity by looking up the password that corresponds to the submitted
+   username. Then, the server must perform the same digest operation
+   (e.g., MD5) performed by the client, and compare the result to the
+   given request-digest value.
+
+   Note that the HTTP server does not actually need to know the user's
+   cleartext password. As long as H(A1) is available to the server, the
+   validity of an Authorization header may be verified.
+
+   The client response to a WWW-Authenticate challenge for a protection
+   space starts an authentication session with that protection space.
+   The authentication session lasts until the client receives another
+   WWW-Authenticate challenge from any server in the protection space. A
+   client should remember the username, password, nonce, nonce count and
+   opaque values associated with an authentication session to use to
+   construct the Authorization header in future requests within that
+   protection space. The Authorization header may be included
+   preemptively; doing so improves server efficiency and avoids extra
+   round trips for authentication challenges. The server may choose to
+   accept the old Authorization header information, even though the
+   nonce value included might not be fresh. Alternatively, the server
+   may return a 401 response with a new nonce value, causing the client
+   to retry the request; by specifying stale=TRUE with this response,
+   the server tells the client to retry with the new nonce, but without
+   prompting for a new username and password.
+
+   Because the client is required to return the value of the opaque
+   directive given to it by the server for the duration of a session,
+   the opaque data may be used to transport authentication session state
+   information. (Note that any such use can also be accomplished more
+   easily and safely by including the state in the nonce.) For example,
+   a server could be responsible for authenticating content that
+   actually sits on another server. It would achieve this by having the
+   first 401 response include a domain directive whose value includes a
+   URI on the second server, and an opaque directive whose value
+
+
+
+Franks, et al.              Standards Track                    [Page 17]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   contains the state information. The client will retry the request, at
+   which time the server might respond with a 301/302 redirection,
+   pointing to the URI on the second server. The client will follow the
+   redirection, and pass an Authorization header , including the
+   <opaque> data.
+
+   As with the basic scheme, proxies must be completely transparent in
+   the Digest access authentication scheme. That is, they must forward
+   the WWW-Authenticate, Authentication-Info and Authorization headers
+   untouched. If a proxy wants to authenticate a client before a request
+   is forwarded to the server, it can be done using the Proxy-
+   Authenticate and Proxy-Authorization headers described in section 3.6
+   below.
+
+3.4 Security Protocol Negotiation
+
+   It is useful for a server to be able to know which security schemes a
+   client is capable of handling.
+
+   It is possible that a server may want to require Digest as its
+   authentication method, even if the server does not know that the
+   client supports it. A client is encouraged to fail gracefully if the
+   server specifies only authentication schemes it cannot handle.
+
+3.5 Example
+
+   The following example assumes that an access-protected document is
+   being requested from the server via a GET request. The URI of the
+   document is "http://www.nowhere.org/dir/index.html". Both client and
+   server know that the username for this document is "Mufasa", and the
+   password is "Circle Of Life" (with one space between each of the
+   three words).
+
+   The first time the client requests the document, no Authorization
+   header is sent, so the server responds with:
+
+         HTTP/1.1 401 Unauthorized
+         WWW-Authenticate: Digest
+                 realm="testrealm@host.com",
+                 qop="auth,auth-int",
+                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+                 opaque="5ccc069c403ebaf9f0171e9517f40e41"
+
+   The client may prompt the user for the username and password, after
+   which it will respond with a new request, including the following
+   Authorization header:
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 18]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+         Authorization: Digest username="Mufasa",
+                 realm="testrealm@host.com",
+                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+                 uri="/dir/index.html",
+                 qop=auth,
+                 nc=00000001,
+                 cnonce="0a4f113b",
+                 response="6629fae49393a05397450978507c4ef1",
+                 opaque="5ccc069c403ebaf9f0171e9517f40e41"
+
+3.6 Proxy-Authentication and Proxy-Authorization
+
+   The digest authentication scheme may also be used for authenticating
+   users to proxies, proxies to proxies, or proxies to origin servers by
+   use of the Proxy-Authenticate and Proxy-Authorization headers. These
+   headers are instances of the Proxy-Authenticate and Proxy-
+   Authorization headers specified in sections 10.33 and 10.34 of the
+   HTTP/1.1 specification [2] and their behavior is subject to
+   restrictions described there. The transactions for proxy
+   authentication are very similar to those already described. Upon
+   receiving a request which requires authentication, the proxy/server
+   must issue the "407 Proxy Authentication Required" response with a
+   "Proxy-Authenticate" header.  The digest-challenge used in the
+   Proxy-Authenticate header is the same as that for the WWW-
+   Authenticate header as defined above in section 3.2.1.
+
+   The client/proxy must then re-issue the request with a Proxy-
+   Authorization header, with directives as specified for the
+   Authorization header in section 3.2.2 above.
+
+   On subsequent responses, the server sends Proxy-Authentication-Info
+   with directives the same as those for the Authentication-Info header
+   field.
+
+   Note that in principle a client could be asked to authenticate itself
+   to both a proxy and an end-server, but never in the same response.
+
+4 Security Considerations
+
+4.1 Authentication of Clients using Basic Authentication
+
+   The Basic authentication scheme is not a secure method of user
+   authentication, nor does it in any way protect the entity, which is
+   transmitted in cleartext 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.
+
+
+
+Franks, et al.              Standards Track                    [Page 19]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   The most serious flaw in Basic authentication is that it results in
+   the essentially cleartext 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 cleartext transmission of
+   passwords it SHOULD NOT 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 unauthorized access to documents on the server but
+   also unauthorized access to any other resources on other systems that
+   the user protects with the same password. Furthermore, in the
+   server's password database, many of the passwords may also be users'
+   passwords for other sites. The owner or administrator of such a
+   system could therefore expose all users of the system to the risk of
+   unauthorized access to all those sites 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. 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.  That gateway can then use the
+   persistent connection mechanism to engage in multiple transactions
+   with the client while impersonating the original server in a way that
+   is not detectable by the client.
+
+4.2 Authentication of Clients using Digest Authentication
+
+   Digest Authentication does not provide a strong authentication
+   mechanism, when compared to public key based mechanisms, for example.
+
+
+
+Franks, et al.              Standards Track                    [Page 20]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   However, it is significantly stronger than (e.g.) CRAM-MD5, which has
+   been proposed for use with LDAP [10], POP and IMAP (see RFC 2195
+   [9]).  It is intended to replace the much weaker and even more
+   dangerous Basic mechanism.
+
+   Digest Authentication offers no confidentiality protection beyond
+   protecting the actual password. All of the rest of the request and
+   response are available to an eavesdropper.
+
+   Digest Authentication offers only limited integrity protection for
+   the messages in either direction. If  qop=auth-int mechanism is used,
+   those parts of the message used in the calculation of the WWW-
+   Authenticate and Authorization header field response directive values
+   (see section 3.2 above) are  protected.  Most header fields and their
+   values could be modified as a part of a man-in-the-middle attack.
+
+   Many needs for secure HTTP transactions cannot be met by Digest
+   Authentication. For those needs TLS or SHTTP are more appropriate
+   protocols. In particular Digest authentication cannot be used for any
+   transaction requiring confidentiality protection.  Nevertheless many
+   functions remain for which Digest authentication is both useful and
+   appropriate.  Any service in present use that uses Basic should be
+   switched to Digest as soon as practical.
+
+4.3 Limited Use Nonce Values
+
+   The Digest scheme uses a server-specified nonce to seed the
+   generation of the request-digest value (as specified in section
+   3.2.2.1 above).  As shown in the example nonce in section 3.2.1, the
+   server is free to construct the nonce such that it may only be used
+   from a particular client, for a particular resource, for a limited
+   period of time or number of uses, or any other restrictions.  Doing
+   so strengthens the protection provided against, for example, replay
+   attacks (see 4.5).  However, it should be noted that the method
+   chosen for generating and checking the nonce also has performance and
+   resource implications.  For example, a server may choose to allow
+   each nonce value to be used only once by maintaining a record of
+   whether or not each recently issued nonce has been returned and
+   sending a next-nonce directive in the Authentication-Info header
+   field of every response. This protects against even an immediate
+   replay attack, but has a high cost checking nonce values, and perhaps
+   more important will cause authentication failures for any pipelined
+   requests (presumably returning a stale nonce indication).  Similarly,
+   incorporating a request-specific element such as the Etag value for a
+   resource limits the use of the nonce to that version of the resource
+   and also defeats pipelining. Thus it may be useful to do so for
+   methods with side effects but have unacceptable performance for those
+   that do not.
+
+
+
+Franks, et al.              Standards Track                    [Page 21]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+4.4 Comparison of Digest with Basic Authentication
+
+   Both Digest and Basic Authentication are very much on the weak end of
+   the security strength spectrum. But a comparison between the two
+   points out the utility, even necessity, of replacing Basic by Digest.
+
+   The greatest threat to the type of transactions for which these
+   protocols are used is network snooping. This kind of transaction
+   might involve, for example, online access to a database whose use is
+   restricted to paying subscribers. With Basic authentication an
+   eavesdropper can obtain the password of the user. This not only
+   permits him to access anything in the database, but, often worse,
+   will permit access to anything else the user protects with the same
+   password.
+
+   By contrast, with Digest Authentication the eavesdropper only gets
+   access to the transaction in question and not to the user's password.
+   The information gained by the eavesdropper would permit a replay
+   attack, but only with a request for the same document, and even that
+   may be limited by the server's choice of nonce.
+
+4.5 Replay Attacks
+
+   A replay attack against Digest authentication would usually be
+   pointless for a simple GET request since an eavesdropper would
+   already have seen the only document he could obtain with a replay.
+   This is because the URI of the requested document is digested in the
+   client request and the server will only deliver that document. By
+   contrast under Basic Authentication once the eavesdropper has the
+   user's password, any document protected by that password is open to
+   him.
+
+   Thus, for some purposes, it is necessary to protect against replay
+   attacks. A good Digest implementation can do this in various ways.
+   The server created "nonce" value is implementation dependent, but if
+   it contains a digest of the client IP, a time-stamp, the resource
+   ETag, and a private server key (as recommended above) then a replay
+   attack is not simple. An attacker must convince the server that the
+   request is coming from a false IP address and must cause the server
+   to deliver the document to an IP address different from the address
+   to which it believes it is sending the document. An attack can only
+   succeed in the period before the time-stamp expires. Digesting the
+   client IP and time-stamp in the nonce permits an implementation which
+   does not maintain state between transactions.
+
+   For applications where no possibility of replay attack can be
+   tolerated the server can use one-time nonce values which will not be
+   honored for a second use. This requires the overhead of the server
+
+
+
+Franks, et al.              Standards Track                    [Page 22]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   remembering which nonce values have been used until the nonce time-
+   stamp (and hence the digest built with it) has expired, but it
+   effectively protects against replay attacks.
+
+   An implementation must give special attention to the possibility of
+   replay attacks with POST and PUT requests. Unless the server employs
+   one-time or otherwise limited-use nonces and/or insists on the use of
+   the integrity protection of qop=auth-int, an attacker could replay
+   valid credentials from a successful request with counterfeit form
+   data or other message body. Even with the use of integrity protection
+   most metadata in header fields is not protected. Proper nonce
+   generation and checking provides some protection against replay of
+   previously used valid credentials, but see 4.8.
+
+4.6 Weakness Created by Multiple Authentication Schemes
+
+   An HTTP/1.1 server may return multiple challenges with a 401
+   (Authenticate) response, and each challenge may use a different
+   auth-scheme. A user agent MUST choose to use the strongest auth-
+   scheme it understands and request credentials from the user based
+   upon that challenge.
+
+      Note that many browsers will only recognize Basic and will require
+      that it be the first auth-scheme presented. Servers should only
+      include Basic if it is minimally acceptable.
+
+   When the server offers choices of authentication schemes using the
+   WWW-Authenticate header, the strength of the resulting authentication
+   is only as good as that of the of the weakest of the authentication
+   schemes. See section 4.8 below for discussion of particular attack
+   scenarios that exploit multiple authentication schemes.
+
+4.7 Online dictionary attacks
+
+   If the attacker can eavesdrop, then it can test any overheard
+   nonce/response pairs against a list of common words. Such a list is
+   usually much smaller than the total number of possible passwords. The
+   cost of computing the response for each password on the list is paid
+   once for each challenge.
+
+   The server can mitigate this attack by not allowing users to select
+   passwords that are in a dictionary.
+
+
+
+
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 23]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+4.8 Man in the Middle
+
+   Both Basic and Digest authentication are vulnerable to "man in the
+   middle" (MITM) attacks, for example, from a hostile or compromised
+   proxy. Clearly, this would present all the problems of eavesdropping.
+   But it also offers some additional opportunities to the attacker.
+
+   A possible man-in-the-middle attack would be to add a weak
+   authentication scheme to the set of choices, hoping that the client
+   will use one that exposes the user's credentials (e.g. password). For
+   this reason, the client should always use the strongest scheme that
+   it understands from the choices offered.
+
+   An even better MITM attack would be to remove all offered choices,
+   replacing them with a challenge that requests only Basic
+   authentication, then uses the cleartext credentials from the Basic
+   authentication to authenticate to the origin server using the
+   stronger scheme it requested. A particularly insidious way to mount
+   such a MITM attack would be to offer a "free" proxy caching service
+   to gullible users.
+
+   User agents should consider measures such as presenting a visual
+   indication at the time of the credentials request of what
+   authentication scheme is to be used, or remembering the strongest
+   authentication scheme ever requested by a server and produce a
+   warning message before using a weaker one. It might also be a good
+   idea for the user agent to be configured to demand Digest
+   authentication in general, or from specific sites.
+
+   Or, a hostile proxy might spoof the client into making a request the
+   attacker wanted rather than one the client wanted. Of course, this is
+   still much harder than a comparable attack against Basic
+   Authentication.
+
+4.9 Chosen plaintext attacks
+
+   With Digest authentication, a MITM or a malicious server can
+   arbitrarily choose the nonce that the client will use to compute the
+   response. This is called a "chosen plaintext" attack. The ability to
+   choose the nonce is known to make cryptanalysis much easier [8].
+
+   However, no way to analyze the MD5 one-way function used by Digest
+   using chosen plaintext is currently known.
+
+   The countermeasure against this attack is for clients to be
+   configured to require the use of the optional "cnonce" directive;
+   this allows the client to vary the input to the hash in a way not
+   chosen by the attacker.
+
+
+
+Franks, et al.              Standards Track                    [Page 24]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+4.10 Precomputed dictionary attacks
+
+   With Digest authentication, if the attacker can execute a chosen
+   plaintext attack, the attacker can precompute the response for many
+   common words to a nonce of its choice, and store a dictionary of
+   (response, password) pairs. Such precomputation can often be done in
+   parallel on many machines. It can then use the chosen plaintext
+   attack to acquire a response corresponding to that challenge, and
+   just look up the password in the dictionary. Even if most passwords
+   are not in the dictionary, some might be. Since the attacker gets to
+   pick the challenge, the cost of computing the response for each
+   password on the list can be amortized over finding many passwords. A
+   dictionary with 100 million password/response pairs would take about
+   3.2 gigabytes of disk storage.
+
+   The countermeasure against this attack is to for clients to be
+   configured to require the use of the optional "cnonce" directive.
+
+4.11 Batch brute force attacks
+
+   With Digest authentication, a MITM can execute a chosen plaintext
+   attack, and can gather responses from many users to the same nonce.
+   It can then find all the passwords within any subset of password
+   space that would generate one of the nonce/response pairs in a single
+   pass over that space. It also reduces the time to find the first
+   password by a factor equal to the number of nonce/response pairs
+   gathered. This search of the password space can often be done in
+   parallel on many machines, and even a single machine can search large
+   subsets of the password space very quickly -- reports exist of
+   searching all passwords with six or fewer letters in a few hours.
+
+   The countermeasure against this attack is to for clients to be
+   configured to require the use of the optional "cnonce" directive.
+
+4.12 Spoofing by Counterfeit Servers
+
+   Basic Authentication is vulnerable to spoofing by counterfeit
+   servers.  If a user can be led to believe that she is connecting to a
+   host containing information protected by a password she knows, when
+   in fact she is connecting to a hostile server, then the hostile
+   server can request a password, store it away for later use, and feign
+   an error.  This type of attack is more difficult with Digest
+   Authentication -- but the client must know to demand that Digest
+   authentication be used, perhaps using some of the techniques
+   described above to counter "man-in-the-middle" attacks.  Again, the
+   user can be helped in detecting this attack by a visual indication of
+   the authentication mechanism in use with appropriate guidance in
+   interpreting the implications of each scheme.
+
+
+
+Franks, et al.              Standards Track                    [Page 25]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+4.13 Storing passwords
+
+   Digest authentication requires that the authenticating agent (usually
+   the server) store some data derived from the user's name and password
+   in a "password file" associated with a given realm. Normally this
+   might contain pairs consisting of username and H(A1), where H(A1) is
+   the digested value of the username, realm, and password as described
+   above.
+
+   The security implications of this are that if this password file is
+   compromised, then an attacker gains immediate access to documents on
+   the server using this realm. Unlike, say a standard UNIX password
+   file, this information need not be decrypted in order to access
+   documents in the server realm associated with this file. On the other
+   hand, decryption, or more likely a brute force attack, would be
+   necessary to obtain the user's password. This is the reason that the
+   realm is part of the digested data stored in the password file. It
+   means that if one Digest authentication password file is compromised,
+   it does not automatically compromise others with the same username
+   and password (though it does expose them to brute force attack).
+
+   There are two important security consequences of this. First the
+   password file must be protected as if it contained unencrypted
+   passwords, because for the purpose of accessing documents in its
+   realm, it effectively does.
+
+   A second consequence of this is that the realm string should be
+   unique among all realms which any single user is likely to use. In
+   particular a realm string should include the name of the host doing
+   the authentication. The inability of the client to authenticate the
+   server is a weakness of Digest Authentication.
+
+4.14 Summary
+
+   By modern cryptographic standards Digest Authentication is weak. But
+   for a large range of purposes it is valuable as a replacement for
+   Basic Authentication. It remedies some, but not all, weaknesses of
+   Basic Authentication. Its strength may vary depending on the
+   implementation.  In particular the structure of the nonce (which is
+   dependent on the server implementation) may affect the ease of
+   mounting a replay attack.  A range of server options is appropriate
+   since, for example, some implementations may be willing to accept the
+   server overhead of one-time nonces or digests to eliminate the
+   possibility of replay. Others may satisfied with a nonce like the one
+   recommended above restricted to a single IP address and a single ETag
+   or with a limited lifetime.
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 26]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   The bottom line is that *any* compliant implementation will be
+   relatively weak by cryptographic standards, but *any* compliant
+   implementation will be far superior to Basic Authentication.
+
+5 Sample implementation
+
+   The following code implements the calculations of H(A1), H(A2),
+   request-digest and response-digest, and a test program which computes
+   the values used in the example of section 3.5. It uses the MD5
+   implementation from RFC 1321.
+
+   File "digcalc.h":
+
+#define HASHLEN 16
+typedef char HASH[HASHLEN];
+#define HASHHEXLEN 32
+typedef char HASHHEX[HASHHEXLEN+1];
+#define IN
+#define OUT
+
+/* calculate H(A1) as per HTTP Digest spec */
+void DigestCalcHA1(
+    IN char * pszAlg,
+    IN char * pszUserName,
+    IN char * pszRealm,
+    IN char * pszPassword,
+    IN char * pszNonce,
+    IN char * pszCNonce,
+    OUT HASHHEX SessionKey
+    );
+
+/* calculate request-digest/response-digest as per HTTP Digest spec */
+void DigestCalcResponse(
+    IN HASHHEX HA1,           /* H(A1) */
+    IN char * pszNonce,       /* nonce from server */
+    IN char * pszNonceCount,  /* 8 hex digits */
+    IN char * pszCNonce,      /* client nonce */
+    IN char * pszQop,         /* qop-value: "", "auth", "auth-int" */
+    IN char * pszMethod,      /* method from the request */
+    IN char * pszDigestUri,   /* requested URL */
+    IN HASHHEX HEntity,       /* H(entity body) if qop="auth-int" */
+    OUT HASHHEX Response      /* request-digest or response-digest */
+    );
+
+File "digcalc.c":
+
+#include <global.h>
+#include <md5.h>
+
+
+
+Franks, et al.              Standards Track                    [Page 27]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+#include <string.h>
+#include "digcalc.h"
+
+void CvtHex(
+    IN HASH Bin,
+    OUT HASHHEX Hex
+    )
+{
+    unsigned short i;
+    unsigned char j;
+
+    for (i = 0; i < HASHLEN; i++) {
+        j = (Bin[i] >> 4) & 0xf;
+        if (j <= 9)
+            Hex[i*2] = (j + '0');
+         else
+            Hex[i*2] = (j + 'a' - 10);
+        j = Bin[i] & 0xf;
+        if (j <= 9)
+            Hex[i*2+1] = (j + '0');
+         else
+            Hex[i*2+1] = (j + 'a' - 10);
+    };
+    Hex[HASHHEXLEN] = '\0';
+};
+
+/* calculate H(A1) as per spec */
+void DigestCalcHA1(
+    IN char * pszAlg,
+    IN char * pszUserName,
+    IN char * pszRealm,
+    IN char * pszPassword,
+    IN char * pszNonce,
+    IN char * pszCNonce,
+    OUT HASHHEX SessionKey
+    )
+{
+      MD5_CTX Md5Ctx;
+      HASH HA1;
+
+      MD5Init(&Md5Ctx);
+      MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
+      MD5Update(&Md5Ctx, ":", 1);
+      MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
+      MD5Update(&Md5Ctx, ":", 1);
+      MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
+      MD5Final(HA1, &Md5Ctx);
+      if (stricmp(pszAlg, "md5-sess") == 0) {
+
+
+
+Franks, et al.              Standards Track                    [Page 28]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+            MD5Init(&Md5Ctx);
+            MD5Update(&Md5Ctx, HA1, HASHLEN);
+            MD5Update(&Md5Ctx, ":", 1);
+            MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
+            MD5Update(&Md5Ctx, ":", 1);
+            MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
+            MD5Final(HA1, &Md5Ctx);
+      };
+      CvtHex(HA1, SessionKey);
+};
+
+/* calculate request-digest/response-digest as per HTTP Digest spec */
+void DigestCalcResponse(
+    IN HASHHEX HA1,           /* H(A1) */
+    IN char * pszNonce,       /* nonce from server */
+    IN char * pszNonceCount,  /* 8 hex digits */
+    IN char * pszCNonce,      /* client nonce */
+    IN char * pszQop,         /* qop-value: "", "auth", "auth-int" */
+    IN char * pszMethod,      /* method from the request */
+    IN char * pszDigestUri,   /* requested URL */
+    IN HASHHEX HEntity,       /* H(entity body) if qop="auth-int" */
+    OUT HASHHEX Response      /* request-digest or response-digest */
+    )
+{
+      MD5_CTX Md5Ctx;
+      HASH HA2;
+      HASH RespHash;
+       HASHHEX HA2Hex;
+
+      // calculate H(A2)
+      MD5Init(&Md5Ctx);
+      MD5Update(&Md5Ctx, pszMethod, strlen(pszMethod));
+      MD5Update(&Md5Ctx, ":", 1);
+      MD5Update(&Md5Ctx, pszDigestUri, strlen(pszDigestUri));
+      if (stricmp(pszQop, "auth-int") == 0) {
+            MD5Update(&Md5Ctx, ":", 1);
+            MD5Update(&Md5Ctx, HEntity, HASHHEXLEN);
+      };
+      MD5Final(HA2, &Md5Ctx);
+       CvtHex(HA2, HA2Hex);
+
+      // calculate response
+      MD5Init(&Md5Ctx);
+      MD5Update(&Md5Ctx, HA1, HASHHEXLEN);
+      MD5Update(&Md5Ctx, ":", 1);
+      MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
+      MD5Update(&Md5Ctx, ":", 1);
+      if (*pszQop) {
+
+
+
+Franks, et al.              Standards Track                    [Page 29]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+          MD5Update(&Md5Ctx, pszNonceCount, strlen(pszNonceCount));
+          MD5Update(&Md5Ctx, ":", 1);
+          MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
+          MD5Update(&Md5Ctx, ":", 1);
+          MD5Update(&Md5Ctx, pszQop, strlen(pszQop));
+          MD5Update(&Md5Ctx, ":", 1);
+      };
+      MD5Update(&Md5Ctx, HA2Hex, HASHHEXLEN);
+      MD5Final(RespHash, &Md5Ctx);
+      CvtHex(RespHash, Response);
+};
+
+File "digtest.c":
+
+
+#include <stdio.h>
+#include "digcalc.h"
+
+void main(int argc, char ** argv) {
+
+      char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093";
+      char * pszCNonce = "0a4f113b";
+      char * pszUser = "Mufasa";
+      char * pszRealm = "testrealm@host.com";
+      char * pszPass = "Circle Of Life";
+      char * pszAlg = "md5";
+      char szNonceCount[9] = "00000001";
+      char * pszMethod = "GET";
+      char * pszQop = "auth";
+      char * pszURI = "/dir/index.html";
+      HASHHEX HA1;
+      HASHHEX HA2 = "";
+      HASHHEX Response;
+
+      DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,
+pszCNonce, HA1);
+      DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop,
+       pszMethod, pszURI, HA2, Response);
+      printf("Response = %s\n", Response);
+};
+
+
+
+
+
+
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 30]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+6 Acknowledgments
+
+   Eric W. Sink, of AbiSource, Inc., was one of the original authors
+   before the specification underwent substantial revision.
+
+   In addition to the authors, valuable discussion instrumental in
+   creating this document has come from Peter J. Churchyard, Ned Freed,
+   and David M.  Kristol.
+
+   Jim Gettys and Larry Masinter edited this document for update.
+
+7 References
+
+   [1]  Berners-Lee, T.,  Fielding, R. and H. Frystyk, "Hypertext
+        Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [2]  Fielding, R.,  Gettys, J., Mogul, J., Frysyk, H., Masinter, L.,
+        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+        HTTP/1.1", RFC 2616, June 1999.
+
+   [3]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+        1992.
+
+   [4]  Freed, N. and N. Borenstein. "Multipurpose Internet Mail
+        Extensions (MIME) Part One: Format of Internet Message Bodies",
+        RFC 2045, November 1996.
+
+   [5]  Dierks, T. and C. Allen "The TLS Protocol, Version 1.0", RFC
+        2246, January 1999.
+
+   [6]  Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP :
+        Digest Access Authentication", RFC 2069, January 1997.
+
+   [7]  Berners Lee, T, Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [8]  Kaliski, B.,Robshaw, M., "Message Authentication with MD5",
+        CryptoBytes, Sping 1995, RSA Inc,
+        (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
+
+   [9]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize
+        Extension for Simple Challenge/Response", RFC 2195, September
+        1997.
+
+   [10] Morgan, B., Alvestrand, H., Hodges, J., Wahl, M.,
+        "Authentication Methods for LDAP", Work in Progress.
+
+
+
+
+Franks, et al.              Standards Track                    [Page 31]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+8 Authors' Addresses
+
+   John Franks
+   Professor of Mathematics
+   Department of Mathematics
+   Northwestern University
+   Evanston, IL 60208-2730, USA
+
+   EMail: john@math.nwu.edu
+
+
+   Phillip M. Hallam-Baker
+   Principal Consultant
+   Verisign Inc.
+   301 Edgewater Place
+   Suite 210
+   Wakefield MA 01880, USA
+
+   EMail: pbaker@verisign.com
+
+
+   Jeffery L. Hostetler
+   Software Craftsman
+   AbiSource, Inc.
+   6 Dunlap Court
+   Savoy, IL 61874
+
+   EMail: jeff@AbiSource.com
+
+
+   Scott D. Lawrence
+   Agranat Systems, Inc.
+   5 Clocktower Place, Suite 400
+   Maynard, MA 01754, USA
+
+   EMail: lawrence@agranat.com
+
+
+   Paul J. Leach
+   Microsoft Corporation
+   1 Microsoft Way
+   Redmond, WA 98052, USA
+
+   EMail: paulle@microsoft.com
+
+
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 32]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+   Ari Luotonen
+   Member of Technical Staff
+   Netscape Communications Corporation
+   501 East Middlefield Road
+   Mountain View, CA 94043, USA
+
+
+   Lawrence C. Stewart
+   Open Market, Inc.
+   215 First Street
+   Cambridge, MA  02142, USA
+
+   EMail: stewart@OpenMarket.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 33]
+
+RFC 2617                  HTTP Authentication                  June 1999
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Franks, et al.              Standards Track                    [Page 34]
+
diff --git a/standards/rfc2639.txt b/standards/rfc2639.txt
new file mode 100644
index 000000000..e3ab71684
--- /dev/null
+++ b/standards/rfc2639.txt
@@ -0,0 +1,3587 @@
+
+
+
+
+
+
+Network Working Group                                        T. Hastings
+Request for Comments: 2639                                     C. Manros
+Category: Informational                                Xerox Corporation
+                                                               July 1999
+
+
+          Internet Printing Protocol/1.0: Implementer's Guide
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies.  This document contains
+   information that supplements the IPP Model and Semantics [RFC2566]
+   and the IPP Transport and Encoding [RFC2565] documents.  It is
+   intended to help implementers understand IPP/1.0 and some of the
+   considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The full set of IPP documents includes:
+
+     Design Goals for an Internet Printing Protocol [RFC2567]
+     Rationale for the Structure and Model and Protocol for the Internet
+        Printing Protocol [RFC2568]
+     Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
+     Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
+     Mapping between LPD and IPP Protocols [RFC2569]
+
+   The document, "Design Goals for an Internet Printing Protocol", takes
+   a broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+
+
+
+
+
+Hastings & Manros            Informational                      [Page 1]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   administrators.  The design goals document calls out a subset of end
+   user requirements that are satisfied in IPP/1.0.  Operator and
+   administrator requirements are out of scope for version 1.0.
+
+   The document, "Rationale for the Structure and Model and Protocol for
+   the Internet Printing Protocol", describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specifications, and gives background and rationale for the
+   IETF working group's major decisions.
+
+   The document, "Internet Printing Protocol/1.0: Model and Semantics",
+   describes a simplified model with abstract objects, their attributes,
+   and their operations.  The model introduces a Printer and a Job.  The
+   Job supports multiple documents per Job.  The model document also
+   addresses how security, internationalization, and directory issues
+   are addressed.
+
+   The document, "Internet Printing Protocol/1.0: Encoding and
+   Transport", is a formal mapping of the abstract operations and
+   attributes defined in the model document onto HTTP/1.1.  It also
+   defines the encoding rules for a new Internet media type called
+   "application/ipp".
+
+   The document, "Mapping between LPD and IPP Protocols", gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+Table of Contents
+
+  1  Introduction......................................................4
+   1.1 Conformance language............................................4
+   1.2 Other terminology...............................................5
+  2  Model and Semantics...............................................5
+   2.1 Summary of Operation Attributes.................................5
+   2.2 Suggested Operation Processing Steps for IPP Objects ..........10
+       2.2.1 Suggested Operation Processing Steps for all Operations..11
+       2.2.1.1  Validate version number...............................11
+       2.2.1.2  Validate operation identifier.........................11
+       2.2.1.3  Validate the request identifier.......................11
+       2.2.1.4  Validate attribute group and attribute presence and
+                order.................................................12
+       2.2.1.5  Validate the values of the REQUIRED Operation
+                attributes............................................19
+       2.2.1.6  Validate the values of the OPTIONAL Operation
+                attributes............................................23
+     2.2.2 Suggested Additional Processing Steps for Operations that
+           Create/Validate Jobs and Add Documents.....................26
+       2.2.2.1  Default "ipp-attribute-fidelity" if not supplied......26
+
+
+
+Hastings & Manros            Informational                      [Page 2]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+       2.2.2.2  Check that the Printer object is accepting jobs.......26
+       2.2.2.3  Validate the values of the Job Template attributes....26
+     2.2.3 Algorithm for job validation...............................27
+       2.2.3.1  Check for conflicting Job Template attributes values..33
+       2.2.3.2  Decide whether to REJECT the request..................33
+       2.2.3.3  For the Validate-Job operation, RETURN one of the
+                success status codes..................................34
+       2.2.3.4  Create the Job object with attributes to support......34
+       2.2.3.5  Return one of the success status codes................36
+       2.2.3.6  Accept appended Document Content......................36
+       2.2.3.7  Scheduling and Starting to Process the Job............36
+       2.2.3.8  Completing the Job....................................37
+       2.2.3.9  Destroying the Job after completion...................37
+       2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
+   2.3 Status codes returned by operation ............................37
+     2.3.1 Printer Operations.........................................38
+       2.3.1.1  Print-Job.............................................38
+       2.3.1.2  Print-URI.............................................40
+       2.3.1.3  Validate-Job..........................................40
+       2.3.1.4  Create-Job............................................41
+       2.3.1.5  Get-Printer-Attributes................................41
+       2.3.1.6  Get-Jobs..............................................42
+     2.3.2 Job Operations.............................................43
+       2.3.2.1  Send-Document.........................................43
+       2.3.2.2  Send-URI..............................................44
+       2.3.2.3  Cancel-Job............................................44
+       2.3.2.4  Get-Job-Attributes....................................45
+   2.4 Validate-Job...................................................46
+   2.5 Case Sensitivity in URIs ......................................46
+   2.6 Character Sets, natural languages, and internationalization....46
+     2.6.1 Character set code conversion support .....................46
+     2.6.2 What charset to return when an unsupported charset is
+           requested?.................................................48
+     2.6.3 Natural Language Override (NLO) ...........................48
+   2.7 The "queued-job-count" Printer Description attribute...........50
+     2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
+     2.7.2 Is "queued-job-count" a good measure of how busy a printer
+           is?........................................................50
+   2.8 Sending empty attribute groups ................................50
+   2.9 Returning unsupported attributes in Get-Xxxx responses ........51
+   2.10 Returning job-state in Print-Job response ....................51
+   2.11 Flow controlling the data portion of a Print-Job request .....52
+   2.12 Multi-valued attributes ......................................53
+   2.13 Querying jobs with IPP that were submitted using other job
+        submission protocols .........................................53
+   2.14 The 'none' value for empty sets ..............................54
+   2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54
+
+
+
+
+Hastings & Manros            Informational                      [Page 3]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   2.16 The "multiple-document-handling" Job Template attribute and
+        support of multiple document jobs.............................54
+  3  Encoding and Transport...........................................55
+   3.1 General Headers................................................56
+   3.2 Request  Headers...............................................57
+   3.3 Response Headers...............................................58
+   3.4 Entity  Headers................................................59
+   3.5 Optional support for HTTP/1.0..................................60
+   3.6 HTTP/1.1 Chunking..............................................60
+     3.6.1 Disabling IPP Server Response Chunking.....................60
+     3.6.2 Warning About the Support of Chunked Requests..............60
+  4  References.......................................................61
+   4.1 Authors' Addresses.............................................62
+  5  Security Considerations..........................................62
+  6  Notices..........................................................62
+  Full Copyright Statement............................................65
+
+1  Introduction
+
+  This document contains information that supplements the IPP Model and
+  Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565]
+  documents.  As such this information is not part of the formal
+  specifications.  Instead information is presented to help implementers
+  understand the specification, including some of the motivation for
+  decisions taken by the committee in developing the specification.
+  Some of the implementation considerations are intended to help
+  implementers design their client and/or IPP object implementations.
+  If there are any contradictions between this document and [RFC2566] or
+  [RFC2565], those documents take precedence over this document.
+
+1.1 Conformance language
+
+  Usually, this document does not contain the terminology MUST, MUST
+  NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
+  However, when those terms do appear in this document, their intent is
+  to repeat what the [RFC2566] and [RFC2565] documents require and
+  allow, rather than specifying additional conformance requirements.
+  These terms are defined in section 13 on conformance terminology in
+  [RFC2566], most of which is taken from RFC 2119 [RFC2119].
+
+  Implementers should read section 13 in [RFC2566] in order to
+  understand these capitalized words.  The words MUST, MUST NOT, and
+  REQUIRED indicate what implementations are required to support in a
+  client or IPP object in order to be conformant to [RFC2566] and
+  [RFC2565].  MAY, NEED NOT, and OPTIONAL indicate was is merely allowed
+  as an implementer option.  The verbs SHOULD and SHOULD NOT indicate
+  suggested behavior, but which is not required or disallowed,
+  respectively, in order to conform to the specification.
+
+
+
+Hastings & Manros            Informational                      [Page 4]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+1.2 Other terminology
+
+  The term "sender" refers to the client that sends a request or an IPP
+  object that returns a response.  The term "receiver" refers to the IPP
+  object that receives a request and to a client that receives a
+  response.
+
+2  Model and Semantics
+
+  This section discusses various aspects of IPP/1.0 Model and Semantics
+  [RFC2566].
+
+2.1 Summary of Operation Attributes
+
+  Legend for the following table:
+
+      R indicates a REQUIRED operation or attribute for an
+        implementation to support
+
+      O indicates an OPTIONAL operation or attribute for an
+        implementation to support
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings & Manros            Informational                      [Page 5]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+    Table 1.  Summary of operation attributes for Printer operations
+
+                           Printer Operations
+
+                         Requests                         Responses
+
+     Operation           Print-   Pri  Crea Get-     Get- All
+     Attributes          Job,     nt-  te-  Printer- Jobs Opera-
+                         Validate URI  Job  Attribut      tions
+                         -Job     (O)  (O)  es
+
+     Operation parameters--REQUIRED to be supplied by the sender
+
+     operation-id           R      R    R      R      R
+
+     status-code                                            R
+
+     request-id             R      R    R      R      R     R
+
+     version-number         R      R    R      R      R     R
+
+     Operation attributes-REQUIRED to be supplied by the sender
+
+     attributes-charset     R      R    R      R      R     R
+
+     attributes-            R      R    R      R      R     R
+     natural-language
+
+     document-uri                   R
+
+     job-id*
+
+     job-uri*
+
+     last-document
+
+     printer-uri            R      R    R      R      R
+
+     Operation attributes-RECOMMENDED to be supplied by the sender
+
+     job-name               R      R    R
+
+     requesting-user-       R      R    R      R      R
+     name
+
+
+
+
+
+
+
+Hastings & Manros            Informational                      [Page 6]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+                           Printer Operations
+
+                         Requests                        Responses
+
+      Operation          Print-   Pri  Crea Get-    Get-  All
+      Attributes         Job,     nt-  te-  Printer Jobs  Opera-
+                         Vali-    URI  Job  Attri-        tions
+                         date-Job (O)  (O)  butes
+
+      Operation attributes-OPTIONAL to be supplied by the sender
+
+      status-message                                         O
+
+      compression           O     O
+
+      document-format       R     R           O
+
+      document-name         O     O
+
+      document-natural-     O     O
+      language
+
+      ipp-attribute-        R     R    R
+      fidelity
+
+      job-impressions       O     O    O
+
+      job-k-octets          O     O    O
+
+      job-media-sheets      O     O    O
+
+      limit                                           R
+
+      message
+
+      my-jobs                                         R
+
+      requested-                               R      R
+      attributes
+
+      which-jobs                                      R
+
+      *  "job-id" is REQUIRED only if used together with
+      "printer-uri" to identify the target job; otherwise, "job-
+      uri" is REQUIRED.
+
+
+
+
+
+
+Hastings & Manros            Informational                      [Page 7]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      Table 2.  Summary of operation attributes for Job operations
+
+
+                         Requests                         Responses
+
+      Operation          Send-    Send-  Cancel  Get-     All
+      Attributes         Document URI    -Job    Job-     Opera-
+                         (O)      (O)            Attri-   tions
+                                                 butes
+
+      Operation parameters--REQUIRED to be supplied by the sender
+
+      operation-id          R       R      R       R
+
+      status-code                                          R
+
+      request-id            R       R      R       R       R
+
+      version-number        R       R      R       R       R
+
+      Operation attributes-REQUIRED to be supplied by the sender
+
+      attributes-           R       R      R       R       R
+      charset
+
+      attributes-           R       R      R       R       R
+      natural-language
+
+      document-uri                   R
+
+      job-id*               R       R      R       R
+
+      job-uri*              R       R      R       R
+
+      last-document         R       R
+
+      printer-uri           R       R      R       R
+
+      Operation attributes-RECOMMENDED to be supplied by the
+      sender
+
+      job-name
+
+      requesting-user-      R       R      R       R
+      name
+
+
+
+
+
+
+Hastings & Manros            Informational                      [Page 8]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+                             Job Operations
+
+                           Requests                      Responses
+
+     Operation Attributes  Send-    Send-   Cance Get-    All
+                           Document URI     l-Job Job-    Opera-
+                           (O)      (O)           Attri-  tions
+                                                  butes
+
+     Operation attributes.OPTIONAL to be supplied by the sender
+
+     status-message                                       O
+
+     compression               O       O
+
+     document-format           R       R
+
+     document-name             O       O
+
+     document-natural-         O       O
+     language
+
+     ipp-attribute-
+     fidelity
+
+     job-impressions
+
+     job-k-octets
+
+     job-media-sheets
+
+     limit
+
+     message                                   O
+
+     my-jobs
+
+     requested-attributes                             R
+
+     which-jobs
+
+     *  "job-id" is REQUIRED only if used together with "printer-
+     uri" to identify the target job; otherwise, "job-uri" is
+     REQUIRED.
+
+
+
+
+
+
+
+Hastings & Manros            Informational                      [Page 9]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.2 Suggested Operation Processing Steps for IPP Objects
+
+   This section suggests the steps and error checks that an IPP object
+   MAY perform when processing requests and returning responses.  An IPP
+   object MAY perform some or all of the error checks.  However, some
+   implementations MAY choose to be more forgiving than the error checks
+   shown here, in order to be able to accept requests from non-
+   conforming clients.  Not performing all of these error checks is a
+   so-called "forgiving" implementation.  On the other hand, clients
+   that successfully submit requests to IPP objects that do perform all
+   the error checks will be more likely to be able to interoperate with
+   other IPP object implementations.  Thus an implementer of an IPP
+   object needs to decide whether to be a "forgiving" or a "strict"
+   implementation.  Therefore, the error status codes returned may
+   differ between implementations.   Consequentially, client SHOULD NOT
+   expect exactly the error code processing described in this section.
+
+   When an IPP object receives a request, the IPP object either accepts
+   or rejects the request. In order to determine whether or not to
+   accept or reject the request, the IPP object SHOULD execute the
+   following steps.  The order of the steps may be rearranged and/or
+   combined, including making one or multiple passes over the request.
+
+   A client MUST supply requests that would pass all of the error checks
+   indicated here in order to be a conforming client.  Therefore, a
+   client SHOULD supply requests that are conforming, in order to avoid
+   being rejected by some IPP object implementations and/or risking
+   different semantics by different implementations of forgiving
+   implementations.  For example, a forgiving implementation that
+   accepts multiple occurrences of the same attribute, rather than
+   rejecting the request might use the first occurrences, while another
+   might use the last occurrence.  Thus such a non-conforming client
+   would get different results from the two forgiving implementations.
+
+   In the following, processing continues step by step until a "RETURNS
+   the xxx status code ." statement is encountered.  Error returns are
+   indicated by the verb: "REJECTS".  Since clients have difficulty
+   getting the status code before sending all of the document data in a
+   Print-Job request, clients SHOULD use the Validate-Job operation
+   before sending large documents to be printed, in order to validate
+   whether the IPP Printer will accept the job or not.
+
+   It is assumed that security authentication and authorization has
+   already taken place at a lower layer.
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 10]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.2.1 Suggested Operation Processing Steps for all Operations
+
+   This section is intended to apply to all operations.  The next
+   section contains the additional steps for the Print-Job, Validate-
+   Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
+   that create jobs, adds documents, and validates jobs.
+
+2.2.1.1   Validate version number
+
+   Every request and every response contains the "version-number"
+   attribute.  The value of this attribute is the major and minor
+   version number of the syntax and semantics that the client and IPP
+   object is using, respectively.  The "version-number" attribute
+   remains in a fixed position across all future versions so that all
+   clients and IPP object that support future versions can determine
+   which version is being used.  The IPP object checks to see if the
+   major version number supplied in the request is supported.  If not,
+   the Printer object REJECTS the request and RETURNS the 'server-
+   error-version-not-supported' status code in the response.  The IPP
+   object returns in the "version-number" response attribute the major
+   and minor version for the error response.  Thus the client can learn
+   at least one major and minor version that the IPP object supports.
+   The IPP object is encouraged to return the closest version number to
+   the one supplied by the client.
+
+   The checking of the minor version number is implementation dependent,
+   however if the client supplied minor version is explicitly supported,
+   the IPP object MUST respond using that identical minor version
+   number.  If the requested minor version is not supported (the
+   requested minor version is either higher or lower) than a supported
+   minor version, the IPP object SHOULD return the closest supported
+   minor version.
+
+2.2.1.2   Validate operation identifier
+
+   The Printer object checks to see if the "operation-id" attribute
+   supplied by the client is supported as indicated in the Printer
+   object's "operations-supported" attribute.  If not, the Printer
+   REJECTS the request and returns the 'server-error-operation-not-
+   supported' status code in the response.
+
+2.2.1.3   Validate the request identifier
+
+   The Printer object SHOULD NOT check to see if the "request-id"
+   attribute supplied by the client is in range: between 1 and 2**31 - 1
+   (inclusive), but copies all 32 bits.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 11]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Note: The "version-number",  "operation-id", and the "request-id"
+   parameters are in fixed octet positions in the IPP/1.0 encoding.  The
+   "version-number" parameter will be the same fixed octet position in
+   all versions of the protocol.  These fields are validated before
+   proceeding with the rest of the validation.
+
+2.2.1.4   Validate attribute group and attribute presence and order
+
+   The order of the following validation steps depends on
+   implementation.
+
+2.2.1.4.1 Validate the presence and order of attribute groups
+
+   Client requests and IPP object responses contain attribute groups
+   that Section 3 requires to be present and in a specified order.  An
+   IPP object verifies that the attribute groups are present and in the
+   correct order in requests supplied by clients (attribute groups
+   without an * in the following tables).
+
+   If an IPP object receives a request with (1) required attribute
+   groups missing, or (2) the attributes groups are out of order, or (3)
+   the groups are repeated, the IPP object REJECTS the request and
+   RETURNS the 'client-error-bad-request' status code.  For example, it
+   is an error for the Job Template Attributes group to occur before the
+   Operation Attributes group, for the Operation Attributes group to be
+   omitted, or for an attribute group to occur more than once, except in
+   the Get-Jobs response.
+
+   Since this kind of attribute group error is most likely to be an
+   error detected by a client developer rather than by a customer, the
+   IPP object NEED NOT return an indication of which attribute group was
+   in error in either the Unsupported Attributes group or the Status
+   Message.  Also, the IPP object NEED NOT find all attribute group
+   errors before returning this error.
+
+2.2.1.4.2 Ignore unknown attribute groups in the expected position
+
+   Future attribute groups may be added to the specification at the end
+   of requests just before the Document Content and at the end of
+   response, except for the Get-Jobs response, where it maybe there or
+   before the first job attributes returned.  If an IPP object receives
+   an unknown attribute group in these positions, it ignores the entire
+   group, rather than returning an error, since that group may be a new
+   group in a later minor version of the protocol that can be ignored.
+   (If the new attribute group cannot be ignored without confusing the
+   client, the major version number would have been increased in the
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 12]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   protocol document and in the request).  If the unknown group occurs
+   in a different position, the IPP object REJECTS the request and
+   RETURNS the 'client-error-bad-request' status code.
+
+   Clients also ignore unknown attribute groups returned in a response.
+
+   Note:  By validating that requests are in the proper form, IPP
+   objects force clients to use the proper form which, in turn,
+   increases the chances that customers will be able to use such clients
+   from multiple vendors with IPP objects from other vendors.
+
+2.2.1.4.3 Validate the presence of a single occurrence of required
+          Operation attributes
+
+   Client requests and IPP object responses contain Operation attributes
+   that [RFC2566] Section 3 requires to be present.  Attributes within a
+   group may be in any order, except for the ordering of target,
+   charset, and natural languages attributes.  These attributes MUST be
+   first, and MUST be supplied in the following order: charset, natural
+   language, and then target. An IPP object verifies that the attributes
+   that Section 4 requires to be supplied by the client have been
+   supplied in the request (attributes without an * in the following
+   tables).  An asterisk (*) indicates groups and Operation attributes
+   that the client may omit in a request or an IPP object may omit in a
+   response.
+
+   If an IPP object receives a request with required attributes missing
+   or repeated from a group or in the wrong position, the behavior of
+   the IPP object is IMPLEMENTATION DEPENDENT.  Some of the possible
+   implementations are:
+
+      1.REJECTS the request and RETURNS the 'client-error-bad-request'
+        status code
+
+      2.accepts the request and uses the first occurrence of the
+        attribute no matter where it is
+
+      3.accepts the request and uses the last occurrence of the
+        attribute no matter where it is
+
+      4.accept the request and assume some default value for the missing
+        attribute
+
+   Therefore, client MUST send conforming requests, if they want to
+   receive the same behavior from all IPP object implementations.  For
+   example, it is an error for the "attributes-charset" or "attributes-
+   natural-language" attribute to be omitted in any operation request,
+   or for an Operation attribute to be supplied in a Job Template group
+
+
+
+Hastings & Manros            Informational                     [Page 13]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   or a Job Template attribute to be supplied in an Operation Attribute
+   group in a create request.  It is also an error to supply the
+   "attributes-charset" attribute twice.
+
+   Since these kinds of attribute errors are most likely to be detected
+   by a client developer rather than by a customer, the IPP object NEED
+   NOT return an indication of which attribute was in error in either
+   the Unsupported Attributes group or the Status Message.  Also, the
+   IPP object NEED NOT find all attribute errors before returning this
+   error.
+
+   The following tables list all the attributes for all the operations
+   by attribute group in each request and each response.  The order of
+   the groups is the order that the client supplies the groups as
+   specified in [RFC2566] Section 3.  The order of the attributes within
+   a group is arbitrary, except as noted for some of the special
+   operation attributes (charset, natural language, and target).  The
+   tables below use the following notation:
+
+     R   indicates a REQUIRED attribute that an IPP object MUST support
+     O   indicates an OPTIONAL attribute that an IPP object NEED NOT
+               support
+     *   indicates that a client MAY omit the attribute in a request
+               and that an IPP object MAY omit the attribute in a
+               response. The absence of an * means that a client MUST
+               supply the attribute in a request and an IPP object MUST
+               supply the attribute in a response.
+
+                            Operation Requests
+
+   The tables below show the attributes in their proper attribute groups
+   for operation requests:
+
+   Note: All operation requests contain "version-number", "operation-
+   id", and "request-id" parameters.
+
+   Print-Job Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             printer-uri (R)
+             requesting-user-name (R*)
+             job-name (R*)
+             ipp-attribute-fidelity (R*)
+             document-name (R*)
+             document-format (R*)
+             document-natural-language (O*)
+             compression (O*)
+
+
+
+Hastings & Manros            Informational                     [Page 14]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+             job-k-octets (O*)
+             job-impressions (O*)
+             job-media-sheets (O*)
+        Group 2: Job Template Attributes (R*)
+             <Job Template attributes> (O*)
+                  (see [RFC2566] Section 4.2)
+        Group 3: Document Content (R)
+             <document content>
+
+   Validate-Job Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             printer-uri (R)
+             requesting-user-name (R*)
+             job-name (R*)
+             ipp-attribute-fidelity (R*)
+             document-name (R*)
+             document-format (R*)
+             document-natural-language (O*)
+             compression (O*)
+             job-k-octets (O*)
+             job-impressions (O*)
+             job-media-sheets (O*)
+        Group 2: Job Template Attributes (R*)
+             <Job Template attributes> (O*)
+                  (see [RFC2566] Section 4.2)
+
+   Create-Job Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             printer-uri (R)
+             requesting-user-name (R*)
+             job-name (R*)
+             ipp-attribute-fidelity (R*)
+             job-k-octets (O*)
+             job-impressions (O*)
+             job-media-sheets (O*)
+        Group 2: Job Template Attributes (R*)
+             <Job Template attributes> (O*) (see
+                  (see [RFC2566] Section 4.2)
+
+   Print-URI Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             printer-uri (R)
+
+
+
+Hastings & Manros            Informational                     [Page 15]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+             document-uri (R)
+             requesting-user-name (R*)
+             job-name (R*)
+             ipp-attribute-fidelity (R*)
+             document-name (R*)
+             document-format (R*)
+             document-natural-language (O*)
+             compression (O*)
+             job-k-octets (O*)
+             job-impressions (O*)
+             job-media-sheets (O*)
+        Group 2: Job Template Attributes (R*)
+             <Job Template attributes> (O*) (see
+                  (see [RFC2566] Section 4.2)
+
+   Send-Document Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             (printer-uri & job-id) | job-uri (R)
+             last-document (R)
+             requesting-user-name (R*)
+             document-name (R*)
+             document-format (R*)
+             document-natural-language (O*)
+             compression (O*)
+        Group 2: Document Content (R*)
+             <document content>
+
+   Send-URI Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             (printer-uri & job-id) | job-uri (R)
+             last-document (R)
+             document-uri (R)
+             requesting-user-name (R*)
+             document-name (R*)
+             document-format (R*)
+             document-natural-language (O*)
+             compression (O*)
+
+
+
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 16]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Cancel-Job Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             (printer-uri & job-id) | job-uri (R)
+             requesting-user-name (R*)
+             message (O*)
+
+   Get-Printer-Attributes Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             printer-uri (R)
+             requesting-user-name (R*)
+             requested-attributes (R*)
+             document-format (R*)
+
+   Get-Job-Attributes Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             (printer-uri & job-id) | job-uri (R)
+             requesting-user-name (R*)
+             requested-attributes (R*)
+
+   Get-Jobs Request:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             printer-uri (R)
+             requesting-user-name (R*)
+             limit (R*)
+             requested-attributes (R*)
+             which-jobs (R*)
+             my-jobs (R*)
+
+
+                            Operation Responses
+
+   The tables below show the response attributes in their proper
+   attribute groups for responses.
+
+   Note: All operation responses contain "version-number", "status-
+   code", and "request-id" parameters.
+
+   Print-Job Response:
+   Print-URI Response:
+   Create-Job Response:
+
+
+
+Hastings & Manros            Informational                     [Page 17]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Send-Document Response:
+   Send-URI Response:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             status-message (O*)
+        Group 2: Unsupported Attributes (R*) (see Note 3)
+             <unsupported attributes> (R*)
+        Group 3: Job Object Attributes(R*) (see Note 2)
+             job-uri (R)
+             job-id (R)
+             job-state (R)
+             job-state-reasons (O*)
+             job-state-message (O*)
+             number-of-intervening-jobs (O*)
+
+   Validate-Job Response:
+   Cancel-Job Response:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             status-message (O*)
+        Group 2: Unsupported Attributes (R*) (see Note 3)
+             <unsupported attributes> (R*)
+
+   Note 2 - the Job Object Attributes and Printer Object Attributes are
+   returned only if the IPP object returns one of the success status
+   codes.
+
+   Note 3 - the Unsupported Attributes Group is present only if the
+   client included some Operation and/or Job Template attributes or
+   values that the Printer doesn't support whether a success or an error
+   return.
+
+   Get-Printer-Attributes Response:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             status-message (O*)
+        Group 2: Unsupported Attributes (R*) (see Note 4)
+             <unsupported attributes> (R*)
+        Group 3: Printer Object Attributes(R*) (see Note 2)
+             <requested attributes> (R*)
+
+   Note 4 - the Unsupported Attributes Group is present only if the
+   client included some Operation attributes that the Printer doesn't
+   support whether a success or an error return.
+
+
+
+
+Hastings & Manros            Informational                     [Page 18]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Get-Job-Attributes Response:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             status-message (O*)
+        Group 2: Unsupported Attributes (R*) (see Note 4)
+             <unsupported attributes> (R*)
+        Group 3: Job Object Attributes(R*) (see Note 2)
+             <requested attributes> (R*)
+
+   Get-Jobs Response:
+        Group 1: Operation Attributes (R)
+             attributes-charset (R)
+             attributes-natural-language (R)
+             status-message (O*)
+        Group 2: Unsupported Attributes (R*) (see Note 4)
+             <unsupported attributes> (R*)
+        Group 3: Job Object Attributes(R*) (see Note 2, 5)
+             <requested attributes> (R*)
+
+   Note 5:  for the Get-Jobs operation the response contains a separate
+   Job Object Attributes group 3 to N containing requested-attributes
+   for each job object in the response.
+
+2.2.1.5   Validate the values of the REQUIRED Operation attributes
+
+   An IPP object validates the values supplied by the client of the
+   REQUIRED Operation attribute that the IPP object MUST support.  The
+   next section specifies the validation of the values of the OPTIONAL
+   Operation attributes that IPP objects MAY support.
+
+   The IPP object performs the following syntactic validation checks of
+   each Operation attribute value:
+
+      a)that the length of each Operation attribute value is correct for
+        the attribute syntax tag supplied by the client according to
+        [RFC2566] Section 4.1,
+
+      b)that the attribute syntax tag is correct for that Operation
+        attribute according to [RFC2566] Section 3,
+
+      c)that the value is in the range specified for that Operation
+        attribute according to [RFC2566] Section 3,
+
+      d)that multiple values are supplied by the client only for
+        operation attributes that are multi-valued, i.e., that are
+        1setOf X according to [RFC2566] Section 3.
+
+
+
+
+Hastings & Manros            Informational                     [Page 19]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   If any of these checks fail, the IPP object REJECTS the request and
+   RETURNS the 'client-error-bad-request' or the 'client-error-request-
+   value-too-long' status code.  Since such an error is most likely to
+   be an error detected by a client developer, rather than by an end-
+   user, the IPP object NEED NOT return an indication of which attribute
+   had the error in either the Unsupported Attributes Group or the
+
+   Status Message.  The description for each of these syntactic checks
+   is explicitly expressed in the first IF statement in the following
+   table.
+
+   In addition, the IPP object checks each Operation attribute value
+   against some Printer object attribute or some hard-coded value if
+   there is no "xxx-supported" Printer object attribute defined. If its
+   value is not among those supported or is not in the range supported,
+   then the IPP object REJECTS the request and RETURNS the error status
+   code indicated in the table by the second IF statement.  If the value
+   of the Printer object's "xxx-supported" attribute is 'no-value'
+   (because the system administrator hasn't configured a value), the
+   check always fails.
+
+   attributes-charset (charset)
+
+      IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
+         error-bad-request'.
+
+      IF the value length is greater than 63 octets, REJECT/RETURN '
+         client-error-request-value-too-long'.
+      IF NOT in the Printer object's "charset-supported" attribute,
+         REJECT/RETURN "client-error-charset-not-supported".
+
+
+   attributes-natural-language(naturalLanguage)
+
+      IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
+         'client-error-bad-request'.
+      IF the value length is greater than 63 octets, REJECT/RETURN '
+         client-error-request-value-too-long'.
+      ACCEPT the request even if not a member of the set in the Printer
+         object's "generated-natural-language-supported" attribute.  If
+         the supplied value is not a member of the Printer object's
+         "generated-natural-language-supported" attribute, use the
+         Printer object's "natural-language-configured" value.
+
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 20]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   requesting-user-name
+
+      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF the IPP object can obtain a better authenticated name, use it
+         instead.
+
+
+   job-name(name)
+
+      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NOT supplied by the client, the Printer object creates a name
+         from the document-name or document-uri.
+
+
+   document-name (name)
+
+      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+
+
+   ipp-attribute-fidelity (boolean)
+
+      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
+         REJECT/RETURN 'client-error-bad-request'.
+      IF the value length is NOT equal to 1 octet, REJECT/RETURN '
+         client-error-request-value-too-long'
+      IF NOT supplied by the client, the IPP object assumes the value
+         'false'.
+
+
+   document-format (mimeMediaType)
+
+      IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
+         'client-error-bad-request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NOT in the Printer object's "document-format-supported"
+         attribute, REJECT/RETURN 'client-error-document-format-not-
+         supported'
+
+
+
+
+Hastings & Manros            Informational                     [Page 21]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      IF NOT supplied by the client, the IPP object assumes the value of
+         the Printer object's "document-format-default" attribute.
+
+
+   document-uri (uri)
+
+      IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
+         error-bad-request'.
+      IF the value length is greater than 1023 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF scheme is NOT in the Printer object's "reference-uri-schemes-
+         supported" attribute, REJECT/RETURN 'client-error-uri-scheme-
+         not-supported'.
+      The Printer object MAY check to see if the document exists and is
+         accessible.  If the document is not found or is not accessible,
+         REJECT/RETURN 'client-error-not found'.
+
+
+   last-document (boolean)
+
+      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
+         REJECT/RETURN 'client-error-bad-request'.
+      IF the value length is NOT equal to 1 octet, REJECT/RETURN '
+         client-error-request-value-too-long'
+
+
+   job-id (integer(1:MAX))
+
+      IF NOT an single 'integer' value equal to 4 octets AND in the
+         range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
+
+      IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
+         error-not-found' or 'client-error-gone' status code, if keep
+         track of recently deleted jobs.
+
+
+   requested-attributes (1setOf keyword)
+
+      IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error-
+         bad-request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      Ignore unsupported values which are the keyword names of
+         unsupported attributes.  Don't bother to copy such requested
+         (unsupported) attributes to the Unsupported Attribute response
+         group since the response will not return them.
+
+
+
+Hastings & Manros            Informational                     [Page 22]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   which-jobs (type2 keyword)
+
+      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
+         the unsupported value to the Unsupported Attributes response
+         group and REJECT/RETURN 'client-error-attributes-or-values-
+         not-supported'.
+      Note: a Printer still supports the 'completed' value even if it
+         keeps no completed/canceled/aborted jobs:  by returning no jobs
+         when so queried.
+      IF NOT supplied by the client, the IPP object assumes the 'not-
+         completed' value.
+
+
+   my-jobs (boolean)
+
+      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
+         REJECT/RETURN 'client-error-bad-request'.
+      IF the value length is NOT equal to 1 octet, REJECT/RETURN '
+         client-error-request-value-too-long'
+      IF NOT supplied by the client, the IPP object assumes the 'false'
+         value.
+
+
+   limit (integer(1:MAX))
+
+      IF NOT a single 'integer' value equal to 4 octets AND in the range
+         1 to MAX, REJECT/RETURN 'client-error-bad-request'.
+      IF NOT supplied by the client, the IPP object returns all jobs, no
+         matter how many.
+
+2.2.1.6   Validate the values of the OPTIONAL Operation attributes
+
+   OPTIONAL Operation attributes are those that an IPP object MAY or MAY
+   NOT support.  An IPP object validates the values of the OPTIONAL
+   attributes supplied by the client.  The IPP object performs the same
+   syntactic validation checks for each OPTIONAL attribute value as in
+   Section 2.2.1.5.  As in Section 2.2.1.5, if any fail, the IPP object
+   REJECTS the request and RETURNS the 'client-error-bad-request' or the
+   'client-error-request-value-too-long' status code.
+
+   In addition, the IPP object checks each Operation attribute value
+   against some Printer attribute or some hard-coded value if there is
+   no "xxx-supported" Printer attribute defined. If its value is not
+   among those supported or is not in the range supported, then the IPP
+
+
+
+Hastings & Manros            Informational                     [Page 23]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   object REJECTS the request and RETURNS the error status code
+   indicated in the table.  If the value of the Printer object's "xxx-
+   supported" attribute is 'no-value' (because the system administrator
+   hasn't configured a value), the check always fails.
+
+   If the IPP object doesn't recognize/support an attribute, the IPP
+   object treats the attribute as an unknown or unsupported attribute
+   (see the last row in the table below).
+
+   document-natural-language (naturalLanguage)
+
+      IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN '
+         client-error-bad-request'.
+      IF the value length is greater than 63 octets, REJECT/RETURN '
+         client-error-request-value-too-long'.
+      IF NOT a value that the Printer object supports in document
+         formats, (no corresponding "xxx-supported" Printer attribute),
+         REJECT/RETURN 'client-error-natural-language-not-supported'.
+
+
+   compression (type3 keyword)
+
+      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN '
+         client-error-request-value-too-long'.
+      IF NOT in the Printer object's "compression-supported" attribute,
+         copy the attribute and the unsupported value to the Unsupported
+         Attributes response group and REJECT/RETURN 'client-error-
+         attributes-or-values-not-supported'.
+
+
+   job-k-octets (integer(0:MAX))
+
+      IF NOT a single 'integer' value equal to 4 octets,
+      REJECT/RETURN 'client-error-bad-request'.
+      IF NOT in the range of the Printer object's "job-k-octets-
+         supported" attribute, copy the attribute and the unsupported
+         value to the Unsupported Attributes response group and
+         REJECT/RETURN 'client-error-attributes-or-values-not-
+         supported'.
+
+
+   job-impressions (integer(0:MAX))
+
+      IF NOT a single 'integer' value equal to 4 octets,
+      REJECT/RETURN 'client-error-bad-request'.
+
+
+
+
+Hastings & Manros            Informational                     [Page 24]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      IF NOT in the range of the Printer object's "job-impressions-
+         supported" attribute, copy the attribute and the unsupported
+         value to the Unsupported Attributes response group and
+         REJECT/RETURN 'client-error-attributes-or-values-not-
+         supported'.
+
+
+   job-media-sheets (integer(0:MAX))
+
+      IF NOT a single 'integer' value equal to 4 octets,
+      REJECT/RETURN 'client-error-bad-request'.
+      IF NOT in the range of the Printer object's "job-media-sheets-
+         supported" attribute, copy the attribute and the unsupported
+         value to the Unsupported Attributes response group and
+         REJECT/RETURN 'client-error-attributes-or-values-not-
+         supported'.
+
+
+   message (text(127))
+
+      IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 127 octets,
+      REJECT/RETURN 'client-error-request-value-too-long'.
+
+
+   unknown or unsupported attribute
+
+      IF the attribute syntax supplied by the client is supported but
+         the length is not legal for that attribute syntax,
+         REJECT/RETURN 'client-error-request-value-too-long'.
+      ELSE copy the attribute and value to the Unsupported Attributes
+         response group and change the attribute value to the "out-of-
+         band" 'unsupported' value, but otherwise ignore the attribute.
+
+      Note: Future Operation attributes may be added to the protocol
+      specification that may occur anywhere in the specified group.
+      When the operation is otherwise successful, the IPP object returns
+      the 'successful-ok-ignored-or-substituted-attributes' status code.
+      Ignoring unsupported Operation attributes in all operations is
+      analogous to the handling of unsupported Job Template attributes
+      in the create and Validate-Job operations when the client supplies
+      the "ipp-attribute-fidelity" Operation attribute with the 'false'
+      value.  This last rule is so that we can add OPTIONAL Operation
+      attributes to future versions of IPP so that older clients can
+      inter-work with new IPP objects and newer clients can inter-work
+      with older IPP objects.  (If the new attribute cannot be ignored
+      without performing unexpectedly, the major version number would
+
+
+
+Hastings & Manros            Informational                     [Page 25]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      have been increased in the protocol document and in the request).
+      This rule for Operation attributes is independent of the value of
+      the "ipp-attribute-fidelity" attribute.   For example, if an IPP
+      object doesn't support the OPTIONAL "job-k-octets" attribute', the
+      IPP object treats "job-k-octets" as an unknown attribute and only
+      checks the length for the 'integer' attribute syntax supplied by
+      the client.  If it is not four octets, the IPP object REJECTS the
+      request and RETURNS the 'client-error-bad-request' status code,
+      else the IPP object copies the attribute to the Unsupported
+      Attribute response group, setting the value to the "out-of-band" '
+      unsupported' value, but otherwise ignores the attribute.
+
+2.2.2 Suggested Additional Processing Steps for Operations that
+      Create/Validate Jobs and Add Documents
+
+   This section in combination with the previous section recommends the
+   processing steps for the Print-Job, Validate-Job, Print-URI, Create-
+   Job, Send-Document, and Send-URI operations that IPP objects SHOULD
+   use.  These are the operations that create jobs, validate a Print-Job
+   request, and add documents to a job.
+
+2.2.2.1   Default "ipp-attribute-fidelity" if not supplied
+
+   The Printer object checks to see if the client supplied an "ipp-
+   attribute-fidelity" Operation attribute.  If the attribute is not
+   supplied by the client, the IPP object assumes that the value is
+   'false'.
+
+2.2.2.2   Check that the Printer object is accepting jobs
+
+   If the value of the Printer object's "printer-is-accepting-jobs" is
+   'false', the Printer object REJECTS the request and RETURNS the
+   'server-error-not-accepting-jobs' status code.
+
+2.2.2.3   Validate the values of the Job Template attributes
+
+   An IPP object validates the values of all Job Template attribute
+   supplied by the client.  The IPP object performs the analogous
+   syntactic validation checks of each Job Template attribute value that
+   it performs for Operation attributes (see Section 2.2.1.5.):
+
+      a)that the length of each value is correct for the attribute
+        syntax tag supplied by the client according to [RFC2566] Section
+        4.1.
+
+      b)that the attribute syntax tag is correct for that attribute
+        according to [RFC2566] Sections 4.2 to 4.4.
+
+
+
+
+Hastings & Manros            Informational                     [Page 26]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      c)that multiple values are supplied only for multi-valued
+        attributes, i.e., that are 1setOf  X according to [RFC2566]
+        Sections 4.2 to 4.4.
+
+   As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP
+   object REJECTS the request and RETURNS the 'client-error-bad-request'
+   or 'client-error-request-value-too-long' status code as appropriate,
+   independent of the value of the "ipp-attribute-fidelity".  Since such
+   an error is most likely to be an error detected by a client
+   developer, rather than by an end-user, the IPP object NEED NOT return
+   an indication of which attribute had the error in either the
+   Unsupported Attributes Group or the Status Message.  The description
+   for each of these syntactic checks is explicitly expressed in the
+   first IF statement in the following table.
+
+   Each Job Template attribute MUST occur no more than once.  If an IPP
+   Printer receives a create request with multiple occurrences of a Job
+   Template attribute, it MAY:
+
+      1.reject the operation and return the 'client-error-bad syntax'
+        error status code
+
+      2.accept the operation and use the first occurrence of the
+        attribute
+
+      3.accept the operation and use the last occurrence of the
+        attribute
+
+   depending on implementation.  Therefore, clients MUST NOT supply
+   multiple occurrences of the same Job Template attribute in the Job
+   Attributes group in the request.
+
+2.2.3 Algorithm for job validation
+
+   The process of validating a Job-Template attribute "xxx" against a
+   Printer attribute "xxx-supported" can use the following validation
+   algorithm (see section 3.2.1.2 in [RFC2566]).
+
+   To validate the value U of Job-Template attribute "xxx" against the
+   value V of Printer "xxx-supported", perform the following algorithm:
+
+      1.If U is multi-valued, validate each value X of U by performing
+        the algorithm in Table 3 with each value X. Each validation is
+        separate from the standpoint of returning unsupported values.
+
+        Example: If U is "finishings" that the client supplies with
+        'staple', 'bind' values, then X takes on the successive values:
+        'staple', then 'bind'
+
+
+
+Hastings & Manros            Informational                     [Page 27]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      2.If V is multi-valued, validate X against each Z of V by
+        performing the algorithm in Table 3 with each value Z.  If a
+        value Z validates, the validation for the attribute value X
+        succeeds. If it fails, the algorithm is applied to the next
+        value Z of V. If there are no more values Z of V, validation
+        fails.
+
+        Example: If V is "sides-supported" with values: 'one-sided',
+        'two-sided-long', and 'two-sided-short', then Z takes on the
+        successive values: 'one-sided', 'two-sided-long', and
+        'two-sided-short'.  If the client supplies "sides" with 'two-
+        sided-long', the first comparison fails ('one-sided' is not
+        equal to 'two-sided-long'), the second comparison succeeds
+        ('two-sided-long' is equal to 'two-sided-long"), and the third
+        comparison ('two-sided-short' with 'two-sided-long') is not even
+        performed.
+
+      3.If both U and V are single-valued, let X be U and Z be V and use
+        the validation rules in Table 3.
+
+            Table 3 - Rules for validating single values X against Z
+
+     attribute    attribute       validated if:
+     syntax of X  syntax of Z
+
+     integer      rangeOfInteger  X is within the range of
+                                   Z
+
+     uri          uriScheme       the uri scheme in X is
+                                   equal to Z
+
+     any          boolean         the value of Z is TRUE
+
+     any          any             X and Z are of the same
+                                   type and are equal.
+
+   If the value of the Printer object's "xxx-supported" attribute is '
+   no-value' (because the system administrator hasn't configured a
+   value), the check always fails.  If the check fails, the IPP object
+   copies the attribute to the Unsupported Attributes response group
+   with its unsupported value.  If the attribute contains more than one
+   value, each value is checked and each unsupported value is separately
+   copied, while supported values are not copied.  If an IPP object
+   doesn't recognize/support a Job Template attribute, i.e., there is no
+   corresponding Printer object "xxx-supported" attribute, the IPP
+   object treats the attribute as an unknown or unsupported attribute
+   (see the last row in the table below).
+
+
+
+
+Hastings & Manros            Informational                     [Page 28]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   If some Job Template attributes are supported for some document
+   formats and not for others or the values are different for different
+   document formats, the IPP object SHOULD take that into account in
+   this validation using the value of the "document-format" supplied by
+   the client (or defaulted to the value of the Printer's "document-
+   format-default" attribute, if not supplied by the client).  For
+   example, if "number-up" is supported for the 'text/plain' document
+   format, but not for the 'application/postscript' document format, the
+   check SHOULD (though it NEED NOT) depend on the value of the
+   "document-format" operation attribute.  See "document-format" in
+   [RFC2566] section 3.2.1.1 and 3.2.5.1.
+
+   Note: whether the request is accepted or rejected is determined by
+   the value of the "ipp-attribute-fidelity" attribute in a subsequent
+   step, so that all Job Template attribute supplied are examined and
+   all unsupported attributes and/or values are copied to the
+   Unsupported Attributes response group.
+
+   job-priority (integer(1:100))
+
+      IF NOT a single 'integer' value with a length equal to 4 octets,
+         REJECT/RETURN 'client-error-bad-request'.
+      IF NOT supplied by the client, use the value of the Printer
+         object's "job-priority-default" attribute at job submission
+         time.
+      IF NOT in the range 1 to 100, inclusive, copy the attribute and
+         the unsupported value to the Unsupported Attributes response
+         group.
+      Map the value to the nearest supported value in the range 1:100 as
+         specified by the number of discrete values indicated by the
+         value of the Printer's "job-priority-supported" attribute.  See
+         the formula in [RFC2566] Section 4.2.1.
+
+   job-hold-until (type3 keyword | name)
+
+      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
+         error-bad-request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NOT supplied by the client, use the value of the Printer
+         object's "job-hold-until" attribute at job submission time.
+      IF NOT in the Printer object's "job-hold-until-supported"
+         attribute, copy the attribute and the unsupported value to the
+         Unsupported Attributes response group.
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 29]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   job-sheets (type3 keyword | name)
+
+      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
+         error-bad-request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NOT in the Printer object's "job-sheets-supported" attribute,
+         copy the attribute and the unsupported value to the Unsupported
+         Attributes response group.
+
+   multiple-document-handling (type2 keyword)
+
+      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NOT in the Printer object's "multiple-document-handling-
+         supported" attribute, copy the attribute and the unsupported
+         value to the Unsupported Attributes response group.
+
+   copies (integer(1:MAX))
+
+      IF NOT a single 'integer' value with a length equal to 4 octets,
+      REJECT/RETURN 'client-error-bad-request'.
+      IF NOT in range of the Printer object's "copies-supported"
+         attribute copy the attribute and the unsupported value to the
+         Unsupported
+         Attributes response group.
+
+   finishings (1setOf type2 enum)
+
+      IF NOT an 'enum' value(s) each with a length equal to 4 octets,
+         REJECT/RETURN 'client-error-bad-request'.
+      IF NOT in the Printer object's "finishings-supported" attribute,
+         copy the attribute and the unsupported value(s), but not any
+         supported values, to the Unsupported Attributes response group.
+
+   page-ranges (1setOf  rangeOfInteger(1:MAX))
+
+      IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
+         octets, REJECT/RETURN 'client-error-bad-request'.
+      IF first value is greater than second value in any range, the
+         ranges are not in ascending order, or ranges overlap,
+         REJECT/RETURN 'client-error-bad-request'.
+      IF the value of the Printer object's "page-ranges-supported"
+         attribute is 'false', copy the attribute to the Unsupported
+         Attributes response group and set the value to the "out-of-
+         band" 'unsupported' value.
+
+
+
+Hastings & Manros            Informational                     [Page 30]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   sides (type2 keyword)
+
+      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
+         request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NOT in the Printer object's "sides-supported" attribute, copy
+         the attribute and the unsupported value to the Unsupported
+         Attributes response group.
+
+   number-up (integer(1:MAX))
+
+      IF NOT a single 'integer' value with a length equal to 4 octets,
+      REJECT/RETURN 'client-error-bad-request'.
+      IF NOT a value or in the range of one of the values of the Printer
+         object's "number-up-supported" attribute, copy the attribute
+         and value to the Unsupported Attribute response group.
+
+   orientation-requested (type2 enum)
+
+      IF NOT a single 'enum' value with a length equal to 4 octets,
+      REJECT/RETURN 'client-error-bad-request'.
+      IF NOT in the Printer object's "orientation-requested-supported"
+         attribute, copy the attribute and the unsupported value to the
+         Unsupported Attributes response group.
+
+   media (type3 keyword | name)
+
+      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
+         error-bad-request'.
+      IF the value length is greater than 255 octets, REJECT/RETURN
+         'client-error-request-value-too-long'.
+      IF NOT in the Printer object's "media-supported" attribute, copy
+         the attribute and the unsupported value to the Unsupported
+         Attributes response group.
+
+   printer-resolution (resolution)
+
+      IF NOT a single 'resolution' value with a length equal to 9
+         octets,
+      REJECT/RETURN 'client-error-bad-request'.
+      IF NOT in the Printer object's "printer-resolution-supported"
+         attribute, copy the attribute and the unsupported value to the
+         Unsupported Attributes response group.
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 31]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   print-quality (type2 enum)
+
+      IF NOT a single 'enum' value with a length equal to 4 octets,
+      REJECT/RETURN 'client-error-bad-request'.
+      IF NOT in the Printer object's "print-quality-supported"
+         attribute, copy the attribute and the unsupported value to the
+         Unsupported Attributes response group.
+
+   unknown or unsupported attribute (i.e., there is no corresponding
+   Printer object "xxx-supported" attribute)
+
+      IF the attribute syntax supplied by the client is supported but
+         the length is not legal for that attribute syntax,
+      REJECT/RETURN 'client-error-bad-request' if the length of the
+         attribute syntax is fixed or 'client-error-request-value-too-
+         long' if the length of the attribute syntax is variable.
+      ELSE copy the attribute and value to the Unsupported Attributes
+         response group and change the attribute value to the "out-of-
+         band" 'unsupported' value.  Any remaining Job Template
+         Attributes are either unknown or unsupported Job Template
+         attributes and are validated algorithmically according to their
+         attribute syntax for proper length (see below).
+
+         If the attribute syntax is supported AND the length check
+         fails, the IPP object REJECTS the request and RETURNS the '
+         client-error-bad-request' if the length of the attribute syntax
+         is fixed or the 'client-error-request-value-too-long' status
+         code if the length of the attribute syntax is variable.
+         Otherwise, the IPP object copies the unsupported Job Template
+         attribute to the Unsupported Attributes response group and
+         changes the attribute value to the "out-of-band" 'unsupported'
+         value.  The following table shows the length checks for all
+         attribute syntaxes.  In the following table:  "<=" means less
+         than or equal, "=" means equal to:
+
+   Name              Octet length check for read-write attributes
+   -----------       --------------------------------------------
+   'textWithLanguage    <= 1023 AND 'naturalLanguage'  <= 63
+   'textWithoutLanguage' <= 1023
+   'nameWithLanguage'    <= 255 AND 'naturalLanguage'  <= 63
+   'nameWithoutLanguage' <= 255
+   'keyword'             <= 255
+   'enum'                = 4
+   'uri'                 <= 1023
+   'uriScheme'           <= 63
+   'charset'             <= 63
+   'naturalLanguage'     <= 63
+   'mimeMediaType'       <= 255
+
+
+
+Hastings & Manros            Informational                     [Page 32]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   'octetString'         <= 1023
+   'boolean'             = 1
+   'integer'             = 4
+   'rangeOfInteger'      = 8
+   'dateTime'            = 11
+   'resolution'          = 9
+   '1setOf  X'
+
+2.2.3.1   Check for conflicting Job Template attributes values
+
+   Once all the Operation and Job Template attributes have been checked
+   individually, the Printer object SHOULD check for any conflicting
+   values among all the supported values supplied by the client.  For
+   example, a Printer object might be able to staple and to print on
+   transparencies, however due to physical stapling constraints, the
+   Printer object might not be able to staple transparencies. The IPP
+   object copies the supported attributes and their conflicting
+   attribute values to the Unsupported Attributes response group.  The
+   Printer object only copies over those attributes that the Printer
+   object either ignores or substitutes in order to resolve the
+   conflict, and it returns the original values which were supplied by
+   the client.  For example suppose the client supplies "finishings"
+   equals 'staple' and "media" equals 'transparency', but the Printer
+   object does not support stapling transparencies.  If the Printer
+   chooses to ignore the stapling request in order to resolve the
+   conflict, the Printer objects returns "finishings" equal to 'staple'
+   in the Unsupported Attributes response group.  If any attributes are
+   multi-valued, only the conflicting values of the attributes are
+   copied.
+
+   Note: The decisions made to resolve the conflict (if there is a
+   choice) is implementation dependent.
+
+2.2.3.2   Decide whether to REJECT the request
+
+   If there were any unsupported Job Template attributes or
+   unsupported/conflicting Job Template attribute values and the client
+   supplied the "ipp-attribute-fidelity" attribute with the 'true'
+   value, the Printer object REJECTS the request and return the status
+   code:
+
+      (1) 'client-error-conflicting-attributes' status code, if there
+          were any conflicts between attributes supplied by the client.
+      (2) 'client-error-attributes-or-values-not-supported' status code,
+          otherwise.
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 33]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Note:  Unsupported Operation attributes or values that are returned
+   do not affect the status returned in this step.  If the unsupported
+   Operation attribute was a serious error, the above already rejected
+   the request in a previous step.  If control gets to this step with
+   unsupported Operation attributes being returned, they are not serious
+   errors.
+
+2.2.3.3   For the Validate-Job operation, RETURN one of the success
+          status codes
+
+   If the requested operation is the Validate-Job operation, the Printer
+   object returns:
+
+      (1) the "successful-ok" status code, if there are no unsupported
+          or conflicting Job Template attributes or values.
+      (2) the "successful-ok-conflicting-attributes, if there are any
+          conflicting Job Template attribute or values.
+      (3) the "successful-ok-ignored-or-substituted-attributes, if there
+          are only unsupported Job Template attributes or values.
+
+   Note:  Unsupported Operation attributes or values that are returned
+   do not affect the status returned in this step.  If the unsupported
+   Operation attribute was a serious error, the above already rejected
+   the request in a previous step.  If control gets to this step with
+   unsupported Operation attributes being returned, they are not serious
+   errors.
+
+2.2.3.4   Create the Job object with attributes to support
+
+   If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
+   by the client), the Printer object:
+
+      (1) creates a Job object, assigns a unique value to the job's
+          "job-uri" and "job-id" attributes, and initializes all of the
+          job's other supported Job Description attributes.
+      (2) removes all unsupported attributes from the Job object.
+      (3) for each unsupported value, removes either the unsupported
+          value or substitutes the unsupported attribute value with some
+          supported value.  If an attribute has no values after removing
+          unsupported values from it, the attribute is removed from the
+          Job object (so that the normal default behavior at job
+          processing time will take place for that attribute).
+      (4) for each conflicting value, removes either the conflicting
+          value or substitutes the conflicting attribute value with some
+          other supported value.  If an attribute has no values after
+          removing conflicting values from it, the attribute is removed
+          from the Job object (so that the normal default behavior at
+          job processing time will take place for that attribute).
+
+
+
+Hastings & Manros            Informational                     [Page 34]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   If there were no attributes or values flagged as unsupported, or the
+   value of 'ipp-attribute-fidelity" was 'false', the Printer object is
+   able to accept the create request and create a new Job object.  If
+   the "ipp-attribute-fidelity" attribute is set to 'true', the Job
+   Template attributes that populate the new Job object are necessarily
+   all the Job Template attributes supplied in the create request.  If
+   the "ipp-attribute-fidelity" attribute is set to 'false', the Job
+   Template attributes that populate the new Job object are all the
+   client supplied Job Template attributes that are supported or that
+   have value substitution.  Thus, some of the requested Job Template
+   attributes may not appear in the Job object because the Printer
+   object did not support those attributes.  The attributes that
+   populate the Job object are persistently stored with the Job object
+   for that Job.  A Get-Job-Attributes operation on that Job object will
+   return only those attributes that are persistently stored with the
+   Job object.
+
+   Note: All Job Template attributes that are persistently stored with
+   the Job object are intended to be "override values"; that is, they
+   that take precedence over whatever other embedded instructions might
+   be in the document data itself.  However, it is not possible for all
+   Printer objects to realize the semantics of "override".  End users
+   may query the Printer's "pdl-override-supported" attribute to
+   determine if the Printer either attempts or does not attempt to
+   override document data instructions with IPP attributes.
+
+   There are some cases, where a Printer supports a Job Template
+   attribute and has an associated default value set for that attribute.
+   In the case where a client does not supply the corresponding
+   attribute, the Printer does not use its default values to populate
+   Job attributes when creating the new Job object; only Job Template
+   attributes actually in the create request are used to populate the
+   Job object. The Printer's default values are only used later at Job
+   processing time if no other IPP attribute or instruction embedded in
+   the document data is present.
+
+   Note: If the default values associated with Job Template attributes
+   that the client did not supply were to be used to populate the Job
+   object, then these values would become "override values" rather than
+   defaults.  If the Printer supports the 'attempted' value of the
+   "pdl-override-supported" attribute, then these override values could
+   replace values specified within the document data.  This is not the
+   intent of the default value mechanism. A default value for an
+   attribute is used only if the create request did not specify that
+   attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
+   being 'false') and no value was provided within the content of the
+   document data.
+
+
+
+
+Hastings & Manros            Informational                     [Page 35]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   If the client does not supply a value for some Job Template
+   attribute, and the Printer does not support that attribute, as far as
+   IPP is concerned, the result of processing that Job (with respect to
+   the missing attribute) is undefined.
+
+2.2.3.5   Return one of the success status codes
+
+   Once the Job object has been created, the Printer object accepts the
+   request and returns to the client:
+
+      (1) the 'successful-ok' status code, if there are no unsupported
+          or conflicting Job Template attributes or values.
+      (2) the 'successful-ok-conflicting-attributes' status code, if
+          there are any conflicting Job Template attribute or values.
+      (3) the 'successful-ok-ignored-or-substituted-attributes' status
+          code, if there are only unsupported Job Template attributes or
+          values.
+
+   Note:  Unsupported Operation attributes or values that are returned
+   do not affect the status returned in this step.  If the unsupported
+   Operation attribute was a serious error, the above already rejected
+   the request in a previous step.  If control gets to this step with
+   unsupported Operation attributes being returned, they are not serious
+   errors.
+
+   The Printer object also returns Job status attributes that indicate
+   the initial state of the Job ('pending', 'pending-held', '
+   processing', etc.), etc.  See Print-Job Response, [RFC2566] section
+   3.2.1.2.
+
+2.2.3.6   Accept appended Document Content
+
+   The Printer object accepts the appended Document Content data and
+   either starts it printing, or spools it for later processing.
+
+2.2.3.7   Scheduling and Starting to Process the Job
+
+   The Printer object uses its own configuration and implementation
+   specific algorithms for scheduling the Job in the correct processing
+   order.  Once the Printer object begins processing the Job, the
+   Printer changes the Job's state to 'processing'. If the Printer
+   object supports PDL override (the "pdl-override-supported" attribute
+   set to 'attempted'), the implementation does its best to see that IPP
+   attributes take precedence over embedded instructions in the document
+   data.
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 36]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.2.3.8   Completing the Job
+
+   The Printer object continues to process the Job until it can move the
+   Job into the 'completed' state.  If an Cancel-Job operation is
+   received, the implementation eventually moves the Job into the '
+   canceled' state.  If the system encounters errors during processing
+   that do not allow it to progress the Job into a completed state, the
+   implementation halts all processing, cleans up any resources, and
+   moves the Job into the 'aborted' state.
+
+2.2.3.9   Destroying the Job after completion
+
+   Once the Job moves to the 'completed', 'aborted', or 'canceled'
+   state, it is an implementation decision as to when to destroy the Job
+   object and release all associated resources.  Once the Job has been
+   destroyed, the Printer would return either the "client-error-not-
+   found" or "client-error-gone" status codes for operations directed at
+   that Job.
+
+   Note:  the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
+   value for a sufficiently long time after a job has been destroyed, so
+   that stale references kept by clients are less likely to access the
+   wrong (newer) job.
+
+2.2.3.10  Interaction with "ipp-attribute-fidelity"
+
+   Some Printer object implementations may support "ipp-attribute-
+   fidelity" set to 'true' and "pdl-override-supported" set to '
+   attempted' and yet still not be able to realize exactly what the
+   client specifies in the create request.  This is due to legacy
+   decisions and assumptions that have been made about the role of job
+   instructions embedded within the document data and external job
+   instructions that accompany the document data and how to handle
+   conflicts between such instructions.  The inability to be 100%
+   precise about how a given implementation will behave is also
+   compounded by the fact that the two special attributes, "ipp-
+   attribute-fidelity" and "pdl-override-supported", apply to the whole
+   job rather than specific values for each attribute. For example, some
+   implementations may be able to override almost all Job Template
+   attributes except for "number-up".
+
+2.3 Status codes returned by operation
+
+   This section lists all status codes once in the first operation
+   (Print-Job).  Then it lists the status codes that are different or
+   specialized for subsequent operations under each operation.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 37]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.3.1 Printer Operations
+
+2.3.1.1   Print-Job
+
+   The Printer object MUST return one of the following "status-code"
+   values for the indicated reason.  Whether all of the document data
+   has been accepted or not before returning the success or error
+   response depends on implementation.  See Section 14 for a more
+   complete description of each status code.
+
+   For the following success status codes, the Job object has been
+   created and the "job-id", and "job-uri" assigned and returned in the
+   response:
+
+      successful-ok:  no request attributes were substituted or ignored.
+      successful-ok-ignored-or-substituted-attributes:  some supplied
+         (1) attributes were ignored or (2) unsupported attribute
+         syntaxes or values were substituted with supported values or
+         were ignored.  Unsupported attributes, attribute syntaxes, or
+         values MUST be returned in the Unsupported Attributes group of
+         the response.
+      successful-ok-conflicting-attributes:  some supplied attribute
+         values conflicted with the values of other supplied attributes
+         and were either substituted or ignored.  Attributes or values
+         which conflict with other attributes and have been substituted
+         or ignored MUST be returned in the Unsupported Attributes group
+         of the response as supplied by the client.
+
+   [RFC2566] section 3.1.6 Operation Status Codes and Messages states:
+
+         If the Printer object supports the "status-message" operation
+         attribute, it SHOULD use the REQUIRED 'utf-8' charset to return
+         a status message for the following error status codes (see
+         section 14):  'client-error-bad-request', 'client-error-
+         charset-not-supported', 'server-error-internal-error', '
+         server-error-operation-not-supported', and 'server-error-
+         version-not-supported'.  In this case, it MUST set the value of
+         the "attributes-charset" operation attribute to 'utf-8' in the
+         error response.
+
+   For the following error status codes, no job is created and no "job-
+   id" or "job-uri" is returned:
+
+      client-error-bad-request:  The request syntax does not conform to
+         the specification.
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 38]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      client-error-forbidden:  The request is being refused for
+         authorization or authentication reasons.  The implementation
+         security policy is to not reveal whether the failure is one of
+         authentication or authorization.
+      client-error-not-authenticated:  Either the request requires
+         authentication information to be supplied or the authentication
+         information is not sufficient for authorization.
+      client-error-not-authorized:  The requester is not authorized to
+         perform the request on the target object.
+      client-error-not-possible:  The request cannot be carried out
+         because of the state of the system.  See also 'server-error-
+         not-accepting-jobs' status code which MUST take precedence if
+         the Printer object's "printer-accepting-jobs" attribute is '
+         false'.
+      client-error-timeout:  not applicable.
+      client-error-not-found:  the target object does not exist.
+      client-error-gone:  the target object no longer exists and no
+         forwarding address is known.
+      client-error-request-entity-too-large:  the size of the request
+         and/or print data exceeds the capacity of the IPP Printer to
+         process it.
+      client-error-request-value-too-long:  the size of request variable
+         length attribute values, such as 'text' and 'name' attribute
+         syntaxes, exceed the maximum length specified in [RFC2566] for
+         the attribute and MUST be returned in the Unsupported
+         Attributes Group.
+      client-error-document-format-not-supported:  the document format
+         supplied is not supported.  The "document-format" attribute
+         with the unsupported value MUST be returned in the Unsupported
+         Attributes Group.  This error SHOULD take precedence over any
+         other 'xxx-not-supported' error, except 'client-error-charset-
+         not-supported'.
+      client-error-attributes-or-values-not-supported:  one or more
+         supplied attributes, attribute syntaxes, or values are not
+         supported and the client supplied the "ipp-attributes-fidelity"
+         operation attribute with a 'true' value.  They MUST be returned
+         in the Unsupported Attributes Group as explained below.
+      client-error-uri-scheme-not-supported:  not applicable.
+      client-error-charset-not-supported:  the charset supplied in the
+         "attributes-charset" operation attribute is not supported.  The
+         Printer's "configured-charset" MUST be returned in the response
+         as the value of the "attributes-charset" operation attribute
+         and used for any 'text' and 'name' attributes returned in the
+         error response.  This error SHOULD take precedence over any
+         other error, unless the request syntax is so bad that the
+         client's supplied "attributes-charset" cannot be determined.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 39]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      client-error-conflicting-attributes:  one or more supplied
+         attribute va attribute values conflicted with each other and
+         the client supplied the "ipp-attributes-fidelity" operation
+         attribute with a 'true' value.  They MUST be returned in the
+         Unsupported Attributes Group as explained below.
+      server-error-internal-error:  an unexpected condition prevents the
+         request from being fulfilled.
+      server-error-operation-not-supported:  not applicable (since
+         Print-Job is REQUIRED).
+      server-error-service-unavailable:  the service is temporarily
+         overloaded.
+      server-error-version-not-supported:  the version in the request is
+         not supported.  The "closest" version number supported MUST be
+         returned in the response.
+      server-error-device-error:  a device error occurred while
+         receiving or spooling the request or document data or the IPP
+         Printer object can only accept one job at a time.
+      server-error-temporary-error:  a temporary error such as a buffer
+         full write error, a memory overflow, or a disk full condition
+         occurred while receiving the request and/or the document data.
+      server-error-not-accepting-jobs:  the Printer object's "printer-
+         is-not-accepting-jobs" attribute is 'false'.
+      server-error-busy:  the Printer is too busy processing jobs to
+         accept another job at this time.
+      server-error-job-canceled:  the job has been canceled by an
+         operator or the system while the client was transmitting the
+         document data.
+
+2.3.1.2   Print-URI
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to Print-URI with the following
+   specializations and differences.  See Section 14 for a more complete
+   description of each status code.
+
+      server-error-uri-scheme-not-supported:  the URI scheme supplied in
+         the "document-uri" operation attribute is not supported and is
+         returned in the Unsupported Attributes group.
+
+2.3.1.3   Validate-Job
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to Validate-Job.  See Section 14
+   for a more complete description of each status code.
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 40]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.3.1.4   Create-Job
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to Create-Job with the following
+   specializations and differences.  See Section 14 for a more complete
+   description of each status code.
+
+      server-error-operation-not-supported:  the Create-Job operation is
+         not supported.
+
+2.3.1.5   Get-Printer-Attributes
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to the Get-Printer-Attributes
+   operation with the following specializations and differences.   See
+   Section 14 for a more complete description of each status code.
+
+   For the following success status codes, the requested attributes are
+   returned in Group 3 in the response:
+
+      successful-ok:  no request attributes were substituted or ignored
+         (same as Print-Job) and no requested attributes were
+         unsupported.
+      successful-ok-ignored-or-substituted-attributes:   same as Print-
+         Job, except the "requested-attributes" operation attribute MAY,
+         but NEED NOT, be returned with the unsupported values.
+      successful-ok-conflicting-attributes:  same as Print-Job.
+
+   For the error status codes, Group 3 is returned containing no
+   attributes or is not returned at all:
+
+      client-error-not-possible:  Same as Print-Job, in addition the
+         Printer object is not accepting any requests.
+      client-error-request-entity-too-large:  same as Print-job, except
+         that no print data is involved.
+      client-error-attributes-or-values-not-supported:  not applicable,
+         since unsupported operation attributes MUST be ignored and '
+         successful-ok-ignored-or-substituted-attributes' returned.
+      client-error-conflicting-attributes:  same as Print-Job, except
+         that "ipp-attribute-fidelity" is not involved.
+      server-error-operation-not-supported:  not applicable (since Get-
+         Printer-Attributes is REQUIRED).
+      server-error-device-error:  same as Print-Job, except that no
+         document data is involved.
+      server-error-temporary-error:  same as Print-Job, except that no
+         document data is involved.
+      server-error-not-accepting-jobs:  not applicable.
+
+
+
+
+Hastings & Manros            Informational                     [Page 41]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      server-error-busy:  same as Print-Job, except the IPP object is
+         too busy to accept even query requests.
+      server-error-job-canceled:  not applicable.
+
+2.3.1.6   Get-Jobs
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to the Get-Jobs operation with the
+   following specializations and differences.   See Section 14 for a
+   more complete description of each status code.
+
+   For the following success status codes, the requested attributes are
+   returned in Group 3 in the response:
+
+      successful-ok:  no request attributes were substituted or ignored
+         (same as Print-Job) and no requested attributes were
+         unsupported.
+      successful-ok-ignored-or-substituted-attributes:   same as Print-
+         Job, except the "requested-attributes" operation attribute MAY,
+         but NEED NOT, be returned with the unsupported values.
+      successful-ok-conflicting-attributes:  same as Print-Job.
+
+   For any error status codes, Group 3 is returned containing no
+   attributes or is not returned at all.  The following brief error
+   status code descriptions contain unique information for use with
+   Get-Jobs operation.  See section 14 for the other error status codes
+   that apply uniformly to all operations:
+
+      client-error-not-possible:  Same as Print-Job, in addition the
+         Printer object is not accepting any requests.
+      client-error-request-entity-too-large:  same as Print-job, except
+         that no print data is involved.
+      client-error-document-format-not-supported:  not applicable.
+      client-error-attributes-or-values-not-supported:  not applicable,
+         since unsupported operation attributes MUST be ignored and '
+         successful-ok-ignored-or-substituted-attributes' returned.
+      client-error-conflicting-attributes:  same as Print-Job, except
+         that "ipp-attribute-fidelity" is not involved.
+      server-error-operation-not-supported:  not applicable (since Get-
+         Jobs is REQUIRED).
+      server-error-device-error:  same as Print-Job, except that no
+         document data is involved.
+      server-error-temporary-error:  same as Print-Job, except that no
+         document data is involved.
+      server-error-not-accepting-jobs:  not applicable.
+      server-error-job-canceled:  not applicable.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 42]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.3.2 Job Operations
+
+2.3.2.1   Send-Document
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to the Get-Printer-Attributes
+   operation with the following specializations and differences.   See
+   Section 14 for a more complete description of each status code.
+
+   For the following success status codes, the document has been added
+   to the specified Job object and the job's "number-of-documents"
+   attribute has been incremented:
+
+      successful-ok:  no request attributes were substituted or ignored
+         (same as Print-Job).
+      successful-ok-ignored-or-substituted-attributes:  same as Print-
+         Job.
+      successful-ok-conflicting-attributes:  same as Print-Job.
+
+   For the error status codes, no document has been added to the Job
+   object and the job's "number-of-documents" attribute has not been
+   incremented:
+
+      client-error-not-possible: Same as Print-Job, except that the
+         Printer's "printer-is-accepting-jobs" attribute is not
+         involved, so that the client is able to finish submitting a
+         multi-document job after this attribute has been set to 'true'.
+         Another condition is that the state of the job precludes Send-
+         Document, i.e., the job has already been closed out by the
+         client.  However, if the IPP Printer closed out the job due to
+         timeout, the 'client-error-timeout' error status SHOULD  be
+         returned instead.
+      client-error-timeout:  This request was sent after the Printer
+         closed the job, because it has not received a Send-Document or
+         Send-URI operation within the Printer's "multiple-operation-
+         time-out" period.
+      client-error-request-entity-too-large:  same as Print-Job.
+      client-error-conflicting-attributes:  same as Print-Job, except
+         that "ipp-attributes-fidelity" operation attribute is not
+         involved.
+      server-error-operation-not-supported:  the Send-Document request
+         is not supported.
+      server-error-not-accepting-jobs:  not applicable.
+      server-error-job-canceled:  the job has been canceled by an
+         operator or the system while the client was transmitting the
+         data.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 43]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.3.2.2   Send-URI
+
+   All of the Print-Job status code descriptions in Section 3.2.1.2
+   Print-Job Response with the specializations described for Send-
+   Document are applicable to Send-URI.  See Section 14 for a more
+   complete description of each status code.
+
+      server-error-uri-scheme-not-supported:  the URI scheme supplied in
+         the "document-uri" operation attribute is not supported and the
+         "document-uri" attribute MUST be returned in the Unsupported
+         Attributes group.
+
+2.3.2.3   Cancel-Job
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to Cancel-Job with the following
+   specializations and differences.  See Section 14 for a more complete
+   description of each status code.
+
+   For the following success status codes, the Job object is being
+   canceled or has been canceled:
+
+      successful-ok:  no request attributes were substituted or ignored
+         (same as Print-Job).
+      successful-ok-ignored-or-substituted-attributes:   same as Print-
+         Job.
+      successful-ok-conflicting-attributes:  same as Print-Job.
+
+   For any of the error status codes, the Job object has not been
+   canceled or was previously canceled.
+
+      client-error-not-possible:  The request cannot be carried out
+         because of the state of the Job object ('completed', '
+         canceled', or 'aborted') or the state of the system.
+      client-error-not-found:  the target Printer and/or Job object does
+         not exist.
+      client-error-gone:  the target Printer and/or Job object no longer
+         exists and no forwarding address is known.
+      client-error-request-entity-too-large:  same as Print-Job, except
+         no document data is involved.
+      client-error-document-format-not-supported:  not applicable.
+      client-error-attributes-or-values-not-supported:  not applicable,
+         since unsupported operation attributes and values MUST be
+         ignored.
+      client-error-conflicting-attributes:  same as Print-Job, except
+         that the Printer's "printer-is-accepting-jobs" attribute is not
+         involved.
+
+
+
+
+Hastings & Manros            Informational                     [Page 44]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      server-error-operation-not-supported:  not applicable (Cancel-Job
+         is REQUIRED).
+      server-error-device-error:  same as Print-Job, except no document
+         data is involved.
+      server-error-temporary-error:  same as Print-Job, except no
+         document data is involved.
+      server-error-not-accepting-jobs:  not applicable.
+      server-error-job-canceled:  not applicable.
+
+2.3.2.4   Get-Job-Attributes
+
+   All of the Print-Job status codes described in Section 3.2.1.2
+   Print-Job Response are applicable to Get-Job-Attributes with the
+   following specializations and differences.  See Section 14 for a more
+   complete description of each status code.
+
+   For the following success status codes, the requested attributes are
+   returned in Group 3 in the response:
+
+      successful-ok:  no request attributes were substituted or ignored
+         (same as Print-Job) and no requested attributes were
+         unsupported.
+      successful-ok-ignored-or-substituted-attributes:   same as Print-
+         Job, except the "requested-attributes" operation attribute MAY,
+         but NEED NOT, be returned with the unsupported values.
+      successful-ok-conflicting-attributes:  same as Print-Job.
+
+   For the error status codes, Group 3 is returned containing no
+   attributes or is not returned at all.
+
+      client-error-not-possible:  Same as Print-Job, in addition the
+         Printer object is not accepting any requests.
+      client-error-document-format-not-supported:  not applicable.
+      client-error-attributes-or-values-not-supported:  not applicable.
+      client-error-uri-scheme-not-supported:  not applicable.
+      client-error-conflicting-attributes:  not applicable
+      server-error-operation-not-supported:  not applicable (since Get-
+         Job-Attributes is REQUIRED).
+      server-error-device-error:  same as Print-Job, except no document
+         data is involved.
+      server-error-temporary-error:  sane as Print-Job, except no
+         document data is involved.
+      server-error-not-accepting-jobs:  not applicable.  server-error-
+      job-canceled:  not applicable.
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 45]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.4 Validate-Job
+
+   The Validate-Job operation has been designed so that its
+   implementation may be a part of the Print-Job operation.  Therefore,
+   requiring Validate-Job is not a burden on implementers.  Also it is
+   useful for client's to be able to count on its presence in all
+   conformance implementations, so that the client can determine before
+   sending a long document, whether the job will be accepted by the IPP
+   Printer or not.
+
+2.5 Case Sensitivity in URIs
+
+   IPP client and server implementations must be aware of the diverse
+   uppercase/lowercase nature of URIs.  RFC 2396 defines URL schemes and
+   Host names as case insensitive but reminds us that the rest of the
+   URL may well demonstrate case sensitivity.  When creating URL's for
+   fields where the choice is completely arbitrary, it is probably best
+   to select lower case.  However, this cannot be guaranteed and
+   implementations MUST NOT rely on any fields being case-sensitive or
+   case-insensitive in the URL beyond the URL scheme and host name
+   fields.
+
+   The reason that the IPP specification does not make any restrictions
+   on URIs, is so that implementations of IPP may use off-the-shelf
+   components that conform to the standards that define URIs, such as
+   RFC 2396 and the HTTP/1.1 specifications [RFC2068].  See these
+   specifications for rules of matching, comparison, and case-
+   sensitivity.
+
+   It is also recommended that System Administrators and implementations
+   avoid creating URLs for different printers that differ only in their
+   case.  For example, don't have Printer1 and printer1 as two different
+   IPP Printers.
+
+   The HTTP/1.1 specification [RFC2068] contains more details on
+   comparing URLs.
+
+2.6 Character Sets, natural languages, and internationalization
+
+   This section discusses character set support, natural language
+   support and internationalization.
+
+2.6.1 Character set code conversion support
+
+   IPP clients and IPP objects are REQUIRED to support UTF-8.  They MAY
+   support additional charsets.  It is RECOMMENDED that an IPP object
+   also support US-ASCII, since many clients support US-ASCII, and
+   indicate that UTF-8 and US-ASCII are supported by populating the
+
+
+
+Hastings & Manros            Informational                     [Page 46]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Printer's "charset-supported" with 'utf-8' and 'us-ascii' values.  An
+   IPP object is required to code covert with as little loss as possible
+   between the charsets that it supports, as indicated in the Printer's
+   "charsets-supported" attribute.
+
+   How should the server handle the situation where the "attributes-
+   charset" of the response itself is "us-ascii", but one or more
+   attributes in that response is in the "utf-8" format?
+
+   Example:  Consider a case where a client sends a Print-Job request
+   with "utf-8" as the value of "attributes-charset" and with the "job-
+   name" attribute supplied.  Later another client submits a Get-Job-
+   Attribute or Get-Jobs request.  This second request contains the
+   "attributes-charset" with value "us-ascii" and "requested-attributes"
+   attribute with exactly one value "job-name".
+
+   According to the RFC2566 document (section 3.1.4.2), the value of the
+   "attributes-charset" for the response of the second request must be
+   "us-ascii" since that is the charset specified in the request.  The
+   "job-name" value, however, is in "utf-8" format.  Should the request
+   be rejected even though both "utf-8" and "us-ascii" charsets are
+   supported by the server? or should the "job-name" value be converted
+   to "us-ascii" and return "successful-ok-conflicting-attributes"
+   (0x0002) as the status code?
+
+   Answer:  An IPP object that supports both utf-8 (REQUIRED) and us-
+   ascii, the second paragraph of section 3.1.4.2 applies so that the
+   IPP object MUST accept the request, perform code set conversion
+   between these two charsets with "the highest fidelity possible" and
+   return 'successful-ok', rather than a warning 'successful-ok-
+   conflicting-attributes, or an error.  The printer will do the best it
+   can to convert between each of the character sets that it supports--
+   even if that means providing a string of question marks because none
+   of the characters are representable in US ASCII.  If it can't perform
+   such conversion, it MUST NOT advertise us-ascii as a value of its
+   "attributes-charset-supported" and MUST reject any request that
+   requests 'us-ascii'.
+
+   One IPP object implementation strategy is to convert all request text
+   and name values to a Unicode internal representation.  This is 16-bit
+   and virtually universal.  Then convert to the specified operation
+   attributes-charset on output.
+
+   Also it would be smarter for a client to ask for 'utf-8', rather than
+   'us-ascii' and throw away characters that it doesn't understand,
+   rather than depending on the code conversion of the IPP object.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 47]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.6.2 What charset to return when an unsupported charset is requested?
+
+   Section 3.1.4.1 Request Operation attributes was clarified in
+   November 1998 as follows:
+
+      All clients and IPP objects MUST support the 'utf-8' charset
+      [RFC2044] and MAY support additional charsets provided that they
+      are registered with IANA [IANA-CS].  If the Printer object does
+      not support the client supplied charset value, the Printer object
+      MUST reject the request, set the "attributes-charset" to 'utf-8'
+      in the response, and return the 'client-error-charset-not-
+      supported' status code and any 'text' or 'name' attributes using
+      the 'utf-8' charset.
+
+   Since the client and IPP object MUST support UTF-8, returning any
+   text or name attributes in UTF-8 when the client requests a charset
+   that is not supported should allow the client to display the text or
+   name.
+
+   Since such an error is a client error, rather than a user error, the
+   client should check the status code first so that it can avoid
+   displaying any other returned 'text' and 'name' attributes that are
+   not in the charset requested.
+
+   Furthermore, [RFC2566] section 14.1.4.14 client-error-charset-not-
+   supported (0x040D) was clarified in November 1998 as follows:
+
+      For any operation, if the IPP Printer does not support the charset
+      supplied by the client in the "attributes-charset" operation
+      attribute, the Printer MUST reject the operation and return this
+      status and any 'text' or 'name' attributes using the 'utf-8'
+      charset (see Section 3.1.4.1).
+
+2.6.3 Natural Language Override (NLO)
+
+   The 'text' and 'name' attributes each have two forms.  One has an
+   implicit natural language, and the other has an explicit natural
+   language.  The 'textWithoutLanguage' and 'textWithoutLanguage' are
+   the two 'text' forms.  The 'nameWithoutLanguage" and '
+   nameWithLanguage are the two 'name' forms.  If a receiver (IPP object
+   or IPP client) supports an attribute with attribute syntax 'text', it
+   MUST support both forms in a request and a response.  A sender (IPP
+   client or IPP object) MAY send either form for any such attribute.
+   When a sender sends a WithoutLanguage form, the implicit natural
+   language is specified in the "attributes-natural-language" operation
+   attribute which all senders MUST include in every request and
+   response.
+
+
+
+
+Hastings & Manros            Informational                     [Page 48]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   When a sender sends a WithLanguage form, it MAY be different from the
+   implicit natural language supplied by the sender or it MAY be the
+   same.  The receiver MUST treat either form equivalently.
+
+   There is an implementation decision for senders, whether to always
+   send the WithLanguage forms or use the WithoutLanguage form when the
+   attribute's natural language is the same as the request or response.
+   The former approach makes the sender implementation simpler.  The
+   latter approach is more efficient on the wire and allows inter-
+   working with non-conforming receivers that fail to support the
+   WithLanguage forms.  As each approach have advantages, the choice is
+   completely up to the implementer of the sender.
+
+   Furthermore, when a client receives a 'text' or 'name' job attribute
+   that it had previously supplied, that client MUST NOT expect to see
+   the attribute in the same form, i.e., in the same WithoutLanguage or
+   WithLanguage form as the client supplied when it created the job.
+   The IPP object is free to transform the attribute from the
+   WithLanguage form to the WithoutLanguage form and vice versa, as long
+   as the natural language is preserved.  However, in order to meet this
+   latter requirement, it is usually simpler for the IPP object
+   implementation to store the natural language explicitly with the
+   attribute value, i.e., to store using an internal representation that
+   resembles the WithLanguage form.
+
+   The IPP Printer MUST copy the natural language of a job, i.e., the
+   value of the "attributes-natural-language" operation attribute
+   supplied by the client in the create operation, to the Job object as
+   a Job Description attribute, so that a client is able to query it.
+   In returning a Get-Job-Attributes response, the IPP object MAY return
+   one of three natural language values in the response's "attributes-
+   natural-language" operation attribute: (1) that requested by the
+   requester, (2) the natural language of the job, or (3) the configured
+   natural language of the IPP Printer, if the requested language is not
+   supported by the IPP Printer.
+
+   This "attributes-natural-language" Job Description attribute is
+   useful for an IPP object implementation that prints start sheets in
+   the language of the user who submitted the job.  This same Job
+   Description attribute is useful to a multi-lingual operator who has
+   to communicate with different job submitters in different natural
+   languages.  This same Job Description attribute is expected to be
+   used in the future to generate notification messages in the natural
+   language of the job submitter.
+
+   Early drafts of [RFC2566] contained a job-level natural language
+   override (NLO) for the Get-Jobs response.  A job-level (NLO) is an
+   (unrequested) Job Attribute which then specified the implicit natural
+
+
+
+Hastings & Manros            Informational                     [Page 49]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   language for any other WithoutLanguage job attributes returned in the
+   response for that job.  Interoperability testing of early
+   implementations showed that no one was implementing the job-level NLO
+   in Get-Job responses.  So the job-level NLO was eliminated from the
+   Get- Jobs response.  This simplification makes all requests and
+   responses consistent in that the implicit natural language for any
+   WithoutLanguage 'text' or 'name' form is always supplied in the
+   request's or response's "attributes-natural-language" operation
+   attribute.
+
+2.7 The "queued-job-count" Printer Description attribute
+
+2.7.1 Why is "queued-job-count" RECOMMENDED?
+
+   The reason that "queued-job-count" is RECOMMENDED, is that some
+   clients look at that attribute alone when summarizing the status of a
+   list of printers, instead of doing a Get-Jobs to determine the number
+   of jobs in the queue.  Implementations that fail to support the
+   "queued-job-count" will cause that client to display 0 jobs when
+   there are actually queued jobs.
+
+   We would have made it a REQUIRED Printer attribute, but some
+   implementations had already been completed before the issue was
+   raised, so making it a SHOULD was a compromise.
+
+2.7.2 Is "queued-job-count" a good measure of how busy a printer is?
+
+   The "queued-job-count" is not a good measure of how busy the printer
+   is when there are held jobs.  A future registration could be to add a
+   "held-job-count" (or an "active-job-count") Printer Description
+   attribute if experience shows that such an attribute (combination) is
+   needed to quickly indicate how busy a printer really is.
+
+2.8 Sending empty attribute groups
+
+   The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender
+   not send an empty attribute group in a request or a response.
+   However, they REQUIRE a receiver to accept an empty attribute group
+   as equivalent to the omission of that group.  So a client SHOULD omit
+   the Job Template Attributes group entirely in a create operation that
+   is not supplying any Job Template attributes.  Similarly, an IPP
+   object SHOULD omit an empty Unsupported Attributes group if there are
+   no unsupported attributes to be returned in a response.
+
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 50]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   The [RFC2565] specification REQUIRES a receiver to be able to receive
+   either an empty attribute group or an omitted attribute group and
+   treat them equivalently.  The term "receiver" means an IPP object for
+   a request and a client for a response.  The term "sender' means a
+   client for a request and an IPP object for a response.
+
+   There is an exception to the rule for Get-Jobs when there are no
+   attributes to be returned.  [RFC2565] contains the following
+   paragraph:
+
+      The syntax allows an xxx-attributes-tag to be present when the
+      xxx-attribute-sequence that follows is empty. The syntax is
+      defined this way to allow for the response of Get-Jobs where no
+      attributes are returned for some job-objects.  Although it is
+      RECOMMENDED that the sender not send an xxx-attributes-tag if
+      there are no attributes (except in the Get-Jobs response just
+      mentioned), the receiver MUST be able to decode such syntax.
+
+2.9 Returning unsupported attributes in Get-Xxxx responses
+
+   In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
+   responses, the client cannot depend on getting unsupported attributes
+   returned in the Unsupported Attributes group that the client
+   requested, but are not supported by the IPP object.  However, such
+   unsupported requested attributes will not be returned in the Job
+   Attributes or Printer Attributes group (since they are unsupported).
+   Furthermore, the IPP object is REQUIRED to return the 'successful-
+   ok-ignored-or-substituted-attributes' status code, so that the client
+   knows that not all that was requested has been returned.
+
+2.10 Returning job-state in Print-Job response
+
+   An IPP client submits a small job via Print-Job.  By the time the IPP
+   printer/print server is putting together a response to the operation,
+   the job has finished printing and been removed as an object from the
+   print system.  What should the job-state be in the response?
+
+   The Model suggests that the Printer return a response before it even
+   accepts the document content.  The Job Object Attributes are returned
+   only if the IPP object returns one of the success status codes. Then
+   the job-state would always be "pending" or "pending-held".
+
+   This issue comes up for the implementation of an IPP Printer object
+   as a server that forwards jobs to devices that do not provide job
+   status back to the server.  If the server is reasonably certain that
+   the job completed successfully, then it should return the job-state
+   as 'completed'.  Also the server can keep the job in its "job
+   history" long after the job is no longer in the device.  Then a user
+
+
+
+Hastings & Manros            Informational                     [Page 51]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   could query the server and see that the job was in the 'completed'
+   state and completed as specified by the job's "time-at-completed"
+   time which would be the same as the server submitted the job to the
+   device.
+
+   An alternative is for the server to respond to the client before or
+   while sending the job to the device, instead of waiting until the
+   server has finished sending the job to the device.  In this case, the
+   server can return the job's state as 'pending' with the 'job-
+   outgoing' value in the job's "job-state-reasons" attribute.
+
+   If the server doesn't know for sure whether the job completed
+   successfully (or at all), it could return the (out-of-band) 'unknown'
+   value.
+
+   On the other hand, if the server is able to query the device and/or
+   setup some sort of event notification that the device initiates when
+   the job makes state transitions, then the server can return the
+   current job state in the Print-Job response and in subsequent queries
+   because the server knows what the job state is in the device (or can
+   query the device).
+
+   All of these alternatives depend on implementation of the server and
+   the device.
+
+2.11 Flow controlling the data portion of a Print-Job request
+
+   A paused printer (or one that is stopped due to paper out or jam or
+   spool space full or buffer space full, may flow control the data of a
+   Print-Job operation (at the TCP/IP layer), so that the client is not
+   able to send all the document data.  Consequently, the Printer will
+   not return a response until the condition is changed.
+
+   The Printer should not return a Print-Job response with an error code
+   in any of these conditions, since either the printer will be resumed
+   and/or the condition will be freed either by human intervention or as
+   jobs print.
+
+   In writing test scripts to test IPP Printers, the script must also be
+   written not to expect a response, if the printer has been paused,
+   until the printer is resumed, in order to work with all possible
+   implementations.
+
+2.12 Multi-valued attributes
+
+   What is the attribute syntax for a multi-valued attribute?  Since
+   some attributes support values in more than one data type, such as
+   "media", "job-hold-until", and "job-sheets", IPP semantics associate
+
+
+
+Hastings & Manros            Informational                     [Page 52]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   the attribute syntax with each value, not with the attribute as a
+   whole.  The protocol associates the attribute syntax tag with each
+   value.  Don't be fooled, just because the attribute syntax tag comes
+   before the attribute keyword.  All attribute values after the first
+   have a zero length attribute keyword as the indication of a
+   subsequent value of the same attribute.
+
+2.13 Querying jobs with IPP that were submitted using other job
+     submission protocols
+
+   The following clarification was added to [RFC2566] section 8.5:
+
+      8.5 Queries on jobs submitted using non-IPP protocols
+
+      If the device that an IPP Printer is representing is able to
+      accept jobs using other job submission protocols in addition to
+      IPP, it is RECOMMEND that such an implementation at least allow
+      such "foreign" jobs to be queried using Get-Jobs returning "job-
+      id" and "job-uri" as 'unknown'.  Such an implementation NEED NOT
+      support all of the same IPP job attributes as for IPP jobs.  The
+      IPP object returns the 'unknown' out-of-band value for any
+      requested attribute of a foreign job that is supported for IPP
+      jobs, but not for foreign jobs.
+
+      It is further RECOMMENDED, that the IPP Printer generate "job-id"
+      and "job-uri" values for such "foreign jobs", if possible, so that
+      they may be targets of other IPP operations, such as Get-Job-
+      Attributes and Cancel-Job.  Such an implementation also needs to
+      deal with the problem of authentication of such foreign jobs.  One
+      approach would be to treat all such foreign jobs as belonging to
+      users other than the user of the IPP client.  Another approach
+      would be for the foreign job to belong to 'anonymous'.  Only if
+      the IPP client has been authenticated as an operator or
+      administrator of the IPP Printer object, could the foreign jobs be
+      queried by an IPP request.  Alternatively, if the security policy
+      is to allow users to query other users' jobs, then the foreign
+      jobs would also be visible to an end-user IPP client using Get-
+      Jobs and Get-Job-Attributes.
+
+   Thus IPP MAY be implemented as a "universal" protocol that provides
+   access to jobs submitted with any job submission protocol.  As IPP
+   becomes widely implemented, providing a more universal access makes
+   sense.
+
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 53]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+2.14 The 'none' value for empty sets
+
+   [RFC2566] states that the 'none' value should be used as the value of
+   a 1SetOf when the set is empty. In most cases, sets that are
+   potentially empty contain keywords so the keyword 'none' is used, but
+   for the 3 finishings attributes, the values are enums and thus the
+   empty set is represented by the enum 3.  Currently there are no other
+   attributes with 1SetOf values which can be empty and can contain
+   values that are not keywords.  This exception requires special code
+   and is a potential place for bugs.  It would have been better if we
+   had chosen an out-of-band value, either "no-value" or some new value,
+   such as 'none'.  Since we didn't, implementations have to deal with
+   the different representations of 'none', depending on the attribute
+   syntax.
+
+2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?
+
+   In [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute '
+   my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
+   attribute be there to, and if it's not present what should the IPP
+   printer do?
+
+   [RFC2566] Section 8.3 describes the various cases of "requesting-
+   user-name" being present or not for any operation.  If the client
+   does not supply a value for "requesting-user-name", the printer MUST
+   assume that the client is supplying some anonymous name, such as
+   "anonymous".
+
+2.16 The "multiple-document-handling" Job Template attribute and support
+     of multiple document jobs
+
+   ISSUE:  IPP/1.0 is silent on which of the four effects an
+   implementation would perform if it supports Create-Job, but does not
+   support "multiple-document-handling".
+
+   A fix to IPP/1.0 would be to require implementing all four values of
+   "multiple-document-handling" if Create-Job is supported at all.  Or
+   at least 'single-document-new-sheet' and 'separate-documents-
+   uncollated-copies'.  In any case, an implementation that supports
+   Create-Job SHOULD also support "multiple-document-handling".  Support
+   for all four values is RECOMMENDED, but at least the 'single-
+   document-new-sheet' and 'separate-documents-uncollated-copies'
+   values, along with the "multiple-document-handling-default"
+   indicating the default behavior and "multiple-document-handling-
+   supported" values.  If an implementation spools the data, it should
+   also support the 'separate-documents-collated-copies' value as well.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 54]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+3  Encoding and Transport
+
+   This section discusses various aspects of IPP/1.0 Encoding and
+   Transport [RFC2565].
+
+   A server is not required to send a response until after it has
+   received the client.s entire request.  Hence, a client must not
+   expect a response until after it has sent the entire request.
+   However, we recommend that the server return a response as soon as
+   possible if an error is detected while the client is still sending
+   the data, rather than waiting until all of the data is received.
+   Therefore, we also recommend that a client listen for an error
+   response that an IPP server MAY send before it receives all the data.
+   In this case a client, if chunking the data, can send a premature
+   zero-length chunk to end the request before sending all the data (and
+   so the client can keep the connection open for other requests, rather
+   than closing it). If the request is blocked for some reason, a client
+   MAY determine the reason by opening another connection to query the
+   server using Get-Printer-Attributes.
+
+   In the following sections, there are a tables of all HTTP headers
+   which describe their use in an IPP client or server.  The following
+   is an explanation of each column in these tables.
+
+      - the .header. column contains the name of a header.
+      - the .request/client. column indicates whether a client sends the
+        header.
+      - the .request/ server. column indicates whether a server supports
+        the header when received.
+      - the .response/ server. column indicates whether a server sends
+        the header.
+      - the .response /client. column indicates whether a client
+        supports the header when received.
+      - the .values and conditions. column specifies the allowed header
+        values and the conditions for the header to be present in a
+        request/response.
+
+   The table for .request headers. does not have columns for responses,
+   and the table for .response headers. does not have columns for
+   requests.
+
+   The following is an explanation of the values in the .request/client.
+   and .response/ server. columns.
+
+      - must: the client or server MUST send the header,
+      - must-if: the client or server MUST send the header when the
+        condition described in the .values and conditions. column is
+        met,
+
+
+
+Hastings & Manros            Informational                     [Page 55]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+      - may: the client or server MAY send the header
+      - not: the client or server SHOULD NOT send the header. It is not
+        relevant to an IPP implementation.
+
+   The following is an explanation of the values in the
+   .response/client.  and .request/ server. columns.
+
+      - must: the client or server MUST support the header,
+      - may: the client or server MAY support the header
+      - not: the client or server SHOULD NOT support the header. It is
+        not relevant to an IPP implementation.
+
+3.1 General Headers
+
+
+   The following is a table for the general headers.
+
+
+   General-     Request         Response       Values and Conditions
+   Header
+
+                Client  Server Server Client
+
+   Cache-       must    not    must   not     .no-cache. only
+   Control
+
+   Connection   must-if must   must-  must    .close. only. Both
+                                if             client and server
+                                                SHOULD keep a
+                                                connection for the
+                                                duration of a sequence
+                                                of operations. The
+                                                client and server MUST
+                                                include this header
+                                                for the last operation
+                                                in such a sequence.
+
+   Date         may     may    must   may     per RFC 1123 [RFC1123]
+                                                from RFC 2068
+                                                [RFC2068]
+
+   Pragma       must    not    must   not     .no-cache. only
+
+   Transfer-    must-if must   must-  must    .chunked. only .
+   Encoding                     if             Header MUST be present
+                                                if Content-Length is
+                                                absent.
+
+
+
+
+Hastings & Manros            Informational                     [Page 56]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Upgrade      not     not    not    not
+
+   Via          not     not    not    not
+
+3.2 Request  Headers
+
+
+   The following is a table for the request headers.
+
+
+   Request-Header   Client   Server  Request Values and Conditions
+
+   Accept           may      must    .application/ipp. only.  This
+                                      value is the default if the
+
+   Request-Header   Client   Server  Request Values and Conditions
+
+                                      client omits it
+
+   Accept-Charset   not      not      Charset information is within
+                                      the application/ipp entity
+
+   Accept-Encoding  may      must    empty and per RFC 2068 [RFC2068]
+                                      and IANA registry for content-
+                                      codings
+
+   Accept-Language  not      not     language information is within
+                                      the application/ipp entity
+
+   Authorization    must-if  must    per RFC 2068. A client MUST send
+                                      this header when it receives a
+                                      401 .Unauthorized. response and
+                                      does not receive a  .Proxy-
+                                      Authenticate. header.
+
+   From             not      not     per RFC 2068. Because RFC
+                                      recommends sending this header
+                                      only with the user.s approval, it
+                                      is not very useful
+
+   Host             must     must    per RFC 2068
+
+   If-Match         not      not
+
+   If-Modified-     not      not
+   Since
+
+   If-None-Match    not      not
+
+
+
+Hastings & Manros            Informational                     [Page 57]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   If-Range         not      not
+
+   If-Unmodified-   not      not
+   Since
+
+   Max-Forwards     not      not
+
+   Proxy-           must-if  not     per RFC 2068. A client MUST send
+   Authorization                      this header when it receives a
+                                      401 .Unauthorized. response and a
+                                      .Proxy-Authenticate. header.
+
+   Range            not      not
+
+   Referer          not      not
+
+   User-Agent       not      not
+
+
+3.3 Response Headers
+
+
+   The following is a table for the request headers.
+
+
+   Response-      Server  Client  Response Values and Conditions
+   Header
+
+   Accept-Ranges  not     not
+
+   Age            not     not
+
+   Location       must-if may     per RFC 2068. When URI needs
+                                   redirection.
+
+   Proxy-         not     must    per RFC 2068
+   Authenticate
+
+   Public         may     may     per RFC 2068
+
+   Retry-After    may     may     per RFC 2068
+
+   Server         not     not
+
+   Vary           not     not
+
+   Warning        may     may     per RFC 2068
+
+
+
+
+Hastings & Manros            Informational                     [Page 58]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   WWW-           must-if must    per RFC 2068. When a server needs to
+   Authenticate                    authenticate a client.
+
+3.4 Entity  Headers
+
+
+   The following is a table for the entity headers.
+
+
+   Entity-Header  Request         Response        Values and Conditions
+
+                  Client  Server Server  Client
+
+   Allow          not     not    not     not
+
+   Content-Base   not     not    not     not
+
+   Content-       may     must   must    must   per RFC 2068 and IANA
+   Encoding                                       registry for content
+                                                  codings.
+
+   Content-       not     not    not     not    Application/ipp
+   Language                                       handles language
+
+   Content-       must-if must   must-if must   the length of the
+   Length                                         message-body per RFC
+                                                  2068. Header MUST be
+                                                  present if Transfer-
+
+   Entity-Header  Request         Response        Values and Conditions
+
+                  Client  Server Server  Client
+
+                                                  Encoding is absent.
+
+   Content-       not     not    not     not
+   Location
+
+   Content-MD5    may     may    may     may    per RFC 2068
+
+   Content-Range  not     not    not     not
+
+   Content-Type   must    must   must    must   .application/ipp.
+                                                  only
+
+   ETag           not     not    not     not
+
+   Expires        not     not    not     not
+
+
+
+Hastings & Manros            Informational                     [Page 59]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Last-Modified  not     not    not     not
+
+
+3.5 Optional support for HTTP/1.0
+
+   IPP implementations consist of an HTTP layer and an IPP layer.  In
+   the following discussion, the term "client" refers to the HTTP client
+   layer and the term "server" refers to the HTTP server layer.  The
+   Encoding and Transport document [RFC2565] requires that HTTP 1.1 MUST
+   be supported by all clients and all servers.  However, a client
+   and/or a server implementation may choose to also support HTTP 1.0.
+
+   - This option means that a server may choose to communicate with a
+     (non-conforming) client that only supports HTTP 1.0.  In such cases
+     the server should not use any HTTP 1.1 specific parameters or
+     features and should respond using HTTP version number 1.0.
+
+   - This option also means that a client may choose to communicate with
+     a (non-conforming) server that only supports HTTP 1.0.  In such
+     cases, if the server responds with an HTTP .unsupported version
+     number. to an HTTP 1.1 request, the client should retry using HTTP
+     version number 1.0.
+
+3.6 HTTP/1.1 Chunking
+
+3.6.1 Disabling IPP Server Response Chunking
+
+   Clients MUST anticipate that the HTTP/1.1 server may chunk responses
+   and MUST accept them in responses.  However, a (non-conforming) HTTP
+   client that is unable to accept chunked responses may attempt to
+   request an HTTP 1.1 server not to use chunking in its response to an
+   operation by using the following HTTP header:
+
+        TE: identity
+
+   This mechanism should not be used by a server to disable a client
+   from chunking a request, since chunking of document data is an
+   important feature for clients to send long documents.
+
+3.6.2 Warning About the Support of Chunked Requests
+
+   This section describes some problems with the use of chunked requests
+   and HTTP/1.1 servers.
+
+   The HTTP/1.1 standard [HTTP] requires that conforming servers support
+   chunked requests for any method.  However, in spite of this
+   requirement, some HTTP/1.1 implementations support chunked responses
+   in the GET method, but do not support chunked POST method requests.
+
+
+
+Hastings & Manros            Informational                     [Page 60]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
+   servlets [Servlet] require that the client supply a Content-Length.
+   These implementations might reject a chunked POST method and return a
+   411 status code (Length Required), might attempt to buffer the
+   request and run out of room returning a 413 status code (Request
+   Entity Too Large), or might successfully accept the chunked request.
+
+   Because of this lack of conformance of HTTP servers to the HTTP/1.1
+   standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP
+   Printer object implementation support chunked requests and that
+   conforming clients accept chunked responses.  Therefore, IPP object
+   implementers are warned to seek HTTP server implementations that
+   support chunked POST requests in order to conform to the IPP standard
+   and/or use implementation techniques that support chunked POST
+   requests.
+
+4  References
+
+   [CGI]     Coar, K. and D. Robinson, "The WWW Common Gateway Interface
+             Version 1.1 (CGI/1.1)", Work in Progress.
+
+   [HTTP]    Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter,
+             L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
+             Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+             "Mapping between LPD and IPP Protocols", RFC 2569, April
+             1999.
+
+   [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
+             Powell, "Internet Printing Protocol/1.0: Model and
+             Semantics", RFC 2566, April 1999.
+
+   [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
+             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+             April 1999.
+
+   [RFC2568] Zilles, S., "Rationale for the Structure and Model and
+             Protocol for the Internet Printing Protocol", RFC 2568,
+             April 1999.
+
+   [RFC2567] Wright, D., "Design Goals for an Internet Printing
+             Protocol", RFC 2567, April 1999.
+
+   [RFC1123] Braden, S., "Requirements for Internet Hosts - Application
+             and Support", STD 3, RFC 1123, October 1989.
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 61]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+             3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+             2068, January 1997.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+             Resource Identifiers (URI): Generic Syntax", RFC 2396,
+             August 1998.
+
+   [Servlet] Servlet Specification Version 2.1
+             (http://java.sun.com/products/servlet/2.1/index.html).
+
+   [SSL]     Netscape, The SSL Protocol, Version 3, (Text version 3.02),
+             November 1996.
+
+4.1 Authors' Addresses
+
+   Thomas N. Hastings
+   Xerox Corporation
+   701 Aviation Blvd.
+   El Segundo, CA 90245
+
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Carl-Uno Manros
+   Xerox Corporation
+   701 Aviation Blvd.
+   El Segundo, CA 90245
+
+   EMail: manros@cp10.es.xerox.com
+
+5  Security Considerations
+
+   Security issues are discussed in sections 2.2, 2.3.1, and 8.5.
+
+6  Notices
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+
+
+
+Hastings & Manros            Informational                     [Page 62]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11 [BCP-11].
+   Copies of claims of rights made available for publication and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 63]
+
+RFC 2639              IPP/1.0: Implementer's Guide             July 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings & Manros            Informational                     [Page 64]
+
diff --git a/standards/rfc2712.txt b/standards/rfc2712.txt
new file mode 100644
index 000000000..4888e2e2d
--- /dev/null
+++ b/standards/rfc2712.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                      A. Medvinsky
+Request for Comments: 2712                                       Excite
+Category: Standards Track                                        M. Hur
+                                                  CyberSafe Corporation
+                                                           October 1999
+
+
+  Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+IESG Note:
+
+   The 40-bit ciphersuites defined in this memo are included only for
+   the purpose of documenting the fact that those ciphersuite codes have
+   already been assigned.  40-bit ciphersuites were designed to comply
+   with US-centric, and now obsolete, export restrictions.  They were
+   never secure, and nowadays are inadequate even for casual
+   applications.  Implementation and use of the 40-bit ciphersuites
+   defined in this document, and elsewhere, is strongly discouraged.
+
+1. Abstract
+
+   This document proposes the addition of new cipher suites to the TLS
+   protocol [1] to support Kerberos-based authentication.  Kerberos
+   credentials are used to achieve mutual authentication and to
+   establish a master secret which is subsequently used to secure
+   client-server communication.
+
+2. Introduction
+
+   Flexibility is one of the main strengths of the TLS protocol.
+   Clients and servers can negotiate cipher suites to meet specific
+   security and administrative policies.  However, to date,
+   authentication in TLS is limited only to public key solutions.  As a
+   result, TLS does not fully support organizations with heterogeneous
+   security deployments that include authentication systems based on
+   symmetric cryptography.  Kerberos, originally developed at MIT, is
+
+
+
+Medvinsky & Hur             Standards Track                     [Page 1]
+
+RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
+
+
+   based on an open standard [2] and is the most widely deployed
+   symmetric key authentication system.  This document proposes a new
+   option for negotiating Kerberos authentication within the TLS
+   framework.  This achieves mutual authentication and the establishment
+   of a master secret using Kerberos credentials.  The proposed changes
+   are minimal and, in fact, no different from adding a new public key
+   algorithm to the TLS framework.
+
+3. Kerberos Authentication Option In TLS
+
+   This section describes the addition of the Kerberos authentication
+   option to the TLS protocol.  Throughout this document, we refer to
+   the basic SSL handshake shown in Figure 1.  For a review of the TLS
+   handshake see [1].
+
+  CLIENT                                             SERVER
+  ------                                             ------
+ ClientHello
+                    -------------------------------->
+                                                     ServerHello
+                                                     Certificate *
+                                                     ServerKeyExchange*
+                                                     CertificateRequest*
+                                                     ServerHelloDone
+                    <-------------------------------
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ change cipher spec
+ Finished
+     |              -------------------------------->
+     |                                               change cipher spec
+     |                                               Finished
+     |                                                   |
+     |                                                   |
+ Application Data   <------------------------------->Application Data
+
+ FIGURE 1: The TLS protocol.  All messages followed by a star are
+           optional.  Note: This figure was taken from an IETF document
+           [1].
+
+   The TLS security context is negotiated in the client and server hello
+   messages.  For example: TLS_RSA_WITH_RC4_MD5 means the initial
+   authentication will be done using the RSA public key algorithm, RC4
+   will be used for the session key, and MACs will be based on the MD5
+   algorithm.  Thus, to facilitate the Kerberos authentication option,
+   we must start by defining new cipher suites including (but not
+   limited to):
+
+
+
+Medvinsky & Hur             Standards Track                     [Page 2]
+
+RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
+
+
+ CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
+ CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
+ CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
+ CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
+ CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
+ CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
+ CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
+ CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
+
+ CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26 };
+ CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27 };
+ CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28 };
+ CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29 };
+ CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A };
+ CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B };
+
+   To establish a Kerberos-based security context, one or more of the
+   above cipher suites must be specified in the client hello message.
+   If the TLS server supports the Kerberos authentication option, the
+   server hello message, sent to the client, will confirm the Kerberos
+   cipher suite selected by the server.  The server's certificate, the
+   client
+
+   CertificateRequest, and the ServerKeyExchange shown in Figure 1 will
+   be omitted since authentication and the establishment of a master
+   secret will be done using the client's Kerberos credentials for the
+   TLS server.  The client's certificate will be omitted for the same
+   reason.  Note that these messages are specified as optional in the
+   TLS protocol; therefore, omitting them is permissible.
+
+   The Kerberos option must be added to the ClientKeyExchange message as
+   shown in Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Medvinsky & Hur             Standards Track                     [Page 3]
+
+RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
+
+
+ struct
+ {
+     select (KeyExchangeAlgorithm)
+     {
+         case krb5:            KerberosWrapper;       /* new addition */
+         case rsa:             EncryptedPreMasterSecret;
+         case diffie_hellman:  ClientDiffieHellmanPublic;
+     } Exchange_keys;
+
+ } ClientKeyExchange;
+
+ struct
+ {
+     opaque Ticket;
+     opaque authenticator;            /* optional */
+     opaque EncryptedPreMasterSecret; /* encrypted with the session key
+                                         which is sealed in the ticket */
+ } KerberosWrapper;                   /* new addition */
+
+         FIGURE 2: The Kerberos option in the ClientKeyExchange.
+
+   To use the Kerberos authentication option, the TLS client must obtain
+   a service ticket for the TLS server.  In TLS, the ClientKeyExchange
+   message is used to pass a random 48-byte pre-master secret to the
+   server.
+
+   The client and server then use the pre-master secret to independently
+   derive the master secret, which in turn is used for generating
+   session keys and for MAC computations.  Thus, if the Kerberos option
+   is selected, the pre-master secret structure is the same as that used
+   in the RSA case; it is encrypted under the Kerberos session key and
+   sent to the TLS server along with the Kerberos credentials (see
+   Figure 2).  The ticket and authenticator are encoded per RFC 1510
+   (ASN.1 encoding).  Once the ClientKeyExchange message is received,
+   the server's secret key is used to unwrap the credentials and extract
+   the pre-master secret.
+
+   Note that a Kerberos authenticator is not required, since the master
+   secret derived by the client and server is seeded with a random value
+   passed in the server hello message, thus foiling replay attacks.
+   However, the authenticator may still prove useful for passing
+   authorization information and is thus allotted an optional field (see
+   Figure 2).
+
+   Lastly, the client and server exchange the finished messages to
+   complete the handshake.  At this point we have achieved the
+   following:
+
+
+
+
+Medvinsky & Hur             Standards Track                     [Page 4]
+
+RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
+
+
+   1) A master secret, used to protect all subsequent communication, is
+      securely established.
+
+   2) Mutual client-server authentication is achieved, since the TLS
+      server proves knowledge of the master secret in the finished
+      message.
+
+   Note that the Kerberos option fits in seamlessly, without adding any
+   new messages.
+
+4. Naming Conventions:
+
+   To obtain an appropriate service ticket, the TLS client must
+   determine the principal name of the TLS server.  The Kerberos service
+   naming convention is used for this purpose, as follows:
+
+     host/MachineName@Realm
+      where:
+        - The literal, "host", follows the Kerberos convention when not
+          concerned about the protection domain on a particular machine.
+        - "MachineName" is the particular instance of the service.
+        - The Kerberos "Realm" is the domain name of the machine.
+
+5. Summary
+
+   The proposed Kerberos authentication option is added in exactly the
+   same manner as a new public key algorithm would be added to TLS.
+   Furthermore, it establishes the master secret in exactly the same
+   manner.
+
+6. Security Considerations
+
+   Kerberos ciphersuites are subject to the same security considerations
+   as the TLS protocol.  In addition, just as a public key
+   implementation must take care to protect the private key (for example
+   the PIN for a smartcard), a Kerberos implementation must take care to
+   protect the long lived secret that is shared between the principal
+   and the KDC.  In particular, a weak password may be subject to a
+   dictionary attack.  In order to strengthen the initial authentication
+   to a KDC, an implementor may choose to utilize secondary
+   authentication via a token card, or one may utilize initial
+   authentication to the KDC based on public key cryptography (commonly
+   known as PKINIT - a product of the Common Authentication Technology
+   working group of the IETF).
+
+
+
+
+
+
+
+Medvinsky & Hur             Standards Track                     [Page 5]
+
+RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
+
+
+7. Acknowledgements
+
+   We would like to thank Clifford Neuman for his invaluable comments on
+   earlier versions of this document.
+
+8. References
+
+   [1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
+       2246, January 1999.
+
+   [2] Kohl J. and C. Neuman, "The Kerberos Network Authentication
+       Service (V5)", RFC 1510, September 1993.
+
+9. Authors' Addresses
+
+   Ari Medvinsky
+   Excite
+   555 Broadway
+   Redwood City, CA 94063
+
+   Phone: +1 650 569 2119
+   EMail: amedvins@excitecorp.com
+   http://www.excite.com
+
+
+   Matthew Hur
+   CyberSafe Corporation
+   1605 NW Sammamish Road
+   Issaquah WA 98027-5378
+
+   Phone: +1 425 391 6000
+   EMail: matt.hur@cybersafe.com
+   http://www.cybersafe.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Medvinsky & Hur             Standards Track                     [Page 6]
+
+RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
+
+
+10. Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Medvinsky & Hur             Standards Track                     [Page 7]
+
diff --git a/standards/rfc2817.txt b/standards/rfc2817.txt
new file mode 100644
index 000000000..d7b7e703b
--- /dev/null
+++ b/standards/rfc2817.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                           R. Khare
+Request for Comments: 2817                     4K Associates / UC Irvine
+Updates: 2616                                                S. Lawrence
+Category: Standards Track                          Agranat Systems, Inc.
+                                                                May 2000
+
+
+                    Upgrading to TLS Within HTTP/1.1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
+   initiate Transport Layer Security (TLS) over an existing TCP
+   connection. This allows unsecured and secured HTTP traffic to share
+   the same well known port (in this case, http: at 80 rather than
+   https: at 443). It also enables "virtual hosting", so a single HTTP +
+   TLS server can disambiguate traffic intended for several hostnames at
+   a single IP address.
+
+   Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this
+   memo also documents the HTTP CONNECT method for establishing end-to-
+   end tunnels across HTTP proxies. Finally, this memo establishes new
+   IANA registries for public HTTP status codes, as well as public or
+   private Upgrade product tokens.
+
+   This memo does NOT affect the current definition of the 'https' URI
+   scheme, which already defines a separate namespace
+   (http://example.org/ and https://example.org/ are not equivalent).
+
+
+
+
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 1]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+Table of Contents
+
+   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . .  4
+   3.  Client Requested Upgrade to HTTP over TLS  . . . . . . . . . .  4
+   3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.2 Mandatory Upgrade  . . . . . . . . . . . . . . . . . . . . . .  4
+   3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . .  4
+   4.  Server Requested Upgrade to HTTP over TLS  . . . . . . . . . .  5
+   4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . .  5
+   4.2 Mandatory Advertisement  . . . . . . . . . . . . . . . . . . .  5
+   5.  Upgrade across Proxies . . . . . . . . . . . . . . . . . . . .  6
+   5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . .  6
+   5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . .  6
+   5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . .  7
+   6.  Rationale for the use of a 4xx (client error) Status Code  . .  7
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   7.1 HTTP Status Code Registry  . . . . . . . . . . . . . . . . . .  8
+   7.2 HTTP Upgrade Token Registry  . . . . . . . . . . . . . . . . .  8
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
+   8.2 Security Considerations for CONNECT  . . . . . . . . . . . . . 10
+       References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+1. Motivation
+
+   The historical practice of deploying HTTP over SSL3 [3] has
+   distinguished the combination from HTTP alone by a unique URI scheme
+   and the TCP port number. The scheme 'http' meant the HTTP protocol
+   alone on port 80, while 'https' meant the HTTP protocol over SSL on
+   port 443.  Parallel well-known port numbers have similarly been
+   requested -- and in some cases, granted -- to distinguish between
+   secured and unsecured use of other application protocols (e.g.
+   snews, ftps). This approach effectively halves the number of
+   available well known ports.
+
+   At the Washington DC IETF meeting in December 1997, the Applications
+   Area Directors and the IESG reaffirmed that the practice of issuing
+   parallel "secure" port numbers should be deprecated. The HTTP/1.1
+   Upgrade mechanism can apply Transport Layer Security [6] to an open
+   HTTP connection.
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 2]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   In the nearly two years since, there has been broad acceptance of the
+   concept behind this proposal, but little interest in implementing
+   alternatives to port 443 for generic Web browsing. In fact, nothing
+   in this memo affects the current interpretation of https: URIs.
+   However, new application protocols built atop HTTP, such as the
+   Internet Printing Protocol [7], call for just such a mechanism in
+   order to move ahead in the IETF standards process.
+
+   The Upgrade mechanism also solves the "virtual hosting" problem.
+   Rather than allocating multiple IP addresses to a single host, an
+   HTTP/1.1 server will use the Host: header to disambiguate the
+   intended web service. As HTTP/1.1 usage has grown more prevalent,
+   more ISPs are offering name-based virtual hosting, thus delaying IP
+   address space exhaustion.
+
+   TLS (and SSL) have been hobbled by the same limitation as earlier
+   versions of HTTP: the initial handshake does not specify the intended
+   hostname, relying exclusively on the IP address. Using a cleartext
+   HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
+   certificates based on the initial Host: header -- will allow ISPs to
+   provide secure name-based virtual hosting as well.
+
+2. Introduction
+
+   TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-
+   to-end connection, optionally including strong mutual authentication,
+   using a variety of cryptosystems. Initially, a handshake phase uses
+   three subprotocols to set up a record layer, authenticate endpoints,
+   set parameters, as well as report errors.  Then, there is an ongoing
+   layered record protocol that handles encryption, compression, and
+   reassembly for the remainder of the connection. The latter is
+   intended to be completely transparent. For example, there is no
+   dependency between TLS's record markers and or certificates and
+   HTTP/1.1's chunked encoding or authentication.
+
+   Either the client or server can use the HTTP/1.1 [1] Upgrade
+   mechanism (Section 14.42) to indicate that a TLS-secured connection
+   is desired or necessary. This memo defines the "TLS/1.0" Upgrade
+   token, and a new HTTP Status Code, "426 Upgrade Required".
+
+   Section 3 and Section 4 describe the operation of a directly
+   connected client and server. Intermediate proxies must establish an
+   end-to-end tunnel before applying those operations, as explained in
+   Section 5.
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 3]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+2.1 Requirements Terminology
+
+   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
+   "MAY" that appear in this document are to be interpreted as described
+   in RFC 2119 [11].
+
+3. Client Requested Upgrade to HTTP over TLS
+
+   When the client sends an HTTP/1.1 request with an Upgrade header
+   field containing the token "TLS/1.0", it is requesting the server to
+   complete the current HTTP/1.1 request after switching to TLS/1.0.
+
+3.1 Optional Upgrade
+
+   A client MAY offer to switch to secured operation during any clear
+   HTTP request when an unsecured response would be acceptable:
+
+       GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
+       Host: example.bank.com
+       Upgrade: TLS/1.0
+       Connection: Upgrade
+
+   In this case, the server MAY respond to the clear HTTP operation
+   normally, OR switch to secured operation (as detailed in the next
+   section).
+
+   Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be
+   supplied within a Connection header field (section 14.10) whenever
+   Upgrade is present in an HTTP/1.1 message".
+
+3.2 Mandatory Upgrade
+
+   If an unsecured response would be unacceptable, a client MUST send an
+   OPTIONS request first to complete the switch to TLS/1.0 (if
+   possible).
+
+       OPTIONS * HTTP/1.1
+       Host: example.bank.com
+       Upgrade: TLS/1.0
+       Connection: Upgrade
+
+3.3 Server Acceptance of Upgrade Request
+
+   As specified in HTTP/1.1 [1], if the server is prepared to initiate
+   the TLS handshake, it MUST send the intermediate "101 Switching
+   Protocol" and MUST include an Upgrade response header specifying the
+   tokens of the protocol stack it is switching to:
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 4]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+       HTTP/1.1 101 Switching Protocols
+       Upgrade: TLS/1.0, HTTP/1.1
+       Connection: Upgrade
+
+   Note that the protocol tokens listed in the Upgrade header of a 101
+   Switching Protocols response specify an ordered 'bottom-up' stack.
+
+   As specified in  HTTP/1.1 [1], Section 10.1.2: "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".
+
+   Once the TLS handshake completes successfully, the server MUST
+   continue with the response to the original request. Any TLS handshake
+   failure MUST lead to disconnection, per the TLS error alert
+   specification.
+
+4. Server Requested Upgrade to HTTP over TLS
+
+   The Upgrade response header field advertises possible protocol
+   upgrades a server MAY accept. In conjunction with the "426 Upgrade
+   Required" status code, a server can advertise the exact protocol
+   upgrade(s) that a client MUST accept to complete the request.
+
+4.1 Optional Advertisement
+
+   As specified in HTTP/1.1 [1], the server MAY include an Upgrade
+   header in any response other than 101 or 426 to indicate a
+   willingness to switch to any (combination) of the protocols listed.
+
+4.2 Mandatory Advertisement
+
+   A server MAY indicate that a client request can not be completed
+   without TLS using the "426 Upgrade Required" status code, which MUST
+   include an an Upgrade header field specifying the token of the
+   required TLS version.
+
+       HTTP/1.1 426 Upgrade Required
+       Upgrade: TLS/1.0, HTTP/1.1
+       Connection: Upgrade
+
+   The server SHOULD include a message body in the 426 response which
+   indicates in human readable form the reason for the error and
+   describes any alternative courses which may be available to the user.
+
+   Note that even if a client is willing to use TLS, it must use the
+   operations in Section 3 to proceed; the TLS handshake cannot begin
+   immediately after the 426 response.
+
+
+
+Khare & Lawrence            Standards Track                     [Page 5]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+5. Upgrade across Proxies
+
+   As a hop-by-hop header, Upgrade is negotiated between each pair of
+   HTTP counterparties.  If a User Agent sends a request with an Upgrade
+   header to a proxy, it is requesting a change to the protocol between
+   itself and the proxy, not an end-to-end change.
+
+   Since TLS, in particular, requires end-to-end connectivity to provide
+   authentication and prevent man-in-the-middle attacks, this memo
+   specifies the CONNECT method to establish a tunnel across proxies.
+
+   Once a tunnel is established, any of the operations in Section 3 can
+   be used to establish a TLS connection.
+
+5.1 Implications of Hop By Hop Upgrade
+
+   If an origin server receives an Upgrade header from a proxy and
+   responds with a 101 Switching Protocols response, it is changing the
+   protocol only on the connection between the proxy and itself.
+   Similarly, a proxy might return a 101 response to its client to
+   change the protocol on that connection independently of the protocols
+   it is using to communicate toward the origin server.
+
+   These scenarios also complicate diagnosis of a 426 response.  Since
+   Upgrade is a hop-by-hop header, a proxy that does not recognize 426
+   might remove the accompanying Upgrade header and prevent the client
+   from determining the required protocol switch.  If a client receives
+   a 426 status without an accompanying Upgrade header, it will need to
+   request an end to end tunnel connection as described in Section 5.2
+   and repeat the request in order to obtain the required upgrade
+   information.
+
+   This hop-by-hop definition of Upgrade was a deliberate choice.  It
+   allows for incremental deployment on either side of proxies, and for
+   optimized protocols between cascaded proxies without the knowledge of
+   the parties that are not a part of the change.
+
+5.2 Requesting a Tunnel with CONNECT
+
+   A CONNECT method requests that a proxy establish a tunnel connection
+   on its behalf. The Request-URI portion of the Request-Line is always
+   an 'authority' as defined by URI Generic Syntax [2], which is to say
+   the host name and port number destination of the requested connection
+   separated by a colon:
+
+      CONNECT server.example.com:80 HTTP/1.1
+      Host: server.example.com:80
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 6]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   Other HTTP mechanisms can be used normally with the CONNECT method --
+   except end-to-end protocol Upgrade requests, of course, since the
+   tunnel must be established first.
+
+   For example, proxy authentication might be used to establish the
+   authority to create a tunnel:
+
+      CONNECT server.example.com:80 HTTP/1.1
+      Host: server.example.com:80
+      Proxy-Authorization: basic aGVsbG86d29ybGQ=
+
+   Like any other pipelined HTTP/1.1 request, data to be tunneled may be
+   sent immediately after the blank line. The usual caveats also apply:
+   data may be discarded if the eventual response is negative, and the
+   connection may be reset with no response if more than one TCP segment
+   is outstanding.
+
+5.3 Establishing a Tunnel with CONNECT
+
+   Any successful (2xx) response to a CONNECT request indicates that the
+   proxy has established a connection to the requested host and port,
+   and has switched to tunneling the current connection to that server
+   connection.
+
+   It may be the case that the proxy itself can only reach the requested
+   origin server through another proxy.  In this case, the first proxy
+   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
+   to the authority.  A proxy MUST NOT respond with any 2xx status code
+   unless it has either a direct or tunnel connection established to the
+   authority.
+
+   An origin server which receives a CONNECT request for itself MAY
+   respond with a 2xx status code to indicate that a connection is
+   established.
+
+   If at any point either one of the peers gets disconnected, any
+   outstanding data that came from that peer will be passed to the other
+   one, and after that also the other connection will be terminated by
+   the proxy. If there is outstanding data to that peer undelivered,
+   that data will be discarded.
+
+6. Rationale for the use of a 4xx (client error) Status Code
+
+   Reliable, interoperable negotiation of Upgrade features requires an
+   unambiguous failure signal. The 426 Upgrade Required status code
+   allows a server to definitively state the precise protocol extensions
+   a given resource must be served with.
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 7]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   It might at first appear that the response should have been some form
+   of redirection (a 3xx code), by analogy to an old-style redirection
+   to an https: URI.  User agents that do not understand Upgrade:
+   preclude this.
+
+   Suppose that a 3xx code had been assigned for "Upgrade Required"; a
+   user agent that did not recognize it would treat it as 300.  It would
+   then properly look for a "Location" header in the response and
+   attempt to repeat the request at the URL in that header field. Since
+   it did not know to Upgrade to incorporate the TLS layer, it would at
+   best fail again at the new URL.
+
+7. IANA Considerations
+
+   IANA shall create registries for two name spaces, as described in BCP
+   26 [10]:
+
+   o  HTTP Status Codes
+   o  HTTP Upgrade Tokens
+
+7.1 HTTP Status Code Registry
+
+   The HTTP Status Code Registry defines the name space for the Status-
+   Code token in the Status line of an HTTP response.  The initial
+   values for this name space are those specified by:
+
+   1.  Draft Standard for HTTP/1.1 [1]
+   2.  Web Distributed Authoring and Versioning [4] [defines 420-424]
+   3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
+   4.  Section 6 [defines 426]
+
+   Values to be added to this name space SHOULD be subject to review in
+   the form of a standards track document within the IETF Applications
+   Area.  Any such document SHOULD be traceable through statuses of
+   either 'Obsoletes' or 'Updates' to the Draft Standard for
+   HTTP/1.1 [1].
+
+7.2 HTTP Upgrade Token Registry
+
+   The HTTP Upgrade Token Registry defines the name space for product
+   tokens used to identify protocols in the Upgrade HTTP header field.
+   Each registered token should be associated with one or a set of
+   specifications, and with contact information.
+
+   The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
+   the production for 'product':
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 8]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+      product         = token ["/" product-version]
+      product-version = token
+
+   Registrations should be allowed on a First Come First Served basis as
+   described in BCP 26 [10]. These specifications need not be IETF
+   documents or be subject to IESG review, but should obey the following
+   rules:
+
+   1.  A token, once registered, stays registered forever.
+   2.  The registration MUST name a responsible party for the
+       registration.
+   3.  The registration MUST name a point of contact.
+   4.  The registration MAY name the documentation required for the
+       token.
+   5.  The responsible party MAY change the registration at any time.
+       The IANA will keep a record of all such changes, and make them
+       available upon request.
+   6.  The responsible party for the first registration of a "product"
+       token MUST approve later registrations of a "version" token
+       together with that "product" token before they can be registered.
+   7.  If absolutely required, the IESG MAY reassign the responsibility
+       for a token. This will normally only be used in the case when a
+       responsible party cannot be contacted.
+
+   This specification defines the protocol token "TLS/1.0" as the
+   identifier for the protocol specified by The TLS Protocol [6].
+
+   It is NOT required that specifications for upgrade tokens be made
+   publicly available, but the contact information for the registration
+   SHOULD be.
+
+8. Security Considerations
+
+   The potential for a man-in-the-middle attack (deleting the Upgrade
+   header) remains the same as current, mixed http/https practice:
+
+   o  Removing the Upgrade header is similar to rewriting web pages to
+      change https:// links to http:// links.
+   o  The risk is only present if the server is willing to vend such
+      information over both a secure and an insecure channel in the
+      first place.
+   o  If the client knows for a fact that a server is TLS-compliant, it
+      can insist on it by only sending an Upgrade request with a no-op
+      method like OPTIONS.
+   o  Finally, as the https: specification warns, "users should
+      carefully examine the certificate presented by the server to
+      determine if it meets their expectations".
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 9]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   Furthermore, for clients that do not explicitly try to invoke TLS,
+   servers can use the Upgrade header in any response other than 101 or
+   426 to advertise TLS compliance. Since TLS compliance should be
+   considered a feature of the server and not the resource at hand, it
+   should be sufficient to send it once, and let clients cache that
+   fact.
+
+8.1 Implications for the https: URI Scheme
+
+   While nothing in this memo affects the definition of the 'https' URI
+   scheme, widespread adoption of this mechanism for HyperText content
+   could use 'http' to identify both secure and non-secure resources.
+
+   The choice of what security characteristics are required on the
+   connection is left to the client and server.  This allows either
+   party to use any information available in making this determination.
+   For example, user agents may rely on user preference settings or
+   information about the security of the network such as 'TLS required
+   on all POST operations not on my local net', or servers may apply
+   resource access rules such as 'the FORM on this page must be served
+   and submitted using TLS'.
+
+8.2 Security Considerations for CONNECT
+
+   A generic TCP tunnel is fraught with security risks. First, such
+   authorization should be limited to a small number of known ports.
+   The Upgrade: mechanism defined here only requires onward tunneling at
+   port 80. Second, since tunneled data is opaque to the proxy, there
+   are additional risks to tunneling to other well-known or reserved
+   ports. A putative HTTP client CONNECTing to port 25 could relay spam
+   via SMTP, for example.
+
+References
+
+   [1]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+        HTTP/1.1", RFC 2616, June 1999.
+
+   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic
+        Syntax", RFC 2396, August 1998.
+
+   [3]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [4]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
+        "Web Distributed Authoring and Versioning", RFC 2518, February
+        1999.
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 10]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   [5]  Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
+        Protocol",  Work In Progress.
+
+   [6]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+        1999.
+
+   [7]  Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
+        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
+        1999.
+
+   [8]  Luotonen, A., "Tunneling TCP based protocols through Web proxy
+        servers",  Work In Progress.  (Also available in: Luotonen, Ari.
+        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
+
+   [9]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
+        1999.
+
+   [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+Authors' Addresses
+
+   Rohit Khare
+   4K Associates / UC Irvine
+   3207 Palo Verde
+   Irvine, CA  92612
+   US
+
+   Phone: +1 626 806 7574
+   EMail: rohit@4K-associates.com
+   URI:   http://www.4K-associates.com/
+
+
+   Scott Lawrence
+   Agranat Systems, Inc.
+   5 Clocktower Place
+   Suite 400
+   Maynard, MA  01754
+   US
+
+   Phone: +1 978 461 0888
+   EMail: lawrence@agranat.com
+   URI:   http://www.agranat.com/
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 11]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+Appendix A. Acknowledgments
+
+   The CONNECT method was originally described in a Work in Progress
+   titled, "Tunneling TCP based protocols through Web proxy servers",
+   [8] by Ari Luotonen of Netscape Communications Corporation.  It was
+   widely implemented by HTTP proxies, but was never made a part of any
+   IETF Standards Track document. The method name CONNECT was reserved,
+   but not defined in [1].
+
+   The definition provided here is derived directly from that earlier
+   memo, with some editorial changes and conformance to the stylistic
+   conventions since established in other HTTP specifications.
+
+   Additional Thanks to:
+
+   o  Paul Hoffman for his work on the STARTTLS command extension for
+      ESMTP.
+   o  Roy Fielding for assistance with the rationale behind Upgrade:
+      and its interaction with OPTIONS.
+   o  Eric Rescorla for his work on standardizing the existing https:
+      practice to compare with.
+   o  Marshall Rose, for the xml2rfc document type description and tools
+      [9].
+   o  Jim Whitehead, for sorting out the current range of available HTTP
+      status codes.
+   o  Henrik Frystyk Nielsen, whose work on the Mandatory extension
+      mechanism pointed out a hop-by-hop Upgrade still requires
+      tunneling.
+   o  Harald Alvestrand for improvements to the token registration
+      rules.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 12]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 13]
+
diff --git a/standards/rfc2818.txt b/standards/rfc2818.txt
new file mode 100644
index 000000000..219a1c427
--- /dev/null
+++ b/standards/rfc2818.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                       E. Rescorla
+Request for Comments: 2818                                   RTFM, Inc.
+Category: Informational                                        May 2000
+
+
+                             HTTP Over TLS
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo describes how to use TLS to secure HTTP connections over
+   the Internet. Current practice is to layer HTTP over SSL (the
+   predecessor to TLS), distinguishing secured traffic from insecure
+   traffic by the use of a different server port. This document
+   documents that practice using TLS. A companion document describes a
+   method for using HTTP/TLS over the same port as normal HTTP
+   [RFC2817].
+
+Table of Contents
+
+   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . 2
+   1.1. Requirements Terminology  . . . . . . . . . . . . . . . 2
+   2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 2
+   2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2
+   2.2. Connection Closure  . . . . . . . . . . . . . . . . . . 2
+   2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 3
+   2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3
+   2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . 4
+   2.4. URI Format  . . . . . . . . . . . . . . . . . . . . . . 4
+   3. Endpoint Identification . . . . . . . . . . . . . . . . . 4
+   3.1. Server Identity . . . . . . . . . . . . . . . . . . . . 4
+   3.2. Client Identity . . . . . . . . . . . . . . . . . . . . 5
+   References . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Security Considerations  . . . . . . . . . . . . . . . . . . 6
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+Rescorla                     Informational                      [Page 1]
+
+RFC 2818                     HTTP Over TLS                      May 2000
+
+
+1.  Introduction
+
+   HTTP [RFC2616] was originally used in the clear on the Internet.
+   However, increased use of HTTP for sensitive applications has
+   required security measures. SSL, and its successor TLS [RFC2246] were
+   designed to provide channel-oriented security. This document
+   describes how to use HTTP over TLS.
+
+1.1.  Requirements Terminology
+
+   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
+   "MAY" that appear in this document are to be interpreted as described
+   in [RFC2119].
+
+2.  HTTP Over TLS
+
+   Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
+   precisely as you would use HTTP over TCP.
+
+2.1.  Connection Initiation
+
+   The agent acting as the HTTP client should also act as the TLS
+   client.  It should initiate a connection to the server on the
+   appropriate port and then send the TLS ClientHello to begin the TLS
+   handshake. When the TLS handshake has finished. The client may then
+   initiate the first HTTP request.  All HTTP data MUST be sent as TLS
+   "application data".  Normal HTTP behavior, including retained
+   connections should be followed.
+
+2.2.  Connection Closure
+
+   TLS provides a facility for secure connection closure. When a valid
+   closure alert is received, an implementation can be assured that no
+   further data will be received on that connection.  TLS
+   implementations MUST initiate an exchange of closure alerts before
+   closing a connection. A TLS implementation MAY, after sending a
+   closure alert, close the connection without waiting for the peer to
+   send its closure alert, generating an "incomplete close".  Note that
+   an implementation which does this MAY choose to reuse the session.
+   This SHOULD only be done when the application knows (typically
+   through detecting HTTP message boundaries) that it has received all
+   the message data that it cares about.
+
+   As specified in [RFC2246], any implementation which receives a
+   connection close without first receiving a valid closure alert (a
+   "premature close") MUST NOT reuse that session.  Note that a
+   premature close does not call into question the security of the data
+   already received, but simply indicates that subsequent data might
+
+
+
+Rescorla                     Informational                      [Page 2]
+
+RFC 2818                     HTTP Over TLS                      May 2000
+
+
+   have been truncated. Because TLS is oblivious to HTTP
+   request/response boundaries, it is necessary to examine the HTTP data
+   itself (specifically the Content-Length header) to determine whether
+   the truncation occurred inside a message or between messages.
+
+2.2.1.  Client Behavior
+
+   Because HTTP uses connection closure to signal end of server data,
+   client implementations MUST treat any premature closes as errors and
+   the data received as potentially truncated.  While in some cases the
+   HTTP protocol allows the client to find out whether truncation took
+   place so that, if it received the complete reply, it may tolerate
+   such errors following the principle to "[be] strict when sending and
+   tolerant when receiving" [RFC1958], often truncation does not show in
+   the HTTP protocol data; two cases in particular deserve special note:
+
+     A HTTP response without a Content-Length header. Since data length
+     in this situation is signalled by connection close a premature
+     close generated by the server cannot be distinguished from a
+     spurious close generated by an attacker.
+
+     A HTTP response with a valid Content-Length header closed before
+     all data has been read. Because TLS does not provide document
+     oriented protection, it is impossible to determine whether the
+     server has miscomputed the Content-Length or an attacker has
+     truncated the connection.
+
+   There is one exception to the above rule. When encountering a
+   premature close, a client SHOULD treat as completed all requests for
+   which it has received as much data as specified in the Content-Length
+   header.
+
+   A client detecting an incomplete close SHOULD recover gracefully.  It
+   MAY resume a TLS session closed in this fashion.
+
+   Clients MUST send a closure alert before closing the connection.
+   Clients which are unprepared to receive any more data MAY choose not
+   to wait for the server's closure alert and simply close the
+   connection, thus generating an incomplete close on the server side.
+
+2.2.2.  Server Behavior
+
+   RFC 2616 permits an HTTP client to close the connection at any time,
+   and requires servers to recover gracefully.  In particular, servers
+   SHOULD be prepared to receive an incomplete close from the client,
+   since the client can often determine when the end of server data is.
+   Servers SHOULD be willing to resume TLS sessions closed in this
+   fashion.
+
+
+
+Rescorla                     Informational                      [Page 3]
+
+RFC 2818                     HTTP Over TLS                      May 2000
+
+
+   Implementation note: In HTTP implementations which do not use
+   persistent connections, the server ordinarily expects to be able to
+   signal end of data by closing the connection. When Content-Length is
+   used, however, the client may have already sent the closure alert and
+   dropped the connection.
+
+   Servers MUST attempt to initiate an exchange of closure alerts with
+   the client before closing the connection. Servers MAY close the
+   connection after sending the closure alert, thus generating an
+   incomplete close on the client side.
+
+2.3.  Port Number
+
+   The first data that an HTTP server expects to receive from the client
+   is the Request-Line production. The first data that a TLS server (and
+   hence an HTTP/TLS server) expects to receive is the ClientHello.
+   Consequently, common practice has been to run HTTP/TLS over a
+   separate port in order to distinguish which protocol is being used.
+   When HTTP/TLS is being run over a TCP/IP connection, the default port
+   is 443. This does not preclude HTTP/TLS from being run over another
+   transport. TLS only presumes a reliable connection-oriented data
+   stream.
+
+2.4.  URI Format
+
+   HTTP/TLS is differentiated from HTTP URIs by using the 'https'
+   protocol identifier in place of the 'http' protocol identifier. An
+   example URI specifying HTTP/TLS is:
+
+     https://www.example.com/~smith/home.html
+
+3.  Endpoint Identification
+
+3.1.  Server Identity
+
+   In general, HTTP/TLS requests are generated by dereferencing a URI.
+   As a consequence, the hostname for the server is known to the client.
+   If the hostname is available, the client MUST check it against the
+   server's identity as presented in the server's Certificate message,
+   in order to prevent man-in-the-middle attacks.
+
+   If the client has external information as to the expected identity of
+   the server, the hostname check MAY be omitted. (For instance, a
+   client may be connecting to a machine whose address and hostname are
+   dynamic but the client knows the certificate that the server will
+   present.) In such cases, it is important to narrow the scope of
+   acceptable certificates as much as possible in order to prevent man
+
+
+
+
+Rescorla                     Informational                      [Page 4]
+
+RFC 2818                     HTTP Over TLS                      May 2000
+
+
+   in the middle attacks.  In special cases, it may be appropriate for
+   the client to simply ignore the server's identity, but it must be
+   understood that this leaves the connection open to active attack.
+
+   If a subjectAltName extension of type dNSName is present, that MUST
+   be used as the identity. Otherwise, the (most specific) Common Name
+   field in the Subject field of the certificate MUST be used. Although
+   the use of the Common Name is existing practice, it is deprecated and
+   Certification Authorities are encouraged to use the dNSName instead.
+
+   Matching is performed using the matching rules specified by
+   [RFC2459].  If more than one identity of a given type is present in
+   the certificate (e.g., more than one dNSName name, a match in any one
+   of the set is considered acceptable.) Names may contain the wildcard
+   character * which is considered to match any single domain name
+   component or component fragment. E.g., *.a.com matches foo.a.com but
+   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
+
+   In some cases, the URI is specified as an IP address rather than a
+   hostname. In this case, the iPAddress subjectAltName must be present
+   in the certificate and must exactly match the IP in the URI.
+
+   If the hostname does not match the identity in the certificate, user
+   oriented clients MUST either notify the user (clients MAY give the
+   user the opportunity to continue with the connection in any case) or
+   terminate the connection with a bad certificate error. Automated
+   clients MUST log the error to an appropriate audit log (if available)
+   and SHOULD terminate the connection (with a bad certificate error).
+   Automated clients MAY provide a configuration setting that disables
+   this check, but MUST provide a setting which enables it.
+
+   Note that in many cases the URI itself comes from an untrusted
+   source. The above-described check provides no protection against
+   attacks where this source is compromised. For example, if the URI was
+   obtained by clicking on an HTML page which was itself obtained
+   without using HTTP/TLS, a man in the middle could have replaced the
+   URI.  In order to prevent this form of attack, users should carefully
+   examine the certificate presented by the server to determine if it
+   meets their expectations.
+
+3.2.  Client Identity
+
+   Typically, the server has no external knowledge of what the client's
+   identity ought to be and so checks (other than that the client has a
+   certificate chain rooted in an appropriate CA) are not possible. If a
+   server has such knowledge (typically from some source external to
+   HTTP or TLS) it SHOULD check the identity as described above.
+
+
+
+
+Rescorla                     Informational                      [Page 5]
+
+RFC 2818                     HTTP Over TLS                      May 2000
+
+
+References
+
+   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+             Public Key Infrastructure: Part I: X.509 Certificate and
+             CRL Profile", RFC 2459, January 1999.
+
+   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
+             L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
+             Protocol, HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
+             January 1999.
+
+   [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
+             HTTP/1.1", RFC 2817, May 2000.
+
+Security Considerations
+
+   This entire document is about security.
+
+Author's Address
+
+   Eric Rescorla
+   RTFM, Inc.
+   30 Newell Road, #16
+   East Palo Alto, CA 94303
+
+   Phone: (650) 328-8631
+   EMail: ekr@rtfm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                      [Page 6]
+
+RFC 2818                     HTTP Over TLS                      May 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                     Informational                      [Page 7]
+
diff --git a/standards/rfc2821.txt b/standards/rfc2821.txt
new file mode 100644
index 000000000..0eac91188
--- /dev/null
+++ b/standards/rfc2821.txt
@@ -0,0 +1,4427 @@
+
+
+
+
+
+
+Network Working Group                                 J. Klensin, Editor
+Request for Comments: 2821                             AT&T Laboratories
+Obsoletes: 821, 974, 1869                                     April 2001
+Updates: 1123
+Category: Standards Track
+
+
+                     Simple Mail Transfer Protocol
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document is a self-contained specification of the basic protocol
+   for the Internet electronic mail transport.  It consolidates, updates
+   and clarifies, but doesn't add new or change existing functionality
+   of the following:
+
+   -  the original SMTP (Simple Mail Transfer Protocol) specification of
+      RFC 821 [30],
+
+   -  domain name system requirements and implications for mail
+      transport from RFC 1035 [22] and RFC 974 [27],
+
+   -  the clarifications and applicability statements in RFC 1123 [2],
+      and
+
+   -  material drawn from the SMTP Extension mechanisms [19].
+
+   It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
+   mail transport materials of RFC 1123).  However, RFC 821 specifies
+   some features that were not in significant use in the Internet by the
+   mid-1990s and (in appendices) some additional transport models.
+   Those sections are omitted here in the interest of clarity and
+   brevity; readers needing them should refer to RFC 821.
+
+
+
+
+
+
+Klensin                     Standards Track                     [Page 1]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   It also includes some additional material from RFC 1123 that required
+   amplification.  This material has been identified in multiple ways,
+   mostly by tracking flaming on various lists and newsgroups and
+   problems of unusual readings or interpretations that have appeared as
+   the SMTP extensions have been deployed.  Where this specification
+   moves beyond consolidation 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 submission' protocol, as recommended for POP [3, 26]
+   and IMAP [6].  Additional submission issues are discussed in RFC 2476
+   [15].
+
+   Section 2.3 provides definitions of terms specific to this document.
+   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 [32] discusses message headers, message bodies
+   and formats and structures for them, and their relationship.
+
+Table of Contents
+
+   1. Introduction ..................................................  4
+   2. The SMTP Model ................................................  5
+   2.1 Basic Structure ..............................................  5
+   2.2 The Extension Model ..........................................  7
+   2.2.1 Background .................................................  7
+   2.2.2 Definition and Registration of Extensions ..................  8
+   2.3 Terminology ..................................................  9
+   2.3.1 Mail Objects ............................................... 10
+   2.3.2 Senders and Receivers ...................................... 10
+   2.3.3 Mail Agents and Message Stores ............................. 10
+   2.3.4 Host ....................................................... 11
+   2.3.5 Domain ..................................................... 11
+   2.3.6 Buffer and State Table ..................................... 11
+   2.3.7 Lines ...................................................... 12
+   2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
+   2.3.9 Message Content and Mail Data .............................. 13
+   2.3.10 Mailbox and Address ....................................... 13
+   2.3.11 Reply ..................................................... 13
+   2.4 General Syntax Principles and Transaction Model .............. 13
+   3. The SMTP Procedures: An Overview .............................. 15
+   3.1 Session Initiation ........................................... 15
+   3.2 Client Initiation ............................................ 16
+   3.3 Mail Transactions ............................................ 16
+   3.4 Forwarding for Address Correction or Updating ................ 19
+
+
+
+Klensin                     Standards Track                     [Page 2]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   3.5 Commands for Debugging Addresses ............................. 20
+   3.5.1 Overview ................................................... 20
+   3.5.2 VRFY Normal Response ....................................... 22
+   3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
+   3.5.4 Semantics and Applications of EXPN ......................... 23
+   3.6 Domains ...................................................... 23
+   3.7 Relaying ..................................................... 24
+   3.8 Mail Gatewaying .............................................. 25
+   3.8.1 Header Fields in Gatewaying ................................ 26
+   3.8.2 Received Lines in Gatewaying ............................... 26
+   3.8.3 Addresses in Gatewaying .................................... 26
+   3.8.4 Other Header Fields in Gatewaying .......................... 27
+   3.8.5 Envelopes in Gatewaying .................................... 27
+   3.9 Terminating Sessions and Connections ......................... 27
+   3.10 Mailing Lists and Aliases ................................... 28
+   3.10.1 Alias ..................................................... 28
+   3.10.2 List ...................................................... 28
+   4. The SMTP Specifications ....................................... 29
+   4.1 SMTP Commands ................................................ 29
+   4.1.1 Command Semantics and Syntax ............................... 29
+   4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO) ................... 29
+   4.1.1.2 MAIL (MAIL) .............................................. 31
+   4.1.1.3 RECIPIENT (RCPT) ......................................... 31
+   4.1.1.4 DATA (DATA) .............................................. 33
+   4.1.1.5 RESET (RSET) ............................................. 34
+   4.1.1.6 VERIFY (VRFY) ............................................ 35
+   4.1.1.7 EXPAND (EXPN) ............................................ 35
+   4.1.1.8 HELP (HELP) .............................................. 35
+   4.1.1.9 NOOP (NOOP) .............................................. 35
+   4.1.1.10 QUIT (QUIT) ............................................. 36
+   4.1.2 Command Argument Syntax .................................... 36
+   4.1.3 Address Literals ........................................... 38
+   4.1.4 Order of Commands .......................................... 39
+   4.1.5 Private-use Commands ....................................... 40
+   4.2  SMTP Replies ................................................ 40
+   4.2.1 Reply Code Severities and Theory ........................... 42
+   4.2.2 Reply Codes by Function Groups ............................. 44
+   4.2.3  Reply Codes in Numeric Order .............................. 45
+   4.2.4 Reply Code 502 ............................................. 46
+   4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
+   4.3 Sequencing of Commands and Replies ........................... 47
+   4.3.1 Sequencing Overview ........................................ 47
+   4.3.2 Command-Reply Sequences .................................... 48
+   4.4 Trace Information ............................................ 49
+   4.5 Additional Implementation Issues ............................. 53
+   4.5.1 Minimum Implementation ..................................... 53
+   4.5.2 Transparency ............................................... 53
+   4.5.3 Sizes and Timeouts ......................................... 54
+
+
+
+Klensin                     Standards Track                     [Page 3]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   4.5.3.1 Size limits and minimums ................................. 54
+   4.5.3.2 Timeouts ................................................. 56
+   4.5.4 Retry Strategies ........................................... 57
+   4.5.4.1 Sending Strategy ......................................... 58
+   4.5.4.2 Receiving Strategy ....................................... 59
+   4.5.5 Messages with a null reverse-path .......................... 59
+   5. Address Resolution and Mail Handling .......................... 60
+   6. Problem Detection and Handling ................................ 62
+   6.1 Reliable Delivery and Replies by Email ....................... 62
+   6.2 Loop Detection ............................................... 63
+   6.3 Compensating for Irregularities .............................. 63
+   7. Security Considerations ....................................... 64
+   7.1 Mail Security and Spoofing ................................... 64
+   7.2 "Blind" Copies ............................................... 65
+   7.3 VRFY, EXPN, and Security ..................................... 65
+   7.4 Information Disclosure in Announcements ...................... 66
+   7.5 Information Disclosure in Trace Fields ....................... 66
+   7.6 Information Disclosure in Message Forwarding ................. 67
+   7.7 Scope of Operation of SMTP Servers ........................... 67
+   8. IANA Considerations ........................................... 67
+   9. References .................................................... 68
+   10. Editor's Address ............................................. 70
+   11. Acknowledgments .............................................. 70
+   Appendices ....................................................... 71
+   A. TCP Transport Service ......................................... 71
+   B. Generating SMTP Commands from RFC 822 Headers ................. 71
+   C. Source Routes ................................................. 72
+   D. Scenarios ..................................................... 73
+   E. Other Gateway Issues .......................................... 76
+   F. Deprecated Features of RFC 821 ................................ 76
+   Full Copyright Statement ......................................... 79
+
+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.
+
+   An important feature of SMTP is its capability to transport mail
+   across networks, usually referred to as "SMTP mail relaying" (see
+   section 3.8).  A network consists of the mutually-TCP-accessible
+   hosts on the public Internet, the mutually-TCP-accessible hosts on a
+   firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
+   environment utilizing a non-TCP transport-level protocol.  Using
+
+
+
+Klensin                     Standards Track                     [Page 4]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   SMTP, a process can transfer mail to another process on the same
+   network or to some other network via a relay or gateway process
+   accessible to both networks.
+
+   In this way, a mail message may pass through a number of intermediate
+   relay or gateway hosts on its path from sender to ultimate recipient.
+   The Mail eXchanger mechanisms of the domain name system [22, 27] (and
+   section 5 of this document) are used to identify the appropriate
+   next-hop destination for a message being transported.
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+   The SMTP design can be pictured as:
+
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Client- |Commands/Replies| Server-  |
+   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+   | File |<-->|          |    and Mail    |          |<-->| File |
+   |System|    |          |                |          |    |System|
+   +------+    +----------+                +----------+    +------+
+                SMTP client                SMTP server
+
+   When an SMTP client has a message to transmit, it establishes a two-
+   way transmission channel to an SMTP server.  The responsibility of an
+   SMTP client is to transfer mail messages to one or more SMTP servers,
+   or report its failure to do so.
+
+   The means by which a mail message is presented to an SMTP client, and
+   how that client determines the domain name(s) to which mail messages
+   are to be transferred is a local matter, and is not addressed by this
+   document.  In some cases, the domain name(s) transferred to, or
+   determined by, an SMTP client will identify the final destination(s)
+   of the mail message.  In other cases, common with SMTP clients
+   associated with implementations of the POP [3, 26] or IMAP [6]
+   protocols, or when the SMTP client is inside an isolated transport
+   service environment, the domain name determined will identify an
+   intermediate destination through which all mail messages are to be
+   relayed.  SMTP clients that transfer all traffic, regardless of the
+   target domain names associated with the individual messages, or that
+   do not maintain queues for retrying message transmissions that
+   initially cannot be completed, may otherwise conform to this
+   specification but are not considered fully-capable.  Fully-capable
+   SMTP implementations, including the relays used by these less capable
+
+
+
+
+Klensin                     Standards Track                     [Page 5]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   ones, and their destinations, are expected to support all of the
+   queuing, retrying, and alternate address functions discussed in this
+   specification.
+
+   The means by which an SMTP client, once it has determined a target
+   domain name, determines the identity of an SMTP server to which a
+   copy of a message is to be transferred, and then performs that
+   transfer, is covered by this document.  To effect a mail transfer to
+   an SMTP server, an SMTP client establishes a two-way transmission
+   channel to that SMTP server.  An SMTP client determines the address
+   of an appropriate host running an SMTP server by resolving a
+   destination domain name to either an intermediate Mail eXchanger host
+   or a final target host.
+
+   An SMTP server may be either the ultimate destination or an
+   intermediate "relay" (that is, it may assume the role of an SMTP
+   client after receiving the message) or "gateway" (that is, it may
+   transport the message further using some protocol other than SMTP).
+   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.
+
+   In other words, message transfer can occur in a single connection
+   between the original SMTP-sender and the final SMTP-recipient, or can
+   occur in a series of hops through intermediary systems.  In either
+   case, a formal handoff of responsibility for the message occurs: the
+   protocol requires that a server accept responsibility for either
+   delivering a message or properly reporting the failure to do so.
+
+   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 content (including any headers or other structure) itself.
+   When the same message is sent to multiple recipients, this protocol
+   encourages the transmission of only one copy of the data for all
+   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 specifying 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 such as command
+   pipelining [13].
+
+
+
+
+
+Klensin                     Standards Track                     [Page 6]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   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.  In addition, an SMTP client may use a connection to an
+   SMTP server for ancillary services such as verification of email
+   addresses or retrieval of mailing list subscriber addresses.
+
+   As suggested above, this protocol provides mechanisms for the
+   transmission of mail.  This transmission normally 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 acts as
+   either an SMTP relay or as a gateway into some other transmission
+   environment is usually selected through the use of the domain name
+   service (DNS) Mail eXchanger mechanism.
+
+   Usually, intermediate hosts are determined via the DNS MX record, not
+   by explicit "source" routing (see section 5 and appendices C and
+   F.2).
+
+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 beyond the original SMTP requirements.
+   The SMTP extension mechanism defines a means whereby an extended SMTP
+   client and server may recognize each other, and the server can inform
+   the client as to the service extensions that it supports.
+
+   Contemporary SMTP implementations MUST support the basic extension
+   mechanisms.  For instance, servers MUST support the EHLO command even
+   if they do not implement any specific extensions and clients SHOULD
+   preferentially utilize EHLO rather than HELO.  (However, for
+   compatibility with older conforming implementations, SMTP clients and
+   servers MUST support the original HELO mechanisms as a fallback.)
+   Unless the different characteristics of HELO must be identified for
+   interoperability purposes, this document discusses only EHLO.
+
+   SMTP is widely deployed and high-quality implementations have proven
+   to be very robust.  However, the Internet community now considers
+   some services to be important that were not anticipated when the
+   protocol was first designed.  If support for those services is to be
+   added, it must be done in a way that permits older implementations to
+   continue working acceptably.  The extension framework consists of:
+
+
+
+
+Klensin                     Standards Track                     [Page 7]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   -  The SMTP command EHLO, superseding the earlier HELO,
+
+   -  a registry of SMTP service extensions,
+
+   -  additional parameters to the SMTP MAIL and RCPT commands, and
+
+   -  optional replacements for commands defined in this protocol, such
+      as for DATA in non-ASCII transmissions [33].
+
+   SMTP's strength comes primarily from its simplicity.  Experience with
+   many protocols has shown that protocols with few options tend towards
+   ubiquity, whereas protocols with many options tend towards obscurity.
+
+   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.
+
+2.2.2 Definition and Registration of Extensions
+
+   The IANA maintains a registry of SMTP service extensions.  A
+   corresponding EHLO keyword value is associated with each extension.
+   Each service extension registered with the IANA must be defined in a
+   formal standards-track or IESG-approved experimental protocol
+   document.  The definition must include:
+
+   -  the textual name of the SMTP service extension;
+
+   -  the EHLO keyword value associated with the extension;
+
+   -  the syntax and possible values of parameters associated with the
+      EHLO keyword value;
+
+   -  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);
+
+   -  any new parameters the extension associates with the MAIL or RCPT
+      verbs;
+
+   -  a description of how support for the extension affects the
+      behavior of a server and client SMTP; and,
+
+   -  the increment by which the extension is increasing the maximum
+      length of the commands MAIL and/or RCPT, over that specified in
+      this standard.
+
+
+
+
+
+Klensin                     Standards Track                     [Page 8]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   In addition, any EHLO keyword value starting with an upper or lower
+   case "X" refers to a local SMTP service extension used exclusively
+   through bilateral agreement.  Keywords beginning with "X" MUST NOT be
+   used in a registered service extension.  Conversely, 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 and parameter names are bound by the same rules as
+   EHLO keywords; specifically, verbs beginning with "X" are local
+   extensions that may not be registered or standardized.  Conversely,
+   verbs not beginning with "X" must always be registered.
+
+2.3 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described below.
+
+   1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
+      the definition is an absolute requirement of the specification.
+
+   2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
+      definition is an absolute prohibition of the specification.
+
+   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
+      there may exist valid reasons in particular circumstances to
+      ignore a particular item, but the full implications must be
+      understood and carefully weighed before choosing a different
+      course.
+
+   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean
+      that there may exist valid reasons in particular circumstances
+      when the particular behavior is acceptable or even useful, but the
+      full implications should be understood and the case carefully
+      weighed before implementing any behavior described with this
+      label.
+
+   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+      truly optional.  One vendor may choose to include the item because
+      a particular marketplace requires it or because the vendor feels
+      that it enhances the product while another vendor may omit the
+      same item.  An implementation which does not include a particular
+      option MUST be prepared to interoperate with another
+      implementation which does include the option, though perhaps with
+      reduced functionality.  In the same vein an implementation which
+
+
+
+Klensin                     Standards Track                     [Page 9]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      does include a particular option MUST be prepared to interoperate
+      with another implementation which does not include the option
+      (except, of course, for the feature the option provides.)
+
+2.3.1 Mail Objects
+
+   SMTP transports a mail object.  A mail object contains an envelope
+   and content.
+
+   The SMTP envelope 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); one or more recipient
+   addresses; and optional protocol extension material.  Historically,
+   variations on the recipient address specification command (RCPT TO)
+   could be used to specify alternate delivery modes, such as immediate
+   display; those variations have now been deprecated (see appendix F,
+   section F.6).
+
+   The SMTP content is sent in the SMTP DATA protocol unit and has two
+   parts:  the headers and the body.  If the content conforms to other
+   contemporary standards, the headers form a collection of field/value
+   pairs structured as in the message format specification [32]; the
+   body, if structured, is defined according to MIME [12].  The content
+   is textual in nature, expressed using the US-ASCII repertoire [1].
+   Although SMTP extensions (such as "8BITMIME" [20]) may relax this
+   restriction for the content body, the content headers are always
+   encoded using the US-ASCII repertoire.  A MIME extension [23] defines
+   an algorithm for representing header values outside the US-ASCII
+   repertoire, while still encoding them using the US-ASCII repertoire.
+
+2.3.2 Senders 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 and Message Stores
+
+   Additional 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
+
+
+
+Klensin                     Standards Track                    [Page 10]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   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, e.g., by
+   depositing the message in a "message store").  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
+
+   For the purposes of this specification, a host is a computer system
+   attached to the Internet (or, in some cases, to a private TCP/IP
+   network) and supporting the SMTP protocol.  Hosts are known by names
+   (see "domain"); identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+   A domain (or domain name) consists of one or more dot-separated
+   components.  These components ("labels" in DNS terminology [22]) are
+   restricted for SMTP purposes to consist of a sequence of letters,
+   digits, and hyphens drawn from the ASCII character set [1].  Domain
+   names are used as names of hosts and of other entities in the domain
+   name hierarchy.  For example, a domain may refer to an alias (label
+   of a CNAME RR) or the label of Mail eXchanger records to be used to
+   deliver mail instead of representing a host name.  See [22] and
+   section 5 of this specification.
+
+   The domain name, as described in this document and in [22], is the
+   entire, fully-qualified name (often referred to as an "FQDN").  A
+   domain name that is not in FQDN form is no more than a local alias.
+   Local aliases MUST NOT appear in any SMTP transaction.
+
+2.3.6 Buffer and State Table
+
+   SMTP sessions are stateful, with both parties carefully maintaining a
+   common view of the current state.  In this document we model this
+   state by a virtual "buffer" and a "state table" on the server which
+   may be used by the client to, for example, "clear the buffer" or
+   "reset the state table," causing the information in the buffer to be
+   discarded and the state to be returned to some previous state.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 11]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+2.3.7 Lines
+
+   SMTP commands and, unless altered by a service extension, message
+   data, are transmitted in "lines".  Lines consist of zero or more data
+   characters terminated by the sequence ASCII character "CR" (hex value
+   0D) followed immediately by ASCII character "LF" (hex value 0A).
+   This termination sequence is denoted as <CRLF> in this document.
+   Conforming implementations MUST NOT recognize or generate any other
+   character or character sequence as a line terminator.  Limits MAY be
+   imposed on line lengths by servers (see section 4.5.3).
+
+   In addition, the appearance of "bare" "CR" or "LF" characters in text
+   (i.e., either without the other) has a long history of causing
+   problems in mail implementations and applications that use the mail
+   system as a tool.  SMTP client implementations MUST NOT transmit
+   these characters except when they are intended as line terminators
+   and then MUST, as indicated above, transmit them only as a <CRLF>
+   sequence.
+
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+
+   This specification makes a distinction among four types of SMTP
+   systems, based on the role those systems play in transmitting
+   electronic mail.  An "originating" system (sometimes called an SMTP
+   originator) introduces mail into the Internet or, more generally,
+   into a transport service environment.  A "delivery" SMTP system is
+   one that receives mail from a transport service environment and
+   passes it to a mail user agent or deposits it in a message store
+   which a mail user agent is expected to subsequently access.  A
+   "relay" SMTP system (usually referred to just as a "relay") receives
+   mail from an SMTP client and transmits it, without modification to
+   the message data other than adding trace information, to another SMTP
+   server for further relaying or for delivery.
+
+   A "gateway" SMTP system (usually referred to just as a "gateway")
+   receives mail from a client system in one transport environment and
+   transmits it to a server system in another transport environment.
+   Differences in protocols or message semantics between the transport
+   environments on either side of a gateway may require that the gateway
+   system perform transformations to the message that are not permitted
+   to SMTP relay systems.  For the purposes of this specification,
+   firewalls that rewrite addresses should be considered as gateways,
+   even if SMTP is used on both sides of them (see [11]).
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 12]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+2.3.9 Message Content and Mail Data
+
+   The terms "message content" and "mail data" are used interchangeably
+   in this document to describe the material transmitted after the DATA
+   command is accepted and before the end of data indication is
+   transmitted.  Message content includes message headers and the
+   possibly-structured message body.  The MIME specification [12]
+   provides the standard mechanisms for structured message bodies.
+
+2.3.10 Mailbox and Address
+
+   As used in this specification, an "address" is a character string
+   that identifies a user to whom mail will be sent or a location into
+   which mail will be deposited.  The term "mailbox" refers to that
+   depository.  The two terms are typically used interchangeably unless
+   the distinction between the location in which mail is placed (the
+   mailbox) and a reference to it (the address) is important.  An
+   address normally consists of user and domain specifications.  The
+   standard mailbox naming convention is defined to be "local-
+   part@domain": contemporary usage permits a much broader set of
+   applications than simple "user names".  Consequently, and due to a
+   long history of problems when intermediate hosts have attempted to
+   optimize transport by modifying them, the local-part MUST be
+   interpreted and assigned semantics only by the host specified in the
+   domain part of the address.
+
+2.3.11 Reply
+
+   An SMTP 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 numeric completion code
+   (indicating failure or success) usually followed by a text string.
+   The codes are for use by programs and the text is usually intended
+   for human users.  Recent work [34] has specified further structuring
+   of the reply strings, including the use of supplemental and more
+   specific completion codes.
+
+2.4 General Syntax Principles and Transaction Model
+
+   SMTP commands and replies have a rigid syntax.  All commands begin
+   with a command verb.  All Replies begin with a three digit numeric
+   code.  In some commands and replies, arguments MUST follow the verb
+   or reply code.  Some commands do not accept arguments (after the
+   verb), and some reply codes are followed, sometimes optionally, by
+   free form text.  In both cases, where text appears, it is separated
+   from the verb or reply code by a space character.  Complete
+   definitions of commands and replies appear in section 4.
+
+
+
+
+Klensin                     Standards Track                    [Page 13]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
+   and extension name keywords) are not case sensitive, with the sole
+   exception in this specification of a mailbox local-part (SMTP
+   Extensions may explicitly specify case-sensitive elements).  That is,
+   a command verb, an argument value other than a mailbox local-part,
+   and free form text MAY be encoded in upper case, lower case, or any
+   mixture of upper and lower case with no impact on its meaning.  This
+   is NOT true of a mailbox local-part.  The local-part of a mailbox
+   MUST BE treated as case sensitive.  Therefore, SMTP implementations
+   MUST take care to preserve the case of mailbox local-parts.  Mailbox
+   domains are not case sensitive.  In particular, for some hosts the
+   user "smith" is different from the user "Smith".  However, exploiting
+   the case sensitivity of mailbox local-parts impedes interoperability
+   and is discouraged.
+
+   A few SMTP servers, in violation of this specification (and RFC 821)
+   require that command verbs be encoded by clients in upper case.
+   Implementations MAY wish to employ this encoding to accommodate those
+   servers.
+
+   The argument field consists of a variable length character string
+   ending with the end of the line, i.e., with the character sequence
+   <CRLF>.  The receiver will 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.
+
+   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.  An originating SMTP client which has not
+   successfully negotiated an appropriate extension with a particular
+   server 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.  In general, a relay SMTP SHOULD assume that
+   the message content it has received is valid and, assuming that the
+   envelope permits doing so, relay it without inspecting that content.
+   Of course, if the content is mislabeled and the data path cannot
+   accept the actual content, this may result in ultimate delivery of a
+   severely garbled message to the recipient.  Delivery SMTP systems MAY
+   reject ("bounce") such messages rather than deliver them.  No sending
+   SMTP system is permitted to send envelope commands in any character
+
+
+
+
+
+Klensin                     Standards Track                    [Page 14]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   set other than US-ASCII; receiving systems SHOULD reject such
+   commands, normally using "500 syntax error - invalid character"
+   replies.
+
+   Eight-bit message content transmission MAY be requested of the server
+   by a client using extended SMTP facilities, notably the "8BITMIME"
+   extension [20].  8BITMIME SHOULD be supported by SMTP servers.
+   However, it MUST not be construed as authorization to transmit
+   unrestricted eight bit material.  8BITMIME MUST NOT be requested by
+   senders for material with the high bit on that is not in MIME format
+   with an appropriate content-transfer encoding; servers MAY reject
+   such messages.
+
+   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 the ABNF
+   specification [8].  Metalanguage terms used in running text are
+   surrounded by pointed brackets (e.g., <CRLF>) for clarity.
+
+3. The SMTP Procedures: An Overview
+
+   This section contains descriptions of the procedures used in SMTP:
+   session initiation, the mail transaction, forwarding mail, verifying
+   mailbox names and expanding mailing lists, and the opening and
+   closing exchanges.  Comments on relaying, a note on mail domains, and
+   a discussion of changing roles are included at the end of this
+   section.  Several complete scenarios are presented in appendix D.
+
+3.1 Session Initiation
+
+   An SMTP session is initiated when a client opens a connection to a
+   server and the server responds with an opening message.
+
+   SMTP server implementations MAY include identification of their
+   software and version information in the connection greeting reply
+   after the 220 code, a practice that permits more efficient isolation
+   and repair of any problems.  Implementations MAY make provision for
+   SMTP servers to disable the software and version announcement where
+   it causes security concerns.  While some systems also identify their
+   contact point for mail problems, this is not a substitute for
+   maintaining the required "postmaster" address (see section 4.5.1).
+
+   The SMTP protocol allows a server to formally reject a transaction
+   while still allowing the initial connection as follows: a 554
+   response MAY be given in the initial connection opening message
+   instead of the 220.  A server taking this approach MUST still wait
+   for the client to send a QUIT (see section 4.1.1.10) before closing
+   the connection and SHOULD respond to any intervening commands with
+
+
+
+Klensin                     Standards Track                    [Page 15]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   "503 bad sequence of commands".  Since an attempt to make an SMTP
+   connection to such a system is probably in error, a server returning
+   a 554 response on connection opening SHOULD provide enough
+   information in the reply text to facilitate debugging of the sending
+   system.
+
+3.2 Client Initiation
+
+   Once the server has sent the welcoming message and the client has
+   received it, the client normally sends the EHLO command to the
+   server, indicating the client's 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 which are unable to
+   support service extensions and contemporary clients which do not
+   require service extensions in the mail session being initiated, MAY
+   use HELO instead of EHLO.  Servers MUST NOT return the extended
+   EHLO-style response to a HELO command.  For a particular connection
+   attempt, if the server returns a "command not recognized" response to
+   EHLO, the client SHOULD be able to fall back and send HELO.
+
+   In the EHLO command the host sending the command identifies itself;
+   the command may be interpreted as saying "Hello, I am <domain>" (and,
+   in the case of EHLO, "and I support service extension requests").
+
+3.3 Mail Transactions
+
+   There are three steps to SMTP mail transactions.  The transaction
+   starts with a MAIL command which gives the sender identification.
+   (In general, the MAIL command may be sent only when no mail
+   transaction is in progress; see section 4.1.4.)  A series of one or
+   more RCPT commands follows giving the receiver information.  Then a
+   DATA command initiates transfer of the mail data and is terminated by
+   the "end of mail" data indicator, which also confirms the
+   transaction.
+
+   The first step in the procedure is the MAIL command.
+
+      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
+
+   This command tells the SMTP-receiver that a new mail transaction is
+   starting and to reset all its state tables and buffers, including any
+   recipients or mail data.  The <reverse-path> portion of the first or
+   only argument contains the source mailbox (between "<" and ">"
+   brackets), 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.  If the mailbox specification is not acceptable for
+   some reason, the server MUST return a reply indicating whether the
+
+
+
+Klensin                     Standards Track                    [Page 16]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   failure is permanent (i.e., will occur again if the client tries to
+   send the same address again) or temporary (i.e., the address might be
+   accepted if the client tries again later).  Despite the apparent
+   scope of this requirement, there are circumstances in which the
+   acceptability of the reverse-path may not be determined until one or
+   more forward-paths (in RCPT commands) can be examined.  In those
+   cases, the server MAY reasonably accept the reverse-path (with a 250
+   reply) and then report problems after the forward-paths are received
+   and examined.  Normally, failures produce 550 or 553 replies.
+
+   Historically, the <reverse-path> can contain more than just a
+   mailbox, however, contemporary systems SHOULD NOT use source routing
+   (see appendix C).
+
+   The optional <mail-parameters> are associated with negotiated SMTP
+   service extensions (see section 2.2).
+
+   The second step in the procedure is the RCPT command.
+
+      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
+
+   The first or only argument to this command includes a forward-path
+   (normally a mailbox and domain, always surrounded by "<" and ">"
+   brackets) identifying one recipient.  If accepted, the SMTP server
+   returns a 250 OK reply and stores the forward-path.  If the recipient
+   is known not to be a deliverable address, the SMTP server returns a
+   550 reply, typically with a string such as "no such user - " and the
+   mailbox name (other circumstances and reply codes are possible).
+   This step of the procedure can be repeated any number of times.
+
+   The <forward-path> can contain more than just a mailbox.
+   Historically, the <forward-path> can be a source routing list of
+   hosts and the destination mailbox, however, contemporary SMTP clients
+   SHOULD NOT utilize source routes (see appendix C).  Servers MUST be
+   prepared to encounter a list of source routes in the forward path,
+   but SHOULD ignore the routes or MAY decline to support the relaying
+   they imply.  Similarly, servers MAY decline to accept mail that is
+   destined for other hosts or systems.  These restrictions make a
+   server useless as a relay for clients that do not support full SMTP
+   functionality.  Consequently, restricted-capability clients MUST NOT
+   assume that any SMTP server on the Internet can be used as their mail
+   processing (relaying) site.  If a RCPT command appears without a
+   previous MAIL command, the server MUST return a 503 "Bad sequence of
+   commands" response.  The optional <rcpt-parameters> are associated
+   with negotiated SMTP service extensions (see section 2.2).
+
+   The third step in the procedure is the DATA command (or some
+   alternative specified in a service extension).
+
+
+
+Klensin                     Standards Track                    [Page 17]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      DATA <CRLF>
+
+   If accepted, the SMTP server returns a 354 Intermediate reply and
+   considers all succeeding lines up to but not including the end of
+   mail data indicator to be the message text.  When the end of text is
+   successfully received and stored the SMTP-receiver sends a 250 OK
+   reply.
+
+   Since the mail data is sent on the transmission channel, the end of
+   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 a "." (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 can fail at only two points in the protocol exchange:
+
+   -  If there was no MAIL, or no RCPT, command, or all such commands
+      were rejected, the server MAY return a "command out of sequence"
+      (503) or "no valid recipients" (554) reply in response to the DATA
+      command.  If one of those replies (or any other 5yz reply) is
+      received, the client MUST NOT send the message data; more
+      generally, message data MUST NOT be sent unless a 354 reply is
+      received.
+
+   -  If the verb is initially accepted and the 354 reply issued, the
+      DATA command should fail only if the mail transaction was
+      incomplete (for example, no recipients), or if resources were
+      unavailable (including, of course, the server unexpectedly
+      becoming unavailable), or if the server determines that the
+      message should be rejected for policy or other reasons.
+
+   However, in practice, some servers 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 6.  Using
+   a "550 mailbox not found" (or equivalent) reply code after the data
+   are accepted makes it difficult or impossible for the client to
+   determine which recipients failed.
+
+   When RFC 822 format [7, 32] is being used, the mail data include the
+   memo header items such as Date, Subject, To, Cc, From.  Server SMTP
+   systems SHOULD NOT reject messages based on perceived defects in the
+   RFC 822 or MIME [12] message header or message body.  In particular,
+
+
+
+
+Klensin                     Standards Track                    [Page 18]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   they MUST NOT reject messages in which the numbers of Resent-fields
+   do not match or Resent-to appears without Resent-from and/or Resent-
+   date.
+
+   Mail transaction commands MUST be used in the order discussed above.
+
+3.4 Forwarding for Address Correction or Updating
+
+   Forwarding support is most often required to consolidate and simplify
+   addresses within, or relative to, some enterprise and less frequently
+   to establish addresses to link a person's prior address with current
+   one.  Silent forwarding of messages (without server notification to
+   the sender), for security or non-disclosure purposes, is common in
+   the contemporary Internet.
+
+   In both the enterprise and the "new address" cases, information
+   hiding (and sometimes security) considerations argue against exposure
+   of the "final" address through the SMTP protocol as a side-effect of
+   the forwarding activity.  This may be especially important when the
+   final address may not even be reachable by the sender.  Consequently,
+   the "forwarding" mechanisms described in section 3.2 of RFC 821, and
+   especially the 251 (corrected destination) and 551 reply codes from
+   RCPT must be evaluated carefully by implementers and, when they are
+   available, by those configuring systems.
+
+   In particular:
+
+   *  Servers MAY forward messages when they are aware of an address
+      change.  When they do so, they MAY either provide address-updating
+      information with a 251 code, or may forward "silently" and return
+      a 250 code.  But, if a 251 code is used, they MUST NOT assume that
+      the client will actually update address information or even return
+      that information to the user.
+
+   Alternately,
+
+   *  Servers MAY reject or bounce messages when they are not
+      deliverable when addressed.  When they do so, they MAY either
+      provide address-updating information with a 551 code, or may
+      reject the message as undeliverable with a 550 code and no
+      address-specific information.  But, if a 551 code is used, they
+      MUST NOT assume that the client will actually update address
+      information or even return that information to the user.
+
+   SMTP server implementations that support the 251 and/or 551 reply
+   codes are strongly encouraged to provide configuration mechanisms so
+   that sites which conclude that they would undesirably disclose
+   information can disable or restrict their use.
+
+
+
+Klensin                     Standards Track                    [Page 19]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.5 Commands for Debugging Addresses
+
+3.5.1 Overview
+
+   SMTP provides commands to verify a user name or obtain the content of
+   a mailing list.  This is done with the VRFY and EXPN commands, which
+   have character string arguments.  Implementations SHOULD support VRFY
+   and EXPN (however, see section 3.5.2 and 7.3).
+
+   For the VRFY command, the string is a user name or a user name and
+   domain (see below).  If a normal (i.e., 250) response is returned,
+   the response MAY include the full name of the user and MUST include
+   the mailbox of the user.  It MUST be in either of the following
+   forms:
+
+      User Name <local-part@domain>
+      local-part@domain
+
+   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, any of the following are legitimate
+   response to VRFY:
+
+      553 User ambiguous
+
+   or
+
+      553- Ambiguous;  Possibilities are
+      553-Joe Smith <jsmith@foo.com>
+      553-Harry Smith <hsmith@foo.com>
+      553 Melvin Smith <dweep@foo.com>
+
+   or
+
+      553-Ambiguous;  Possibilities
+      553- <jsmith@foo.com>
+      553- <hsmith@foo.com>
+      553 <dweep@foo.com>
+
+   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, possibly
+   supplemented by extended reply codes such as those described in [34],
+   will facilitate automated translation into other languages as needed.
+   Of course, a client that was highly automated or that was operating
+   in another language than English, might choose to try to translate
+   the response, to return some other indication to the user than the
+
+
+
+
+Klensin                     Standards Track                    [Page 20]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   literal text of the reply, or to take some automated action such as
+   consulting a directory service for additional information before
+   reporting to the user.
+
+   For the EXPN command, the string identifies a mailing list, and the
+   successful (i.e., 250) multiline response MAY include the full name
+   of the users and MUST give the mailboxes on the mailing list.
+
+   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
+   containing only one mailbox.  If a request is made to apply VRFY to a
+   mailing list, a positive response MAY be given if a message so
+   addressed would be delivered to everyone on the list, otherwise an
+   error SHOULD be reported (e.g., "550 That is a mailing list, not a
+   user" or "252 Unable to verify members of mailing list").  If a
+   request is made to expand a user name, the server MAY return a
+   positive response consisting of a list containing one name, or an
+   error MAY be reported (e.g., "550 That is a user name, not a mailing
+   list").
+
+   In the case of a successful 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.
+
+   "User name" is a fuzzy term and has been used deliberately.  An
+   implementation of the VRFY or EXPN commands MUST include at least
+   recognition of local mailboxes as "user names".  However, since
+   current Internet practice often results in a single host handling
+   mail for multiple domains, hosts, especially hosts that provide this
+   functionality, SHOULD accept the "local-part@domain" form as a "user
+   name"; hosts MAY also choose to recognize other strings as "user
+   names".
+
+   The case of expanding a mailbox list requires a multiline reply, such
+   as:
+
+      C: EXPN Example-People
+      S: 250-Jon Postel <Postel@isi.edu>
+      S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
+      S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
+
+   or
+
+      C: EXPN Executive-Washroom-List
+      S: 550 Access Denied to You.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 21]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   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 are a variety
+   of file naming conventions in the Internet.  Similarly, historical
+   variations in what is returned by these commands are such that the
+   response SHOULD be interpreted very carefully, if at all, and SHOULD
+   generally only be used for diagnostic purposes.
+
+3.5.2 VRFY Normal Response
+
+   When normal (2yz or 551) responses are returned from a VRFY or EXPN
+   request, the reply normally includes the mailbox name, i.e.,
+   "<local-part@domain>", where "domain" is a fully qualified domain
+   name, MUST appear in the syntax.  In circumstances exceptional enough
+   to justify violating the intent of this specification, free-form text
+   MAY be returned.  In order to facilitate parsing by both computers
+   and people, addresses SHOULD appear in pointed brackets.  When
+   addresses, rather than free-form debugging information, are returned,
+   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 MUST be given.  Paths (explicit source routes) MUST NOT be
+   returned by VRFY or EXPN.
+
+   Server implementations SHOULD support both VRFY and 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 be listed as
+   service extensions in an EHLO response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+   A server MUST NOT return a 250 code in response to a VRFY or EXPN
+   command unless it has actually verified the address.  In particular,
+   a server MUST NOT return 250 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.  As
+   stated elsewhere, implementation (in the sense of actually validating
+   addresses and returning information) of VRFY and EXPN are strongly
+   recommended.  Hence, implementations that return 500 or 502 for VRFY
+   are not in full compliance with this specification.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 22]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   There may be circumstances where an address appears to be valid but
+   cannot reasonably be verified in real time, particularly when a
+   server is acting as a mail exchanger for another server or domain.
+   "Apparent validity" in this case would normally involve at least
+   syntax checking and might involve verification that any domains
+   specified were ones to which the host expected to be able to relay
+   mail.  In these situations, reply code 252 SHOULD be returned.  These
+   cases parallel the discussion of RCPT verification discussed in
+   section 2.1.  Similarly, the discussion in section 3.4 applies to the
+   use of reply codes 251 and 551 with VRFY (and EXPN) to indicate
+   addresses that are recognized but that would be forwarded or bounced
+   were mail received for them.  Implementations generally SHOULD be
+   more aggressive about address verification in the case of VRFY than
+   in the case of RCPT, even if it takes a little longer to do so.
+
+3.5.4 Semantics and Applications of EXPN
+
+   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, for hosts (typically with MX and CNAME DNS
+   records), for mailboxes (various types of local host aliases), and in
+   various proxying arrangements, has made it nearly impossible for
+   these strategies to work consistently, and mail systems SHOULD NOT
+   attempt them.
+
+3.6 Domains
+
+   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
+   when domain names are used in SMTP.  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 are two exceptions to the rule requiring FQDNs:
+
+   -  The domain name given in the EHLO command MUST BE either a primary
+      host name (a domain name that resolves to an A RR) or, if the host
+      has no name, an address literal as described in section 4.1.1.1.
+
+   -  The reserved mailbox name "postmaster" may be used in a RCPT
+      command without domain qualification (see section 4.1.1.3) and
+      MUST be accepted if so used.
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 23]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.7 Relaying
+
+   In general, the availability of Mail eXchanger records in the domain
+   name system [22, 27] 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.  When route information
+   is encountered, SMTP servers are also permitted to ignore the route
+   information and simply send to the final destination specified as the
+   last element in the route and SHOULD do so.  There has been an
+   invalid practice 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.  This is one
+   of several reasons why SMTP clients MUST NOT generate invalid source
+   routes or depend on serial resolution of names.
+
+   When 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.
+
+   A relay SMTP server is usually the target of a DNS MX record that
+   designates it, rather than the final delivery system.  The relay
+   server may accept or reject the task of relaying the mail in the same
+   way it accepts or rejects mail for a local user.  If it accepts the
+   task, it then becomes an SMTP client, establishes a transmission
+   channel to the next SMTP server specified in the DNS (according to
+   the rules in section 5), and sends it the mail.  If it declines to
+   relay mail to a particular address for policy reasons, a 550 response
+   SHOULD be returned.
+
+   Many mail-sending clients exist, especially in conjunction with
+   facilities that receive mail via POP3 or IMAP, that have limited
+   capability to support some of the requirements of this specification,
+   such as the ability to queue messages for subsequent delivery
+   attempts.  For these clients, it is common practice to make private
+   arrangements to send all messages to a single server for processing
+   and subsequent distribution.  SMTP, as specified here, is not ideally
+   suited for this role, and work is underway on standardized mail
+   submission protocols that might eventually supercede the current
+   practices.  In any event, because these arrangements are private and
+   fall outside the scope of this specification, they are not described
+   here.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 24]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   It is important to note that MX records can point to SMTP servers
+   which act as gateways into other environments, not just SMTP relays
+   and final delivery systems; see sections 3.8 and 5.
+
+   If an SMTP server has accepted the task of relaying the mail and
+   later finds that the destination 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
+   (see, for example, [24, 25]) 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 MUST NOT send notification
+   messages about problems transporting 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 MUST be set to null (see section
+   4.5.5 for additional discussion).  A MAIL command with a null
+   reverse-path appears as follows:
+
+      MAIL FROM:<>
+
+   As discussed in section 2.4.1, a relay SMTP has no need to inspect or
+   act upon the headers or body of the message data and MUST NOT do so
+   except to add its own "Received:" header (section 4.4) and,
+   optionally, to attempt to detect looping in the mail system (see
+   section 6.2).
+
+3.8 Mail Gatewaying
+
+   While the relay function discussed above operates within the Internet
+   SMTP transport service environment, MX records or various forms of
+   explicit routing may require that an intermediate SMTP server perform
+   a translation function between one transport service and another.  As
+   discussed in section 2.3.8, when such a system is at the boundary
+   between two transport service environments, we refer to it as a
+   "gateway" or "gateway SMTP".
+
+   Gatewaying mail between different mail environments, such as
+   different mail formats and protocols, is complex and does not easily
+   yield to standardization.  However, some general requirements may be
+   given for a gateway between the Internet and another mail
+   environment.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 25]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.8.1 Header Fields in Gatewaying
+
+   Header fields MAY be rewritten when necessary as messages are
+   gatewayed across mail environment boundaries.  This may involve
+   inspecting the message body or interpreting the local-part of the
+   destination address in spite of the prohibitions in section 2.4.1.
+
+   Other mail systems gatewayed to the Internet often use a subset of
+   RFC 822 headers or provide similar functionality with a different
+   syntax, but some of these mail systems do not have an equivalent to
+   the SMTP envelope.  Therefore, when a message leaves the Internet
+   environment, it may be necessary to fold the SMTP envelope
+   information into the message header.  A possible solution would be to
+   create new header fields to carry the envelope information (e.g.,
+   "X-SMTP-MAIL:"  and "X-SMTP-RCPT:"); however, this would require
+   changes in mail programs in foreign environments and might risk
+   disclosure of private information (see section 7.2).
+
+3.8.2 Received Lines in Gatewaying
+
+   When forwarding a message into or out of the Internet environment, a
+   gateway MUST prepend a Received: line, but it MUST NOT alter in any
+   way a Received: line that is already in the header.
+
+   "Received:" fields of messages originating from other environments
+   may not conform exactly to this specification.  However, the most
+   important use of Received: lines is for debugging mail faults, and
+   this debugging can be severely hampered by well-meaning gateways that
+   try to "fix" a Received: line.  As another consequence of trace
+   fields arising in non-SMTP environments, receiving systems MUST NOT
+   reject mail based on the format of a trace field and SHOULD be
+   extremely robust in the light of unexpected information or formats in
+   those fields.
+
+   The gateway SHOULD indicate the environment and protocol in the "via"
+   clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+   From the Internet side, the gateway SHOULD accept all valid address
+   formats in SMTP commands and in RFC 822 headers, and all valid RFC
+   822 messages.  Addresses and headers generated by gateways MUST
+   conform to applicable Internet standards (including this one and RFC
+   822).  Gateways are, of course, subject to the same rules for
+   handling source routes as those described for other SMTP systems in
+   section 3.3.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 26]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.8.4 Other Header Fields in Gatewaying
+
+   The gateway MUST ensure that all header fields of a message that it
+   forwards into the Internet mail environment meet the requirements for
+   Internet mail.  In particular, all addresses in "From:", "To:",
+   "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC
+   822 syntax, MUST reference only fully-qualified domain names, and
+   MUST be effective and useful for sending replies.  The translation
+   algorithm used to convert mail from the Internet protocols to another
+   environment's protocol SHOULD ensure that error messages from the
+   foreign mail environment are delivered to the return path from the
+   SMTP envelope, not to the sender listed in the "From:" field (or
+   other fields) of the RFC 822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+   Similarly, when forwarding a message from another environment into
+   the Internet, the gateway SHOULD set the envelope return path in
+   accordance with an error message return address, if supplied by the
+   foreign environment.  If the foreign environment has no equivalent
+   concept, the gateway must select and use a best approximation, with
+   the message originator's address as the default of last resort.
+
+3.9 Terminating Sessions and Connections
+
+   An SMTP connection is terminated when the client sends a QUIT
+   command.  The server responds with a positive reply code, after which
+   it closes the connection.
+
+   An SMTP server MUST NOT intentionally close the connection except:
+
+   -  After receiving a QUIT command and responding with a 221 reply.
+
+   -  After detecting the need to shut down the SMTP service and
+      returning a 421 response code.  This response code can be issued
+      after the server receives any command or, if necessary,
+      asynchronously from command receipt (on the assumption that the
+      client will receive it after the next command is issued).
+
+   In particular, a server that closes connections in response to
+   commands that are not understood is in violation of this
+   specification.  Servers are expected to be tolerant of unknown
+   commands, issuing a 500 reply and awaiting further instructions from
+   the client.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 27]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   An SMTP server which is forcibly shut down via external means SHOULD
+   attempt to send a line containing a 421 response code to the SMTP
+   client before exiting.  The SMTP client will normally read the 421
+   response code after sending its next command.
+
+   SMTP clients that experience a connection close, reset, or other
+   communications failure due to circumstances not under their control
+   (in violation of the intent of this specification but sometimes
+   unavoidable) SHOULD, to maintain the robustness of the mail system,
+   treat the mail transaction as if a 451 response had been received and
+   act accordingly.
+
+3.10 Mailing Lists and Aliases
+
+   An SMTP-capable host SHOULD support both the alias and the list
+   models of address expansion for multiple delivery.  When a message is
+   delivered or forwarded to each address of an expanded list form, the
+   return address in the envelope ("MAIL FROM:") MUST be changed to be
+   the address of a person or other entity who administers the list.
+   However, in this case, the message header [32] MUST be left
+   unchanged; in particular, the "From" field of the message header is
+   unaffected.
+
+   An important mail facility is a mechanism for multi-destination
+   delivery of a single message, by transforming (or "expanding" or
+   "exploding") a pseudo-mailbox address into a list of destination
+   mailbox addresses.  When a message is sent to such a pseudo-mailbox
+   (sometimes called an "exploder"), copies are forwarded or
+   redistributed to each mailbox in the expanded list.  Servers SHOULD
+   simply utilize the addresses on the list; application of heuristics
+   or other matching rules to eliminate some addresses, such as that of
+   the originator, is strongly discouraged.  We classify such a pseudo-
+   mailbox as an "alias" or a "list", depending upon the expansion
+   rules.
+
+3.10.1 Alias
+
+   To expand an alias, the recipient mailer simply replaces the pseudo-
+   mailbox address in the envelope with each of the expanded addresses
+   in turn; the rest of the envelope and the message body are left
+   unchanged.  The message is then delivered or forwarded to each
+   expanded address.
+
+3.10.2 List
+
+   A mailing list may be said to operate by "redistribution" rather than
+   by "forwarding".  To expand a list, the recipient mailer replaces the
+   pseudo-mailbox address in the envelope with all of the expanded
+
+
+
+Klensin                     Standards Track                    [Page 28]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   addresses.  The return address in the envelope is changed so that all
+   error messages generated by the final deliveries will be returned to
+   a list administrator, not to the message originator, who generally
+   has no control over the contents of the list and will typically find
+   error messages annoying.
+
+4. The SMTP Specifications
+
+4.1 SMTP Commands
+
+4.1.1 Command Semantics and Syntax
+
+   The SMTP commands define the mail transfer or the mail system
+   function requested by the user.  SMTP commands are character strings
+   terminated by <CRLF>.  The commands themselves are alphabetic
+   characters terminated by <SP> if parameters follow and <CRLF>
+   otherwise.  (In the interest of improved interoperability, SMTP
+   receivers are encouraged to tolerate trailing white space before the
+   terminating <CRLF>.)  The syntax of the local part of a mailbox must
+   conform to receiver site conventions and the syntax specified in
+   section 4.1.2.  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.
+
+   Several commands (RSET, DATA, QUIT) are specified as not permitting
+   parameters.  In the absence of specific extensions offered by the
+   server and accepted by the client, clients MUST NOT send such
+   parameters and servers SHOULD reject commands containing them as
+   having invalid syntax.
+
+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 fully-qualified domain name
+   of the SMTP client if one is available.  In situations in which the
+   SMTP client system does not have a meaningful domain name (e.g., when
+   its address is dynamically allocated and no reverse mapping record is
+
+
+
+Klensin                     Standards Track                    [Page 29]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   available), the client SHOULD send an address literal (see section
+   4.1.3), optionally followed by information that will help to identify
+   the client system.  y 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, in violation of this specification,
+   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, and servers MUST
+   support the HELO command and reply properly to it.  In any event, a
+   client MUST issue HELO or EHLO before starting a mail transaction.
+
+   These commands, and a "250 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.
+
+   Syntax:
+
+      ehlo            = "EHLO" SP Domain CRLF
+      helo            = "HELO" SP Domain CRLF
+
+   Normally, the response to EHLO will be a multiline reply.  Each line
+   of the response contains a keyword and, optionally, one or more
+   parameters.  Following the normal syntax for multiline replies, these
+   keyworks follow the code (250) and a hyphen for all but the last
+   line, and the code and a space for the last line.  The syntax for a
+   positive response, using the ABNF notation and terminal symbols of
+   [8], is:
+
+      ehlo-ok-rsp  =    ( "250"    domain [ SP ehlo-greet ] CRLF )
+                   / (    "250-"   domain [ SP ehlo-greet ] CRLF
+                       *( "250-"   ehlo-line                CRLF )
+                          "250"    SP ehlo-line             CRLF  )
+
+      ehlo-greet   = 1*(%d0-9 / %d11-12 / %d14-127)
+                   ; string of any characters other than CR or LF
+
+      ehlo-line    = ehlo-keyword *( SP ehlo-param )
+
+      ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                   ; additional syntax of ehlo-params depends on
+                   ; ehlo-keyword
+
+
+
+
+Klensin                     Standards Track                    [Page 30]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      ehlo-param   = 1*(%d33-127)
+                   ; any CHAR excluding <SP> and all
+                   ; control characters (US-ASCII 0-31 inclusive)
+
+   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 and section 2.4.1.
+
+4.1.1.2 MAIL (MAIL)
+
+   This command is used to initiate a mail transaction in which the mail
+   data is delivered to an SMTP server which may, in turn, deliver it to
+   one or more mailboxes or pass it on to another system (possibly using
+   SMTP).  The argument field contains a reverse-path and may contain
+   optional parameters.  In general, the MAIL command may be sent only
+   when no mail transaction is in progress, see section 4.1.4.
+
+   The reverse-path consists of the sender mailbox.  Historically, that
+   mailbox might optionally have been preceded by a list of hosts, but
+   that behavior is now deprecated (see appendix C).  In some types of
+   reporting messages for which a reply is likely to cause a mail loop
+   (for example, mail delivery and nondelivery notifications), the
+   reverse-path may be null (see section 3.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)
+                       [SP Mail-parameters] CRLF
+
+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 argument field contains a forward-path and may contain
+   optional parameters.
+
+   The forward-path normally consists of the required destination
+   mailbox.  Sending systems SHOULD not generate the optional list of
+   hosts known as a source route.  Receiving systems MUST recognize
+
+
+
+
+Klensin                     Standards Track                    [Page 31]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   source route syntax but SHOULD strip off the source route
+   specification and utilize the domain name associated with the mailbox
+   as if the source route had not been provided.
+
+   Similarly, relay hosts SHOULD strip or ignore source routes, and
+   names MUST NOT be copied into 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 xyz.com with envelope
+   commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+   will normally be sent directly on to host d.bar.org with envelope
+   commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<userc@d.bar.org>
+
+   As provided in appendix C, xyz.com MAY also choose to relay the
+   message to hosta.int, using the envelope commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+   or to jkl.org, using the envelope commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@jkl.org:userc@d.bar.org>
+
+   Of course, since hosts are not required to relay mail at all, xyz.com
+   may also reject the message entirely when the RCPT command is
+   received, using a 550 code (since this is a "policy reason").
+
+   If service extensions were negotiated, the RCPT command may also
+   carry parameters associated with a particular service extension
+   offered by the server.  The client MUST NOT transmit parameters other
+   than those associated with a service extension offered by the server
+   in its EHLO response.
+
+Syntax:
+   "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
+                    [SP Rcpt-parameters] CRLF
+
+
+
+
+
+Klensin                     Standards Track                    [Page 32]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+4.1.1.4 DATA (DATA)
+
+   The receiver normally sends a 354 response to DATA, and then treats
+   the lines (strings ending in <CRLF> sequences, as described in
+   section 2.3.7) following the command as mail data from the sender.
+   This command causes the mail data to be appended to the mail data
+   buffer.  The mail data may contain any of the 128 ASCII character
+   codes, although experience has indicated that use of control
+   characters other than SP, HT, CR, and LF may cause problems and
+   SHOULD be avoided when possible.
+
+   The mail data is terminated by a line containing only a period, that
+   is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This
+   is the end of mail data indication.  Note that the first <CRLF> of
+   this terminating sequence is also the <CRLF> that ends the final line
+   of the data (message text) or, if there was no data, ends the DATA
+   command itself.  An extra <CRLF> MUST NOT be added, as that would
+   cause an empty line to be added to the message.  The only exception
+   to this rule would arise if the message body were passed to the
+   originating SMTP-sender with a final "line" that did not end in
+   <CRLF>; in that case, the originating SMTP system MUST either reject
+   the message as invalid or add <CRLF> in order to have the receiving
+   SMTP server recognize the "end of data" condition.
+
+   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 the server to
+   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 the
+   receiver MUST send a failure reply.  The SMTP model does not allow
+   for partial failures at this point: either the message is accepted by
+   the server for delivery and a positive response is returned or it is
+   not accepted and a failure reply is returned.  In sending a positive
+   completion reply to the end of data indication, the receiver takes
+   full responsibility for the message (see section 6.1).  Errors that
+   are diagnosed subsequently MUST be reported in a mail message, as
+   discussed in section 4.4.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 33]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   When the SMTP server accepts a message either for relaying or for
+   final delivery, it inserts a trace record (also referred to
+   interchangeably 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, the identity of the host that received
+   the message (and 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.
+
+   Additional discussion about the operation of the DATA command appears
+   in section 3.3.
+
+   Syntax:
+      "DATA" CRLF
+
+4.1.1.5 RESET (RSET)
+
+   This command specifies that the current mail transaction will be
+   aborted.  Any stored sender, recipients, and mail data MUST be
+   discarded, and all buffers and state tables cleared.  The receiver
+   MUST send a "250 OK" reply to a RSET command with no arguments.  A
+   reset command may be issued by the client at any time.  It is
+   effectively equivalent to a NOOP (i.e., if has no effect) if issued
+   immediately after EHLO, before EHLO is issued in the session, after
+   an end-of-data indicator has been sent and acknowledged, or
+   immediately before a QUIT.  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).
+
+   Since EHLO implies some additional processing and response by the
+   server, RSET will normally be more efficient than reissuing that
+   command, even though the formal semantics are the same.
+
+   There are circumstances, contrary to the intent of this
+   specification, in which an SMTP server may receive an indication that
+   the underlying TCP connection has been closed or reset.  To preserve
+   the robustness of the mail system, SMTP servers SHOULD be prepared
+   for this condition and SHOULD treat it as if a QUIT had been received
+   before the connection disappeared.
+
+   Syntax:
+      "RSET" CRLF
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 34]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+4.1.1.6 VERIFY (VRFY)
+
+   This command asks the receiver to confirm that the argument
+   identifies a user or mailbox.  If it is a user name, information is
+   returned as specified in section 3.5.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer.
+
+   Syntax:
+      "VRFY" SP String CRLF
+
+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.  If the command is successful, a reply is returned
+   containing information as described in section 3.5.  This reply will
+   have multiple lines except in the trivial case of a one-member list.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer and may be issued at any time.
+
+   Syntax:
+      "EXPN" SP String CRLF
+
+4.1.1.8 HELP (HELP)
+
+   This command causes the server to send helpful information to the
+   client.  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 the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer and may be issued at any time.
+
+   SMTP servers SHOULD support HELP without arguments and MAY support it
+   with arguments.
+
+   Syntax:
+      "HELP" [ SP String ] CRLF
+
+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.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 35]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer and may be issued at any time.
+   If a parameter string is specified, servers SHOULD ignore it.
+
+   Syntax:
+      "NOOP" [ SP String ] CRLF
+
+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 sends a QUIT command and SHOULD wait until it
+   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 cancel any
+   pending transaction, but not undo any previously completed
+   transaction, and generally MUST act as if the command or transaction
+   in progress had received a temporary error (i.e., a 4yz response).
+
+   The QUIT command may be issued at any time.
+
+   Syntax:
+      "QUIT" CRLF
+
+4.1.2 Command Argument Syntax
+
+   The syntax of the argument fields of the above commands (using the
+   syntax specified in [8] where applicable) is given below.  Some of
+   the productions given below are used only in conjunction with source
+   routes as described in appendix C.  Terminals not defined in this
+   document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in
+   the "core" syntax [8 (section 6)] or in the message format syntax
+   [32].
+
+      Reverse-path = Path
+      Forward-path = Path
+      Path = "<" [ A-d-l ":" ] Mailbox ">"
+      A-d-l = At-domain *( "," A-d-l )
+            ; Note that this form, the so-called "source route",
+            ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
+            ; ignored.
+      At-domain = "@" domain
+      Mail-parameters = esmtp-param *(SP esmtp-param)
+      Rcpt-parameters = esmtp-param *(SP esmtp-param)
+
+
+
+Klensin                     Standards Track                    [Page 36]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      esmtp-param     = esmtp-keyword ["=" esmtp-value]
+      esmtp-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+      esmtp-value     = 1*(%d33-60 / %d62-127)
+            ; any CHAR excluding "=", SP, and control characters
+      Keyword  = Ldh-str
+      Argument = Atom
+      Domain = (sub-domain 1*("." sub-domain)) / address-literal
+      sub-domain = Let-dig [Ldh-str]
+
+      address-literal = "[" IPv4-address-literal /
+                            IPv6-address-literal /
+                            General-address-literal "]"
+            ; See section 4.1.3
+
+      Mailbox = Local-part "@" Domain
+
+      Local-part = Dot-string / Quoted-string
+            ; MAY be case-sensitive
+
+      Dot-string = Atom *("." Atom)
+
+      Atom = 1*atext
+
+      Quoted-string = DQUOTE *qcontent DQUOTE
+
+      String = Atom / Quoted-string
+
+   While the above definition for Local-part 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.  For any purposes that require generating or comparing
+   Local-parts (e.g., to specific mailbox names), all quoted forms MUST
+   be treated as equivalent and the sending system SHOULD transmit the
+   form that uses the minimum quoting possible.
+
+   Systems MUST NOT define mailboxes in such a way as to require the use
+   in SMTP 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 or RCPT commands or other
+   commands that require mailbox names.
+
+   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" indicates a
+   single nine character user field with the comma being the fourth
+   character of the field.
+
+
+
+
+Klensin                     Standards Track                    [Page 37]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   To promote interoperability and consistent with long-standing
+   guidance about conservative use of the DNS in naming and applications
+   (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]),
+   characters outside the set of alphas, digits, and hyphen MUST NOT
+   appear in domain name labels for SMTP clients or servers.  In
+   particular, the underscore character is not permitted.  SMTP servers
+   that receive a command in which invalid character codes have been
+   employed, and for which there are no other reasons for rejection,
+   MUST reject that command with a 501 response.
+
+4.1.3 Address Literals
+
+   Sometimes a host is not known to the domain name system and
+   communication (and, in particular, communication to report and repair
+   the error) is blocked.  To bypass this barrier a special literal form
+   of the address is allowed as an alternative to a domain name.  For
+   IPv4 addresses, this form uses four small decimal integers separated
+   by dots and enclosed by brackets such as [123.255.37.2], which
+   indicates an (IPv4) Internet Address in sequence-of-octets form.  For
+   IPv6 and other forms of addressing that might eventually be
+   standardized, the form consists of a standardized "tag" that
+   identifies the address syntax, a colon, and the address itself, in a
+   format specified as part of the IPv6 standards [17].
+
+   Specifically:
+
+      IPv4-address-literal = Snum 3("." Snum)
+      IPv6-address-literal = "IPv6:" IPv6-addr
+      General-address-literal = Standardized-tag ":" 1*dcontent
+      Standardized-tag = Ldh-str
+            ; MUST be specified in a standards-track RFC
+            ; and registered with IANA
+
+      Snum = 1*3DIGIT  ; representing a decimal integer
+            ; value in the range 0 through 255
+      Let-dig = ALPHA / DIGIT
+      Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
+
+      IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
+      IPv6-hex  = 1*4HEXDIG
+      IPv6-full = IPv6-hex 7(":" IPv6-hex)
+      IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
+                 IPv6-hex)]
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 6 groups in addition to the "::" may be
+            ; present
+      IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
+      IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
+
+
+
+Klensin                     Standards Track                    [Page 38]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+                   [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 4 groups in addition to the "::" and
+            ; IPv4-address-literal may be present
+
+4.1.4 Order of Commands
+
+   There are restrictions on the order in which these commands may be
+   used.
+
+   A session that will contain mail transactions MUST first be
+   initialized by the use of the EHLO command.  An SMTP server SHOULD
+   accept commands for non-mail transactions (e.g., VRFY or EXPN)
+   without this initialization.
+
+   An EHLO command MAY be issued by a client later in the session.  If
+   it is issued after the session begins, the SMTP server MUST clear all
+   buffers and reset the state exactly as if a RSET command had been
+   issued.  In other words, the sequence of RSET followed immediately by
+   EHLO is redundant, but not harmful other than in the performance cost
+   of executing unnecessary commands.
+
+   If the EHLO command is 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
+   that it was in before the EHLO was received.
+
+   The SMTP client MUST, if possible, ensure that the domain parameter
+   to the EHLO command is a valid principal host name (not a CNAME or MX
+   name) for its host.  If this is not possible (e.g., when the client's
+   address is dynamically assigned and the client does not have an
+   obvious name), an address literal SHOULD be substituted for the
+   domain name and supplemental information provided that will assist in
+   identifying the client.
+
+   An SMTP server MAY verify that the domain name parameter in the EHLO
+   command actually corresponds to the IP address of the client.
+   However, the server MUST NOT refuse to accept a message for this
+   reason if the verification fails: the information about verification
+   failure is for logging and tracing only.
+
+   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 (that is, not return a 503
+   code) even if no EHLO command has yet been received; clients SHOULD
+   open a session with EHLO before sending these commands.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 39]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   If these rules are followed, the example in RFC 821 that shows "550
+   access denied to you" in response to an EXPN command is incorrect
+   unless an EHLO command precedes the EXPN or the denial of access is
+   based on the client's IP address or other authentication or
+   authorization-determining mechanisms.
+
+   The MAIL command (or the obsolete SEND, SOML, or SAML commands)
+   begins a mail transaction.  Once started, a mail transaction consists
+   of a transaction beginning command, one or more RCPT commands, and a
+   DATA command, in that order.  A mail transaction may be aborted by
+   the RSET (or a new EHLO) command.  There may be zero or more
+   transactions in a session.  MAIL (or SEND, SOML, or SAML) MUST NOT be
+   sent if a mail transaction is already open, i.e., it should be sent
+   only if no mail transaction had been started in the session, or it
+   the previous one successfully concluded with a successful DATA
+   command, or if the previous one was aborted with a RSET.
+
+   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 cannot be used at any other time in a session, but SHOULD be
+   used by the client SMTP to request connection closure, even when no
+   session opening command was sent and accepted.
+
+4.1.5 Private-use Commands
+
+   As specified in section 2.2.2, commands starting in "X" may be used
+   by bilateral agreement between the client (sending) and server
+   (receiving) SMTP agents.  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 conform to the requirements of section 2.2.2.
+
+4.2 SMTP Replies
+
+   Replies to SMTP commands serve 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.
+
+
+
+
+Klensin                     Standards Track                    [Page 40]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The details of the command-reply sequence are described in section
+   4.3.
+
+   An SMTP reply consists of a three digit number (transmitted as three
+   numeric characters) followed by some text unless specified otherwise
+   in this document.  The number is for use by automata to determine
+   what state to enter next; the text is for the human user.  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.  Exceptions are as noted elsewhere in this
+   document.  In particular, the 220, 221, 251, 421, and 551 reply codes
+   are associated with message text that must be parsed and interpreted
+   by machines.  In the general case, 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 section 4.2.1.  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 section 4.2.1).  Since, in violation of this
+   specification, the text is sometimes not sent, clients which do not
+   receive it SHOULD be prepared to process the code alone (with or
+   without a trailing space character).  Only the EHLO, EXPN, and HELP
+   commands are expected to result in multiline replies in normal
+   circumstances, however, multiline replies are allowed for any
+   command.
+
+   In ABNF, server responses are:
+
+      Greeting = "220 " Domain [ SP text ] CRLF
+      Reply-line = Reply-code [ SP text ] CRLF
+
+   where "Greeting" appears only in the 220 response that announces that
+   the server is opening its part of the connection.
+
+   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.
+
+   An SMTP client MUST determine its actions only by the reply code, not
+   by the text (except for the "change of address" 251 and 551 and, if
+   necessary, 220, 221, and 421 replies); in the general case, any text,
+   including no text at all (although senders SHOULD NOT send bare
+   codes), MUST be acceptable.  The space (blank) following the reply
+   code is considered part of the text.  Whenever possible, a receiver-
+   SMTP SHOULD test the first digit (severity indication) of the reply
+   code.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 41]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The list of codes that appears below MUST NOT be construed as
+   permanent.  While the addition of new codes should be a rare and
+   significant activity, with supplemental information in the textual
+   part of the response being preferred, new codes may be added as the
+   result of new Standards or Standards-track specifications.
+   Consequently, a sender-SMTP MUST be prepared to handle codes not
+   specified in this document and MUST do so by interpreting the first
+   digit only.
+
+4.2.1 Reply Code Severities and Theory
+
+   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, or one that receives an unexpected
+   code, will be able to determine its next action (proceed as planned,
+   redo, retrench, etc.) by 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.  The third digit and any supplemental information that may be
+   present is reserved 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: unextended SMTP
+      does not have any commands that allow this type of reply, and so
+      does not have 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 (i.e.,
+      in DATA).
+
+   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
+
+
+
+Klensin                     Standards Track                    [Page 42]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      sender-SMTP agents) 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
+      whether a reply fits into the 4yz or the 5yz category (see below)
+      is that replies are 4yz if they can be successful if repeated
+      without any change in command form or in properties of the sender
+      or receiver (that is, 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 do not 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.
+
+   x4z   Unspecified.
+
+   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.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 43]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   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 reply is 502 when the command requests an unimplemented
+   non-site-specific action.  A refinement of that is the 504 reply for
+   a command that is implemented, but that requests an unimplemented
+   parameter.
+
+   The reply text may be longer than a single line; in these cases the
+   complete text must be marked so the SMTP client knows when it can
+   stop reading the reply.  This requires a special format to indicate a
+   multiple line reply.
+
+   The format for multiline replies requires that every line, except the
+   last, begin with the reply code, followed immediately by a hyphen,
+   "-" (also known as minus), followed by text.  The last line will
+   begin with the reply code, followed immediately by <SP>, optionally
+   some text, and <CRLF>.  As noted above, servers SHOULD send the <SP>
+   if subsequent text is not sent, but clients MUST be prepared for it
+   to be omitted.
+
+   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 a line
+   beginning with the reply code followed by <SP> or <CRLF> and ignore
+   all preceding lines.  In a few cases, there is important data for the
+   client in the reply "text".  The client will be able to identify
+   these cases from the current context.
+
+4.2.2 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.4)
+      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)
+
+
+
+
+Klensin                     Standards Track                    [Page 44]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      220 <domain> Service ready
+      221 <domain> Service closing transmission channel
+      421 <domain> Service not available, closing transmission channel
+         (This may be a reply to any command if the service knows it
+         must shut down)
+
+      250 Requested mail action okay, completed
+      251 User not local; will forward to <forward-path>
+         (See section 3.4)
+      252 Cannot VRFY user, but will accept message and attempt
+          delivery
+         (See section 3.5.3)
+      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, or command rejected
+         for policy reasons)
+      451 Requested action aborted: error in processing
+      551 User not local; please try <forward-path>
+         (See section 3.4)
+      452 Requested action not taken: insufficient system storage
+      552 Requested mail action aborted: exceeded storage allocation
+      553 Requested action not taken: mailbox name not allowed
+         (e.g., mailbox syntax incorrect)
+      354 Start mail input; end with <CRLF>.<CRLF>
+      554 Transaction failed (Or, in the case of a connection-opening
+          response, "No SMTP service here")
+
+4.2.3  Reply Codes in Numeric Order
+
+      211 System status, or system help reply
+      214 Help message
+         (Information on how to use the receiver or the meaning of a
+         particular non-standard command; this reply is useful only
+         to the human user)
+      220 <domain> Service ready
+      221 <domain> Service closing transmission channel
+      250 Requested mail action okay, completed
+      251 User not local; will forward to <forward-path>
+         (See section 3.4)
+      252 Cannot VRFY user, but will accept message and attempt
+         delivery
+         (See section 3.5.3)
+
+      354 Start mail input; end with <CRLF>.<CRLF>
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 45]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      421 <domain> Service not available, closing transmission channel
+         (This may be a reply to any command if the service knows it
+         must shut down)
+      450 Requested mail action not taken: mailbox unavailable
+         (e.g., mailbox busy)
+      451 Requested action aborted: local error in processing
+      452 Requested action not taken: insufficient system storage
+      500 Syntax error, command unrecognized
+         (This may include errors such as command line too long)
+      501 Syntax error in parameters or arguments
+      502 Command not implemented (see section 4.2.4)
+      503 Bad sequence of commands
+      504 Command parameter not implemented
+      550 Requested action not taken: mailbox unavailable
+         (e.g., mailbox not found, no access, or command rejected
+         for policy reasons)
+      551 User not local; please try <forward-path>
+         (See section 3.4)
+      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  (Or, in the case of a connection-opening
+          response, "No SMTP service here")
+
+4.2.4 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.5 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
+   responsibility 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 section 4.5.4.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 46]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   -  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 command).
+
+   When an SMTP server returns a permanent error status (5yz) code after
+   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+   any subsequent attempt to deliver that message.  The SMTP client
+   retains responsibility for delivery of that message and may either
+   return it to the user or requeue it for a subsequent attempt (see
+   section 4.5.4.1).
+
+   The user who originated the message SHOULD be able to interpret the
+   return of a transient failure status (by mail message or otherwise)
+   as a non-delivery indication, just as a permanent failure would be
+   interpreted.  I.e., if the client SMTP successfully handles these
+   conditions, the user will not receive such a reply.
+
+   When an SMTP server returns a permanent error status (5yz) code after
+   the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
+   any subsequent attempt to deliver the message.  As with temporary
+   error status codes, the SMTP client retains responsibility for the
+   message, but SHOULD not again attempt delivery to the same server
+   without user review and intervention of the message.
+
+4.3 Sequencing of Commands and Replies
+
+4.3.1 Sequencing Overview
+
+   The communication between the sender and receiver is 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 (the
+   fully-qualified primary domain name) of the server host as the first
+   word following the reply code.  Sometimes the host will have no
+   meaningful name.  See 4.1.3 for a discussion of alternatives in these
+   situations.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 47]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   For example,
+
+      220 ISIF.USC.EDU Service ready
+   or
+      220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+   or
+      220 [10.0.0.1] Clueless host service ready
+
+   The table below lists alternative success and failure replies for
+   each command.  These SHOULD 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.
+
+4.3.2 Command-Reply Sequences
+
+   Each command is listed with its usual possible replies.  The prefixes
+   used before the possible replies are "I" for intermediate, "S" for
+   success, and "E" for error.  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.
+   Unless extended using the mechanisms described in section 2.2, 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.
+
+   These sequencing rules and, in principle, the codes themselves, can
+   be extended or modified by SMTP extensions offered by the server and
+   accepted (requested) by the client.
+
+   In addition to the codes listed below, any SMTP command can return
+   any of the following codes if the corresponding unusual circumstances
+   are encountered:
+
+   500  For the "command line too long" case or if the command name was
+      not recognized.  Note that producing a "command not recognized"
+      error in response to the required subset of these commands is a
+      violation of this specification.
+
+   501  Syntax error in command or arguments.  In order to provide for
+      future extensions, commands that are specified in this document as
+      not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
+      message if arguments are supplied in the absence of EHLO-
+      advertised extensions.
+
+   421  Service shutting down and closing transmission channel
+
+
+
+Klensin                     Standards Track                    [Page 48]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Specific sequences are:
+
+   CONNECTION ESTABLISHMENT
+      S: 220
+      E: 554
+   EHLO or HELO
+      S: 250
+      E: 504, 550
+   MAIL
+      S: 250
+      E: 552, 451, 452, 550, 553, 503
+   RCPT
+      S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
+      E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+   DATA
+      I: 354 -> data -> S: 250
+                        E: 552, 554, 451, 452
+      E: 451, 554, 503
+   RSET
+      S: 250
+   VRFY
+      S: 250, 251, 252
+      E: 550, 551, 553, 502, 504
+   EXPN
+      S: 250, 252
+      E: 550, 500, 502, 504
+   HELP
+      S: 211, 214
+      E: 502, 504
+   NOOP
+      S: 250
+   QUIT
+      S: 221
+
+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 content, as discussed in
+   section 4.1.1.4.
+
+   This line MUST be structured as follows:
+
+   -  The FROM field, which MUST be supplied in an SMTP environment,
+      SHOULD contain both (1) the name of the source host as presented
+      in the EHLO command and (2) an address literal containing the IP
+      address of the source, determined from the TCP connection.
+
+
+
+
+Klensin                     Standards Track                    [Page 49]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   -  The ID field MAY contain an "@" as suggested in RFC 822, but this
+      is not required.
+
+   -  The FOR field MAY contain a list of <path> entries when multiple
+      RCPT commands have been given.  This may raise some security
+      issues and is usually not desirable; see section 7.2.
+
+   An Internet mail program MUST NOT change a Received: line that was
+   previously added to the message header.  SMTP servers MUST prepend
+   Received lines to messages; they MUST NOT change the order of
+   existing lines or insert Received lines in any other location.
+
+   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.  Local time
+   (with an offset) is preferred to UT when feasible.  This formulation
+   allows slightly more information about local circumstances to be
+   specified.  If UT is needed, the receiver need merely do some simple
+   arithmetic to convert the values.  Use of UT loses information about
+   the time zone-location of the server.  If it is desired to supply a
+   time zone name, it SHOULD be included in a comment.
+
+   When the delivery SMTP server makes the "final delivery" of a
+   message, it inserts a return-path line at the beginning of the mail
+   data.  This use of return-path is required; mail systems MUST support
+   it.  The return-path line preserves the information in the <reverse-
+   path> from the MAIL command.  Here, final delivery means the message
+   has left the SMTP environment.  Normally, this would mean it had been
+   delivered to the destination user or an associated mail drop, 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 to be different
+   from the actual sender's mailbox, for example, if error responses are
+   to be delivered to a special error handling mailbox rather than to
+   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 text above implies 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 headers and body [32].
+
+   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.  Consequently,
+
+
+
+
+Klensin                     Standards Track                    [Page 50]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   any further (forwarding, gateway, or relay) systems MAY remove the
+   return path and rebuild the MAIL 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.  SMTP servers performing a
+   relay function MUST NOT inspect the message data, and especially not
+   to the extent needed to determine if Return-path headers are present.
+   SMTP servers making final delivery MAY remove Return-path headers
+   before adding their own.
+
+   The primary purpose of the Return-path is to designate the address to
+   which messages indicating non-delivery or other mail system failures
+   are to be sent.  For this to be unambiguous, exactly one return path
+   SHOULD be present when the message is delivered.  Systems using RFC
+   822 syntax with non-SMTP transports SHOULD designate an unambiguous
+   address, associated with the transport envelope, to which error
+   reports (e.g., non-delivery messages) should be sent.
+
+   Historical note: Text in RFC 822 that appears to contradict the use
+   of the Return-path header (or the envelope reverse path address from
+   the MAIL command) as the destination for error messages is not
+   applicable on the Internet.  The reverse path address (as copied into
+   the Return-path) MUST be used as the target of any mail containing
+   delivery error messages.
+
+   In particular:
+
+   -  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.
+
+   -  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 reverse
+      path argument to the MAIL command in the SMTP envelope.
+
+   The server must give special treatment to cases in which the
+   processing following the end of mail data indication is only
+   partially successful.  This could happen if, after accepting several
+   recipients and the mail data, the SMTP server finds that the mail
+   data could be successfully delivered to some, but not all, of the
+   recipients.  In such cases, the response to the DATA command MUST be
+   an OK reply.  However, the SMTP server MUST compose and send an
+   "undeliverable mail" notification message to the originator of the
+   message.
+
+
+
+Klensin                     Standards Track                    [Page 51]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   A single notification listing all of the failed recipients or
+   separate notification messages MUST be sent for each failed
+   recipient.  For economy of processing by the sender, the former is
+   preferred when possible.  All undeliverable mail notification
+   messages are sent using the MAIL command (even if they result from
+   processing the obsolete SEND, SOML, or SAML commands) and use a null
+   return path as discussed in section 3.7.
+
+   The time stamp line and the return path line are formally defined as
+   follows:
+
+Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+
+Time-stamp-line = "Received:" FWS Stamp <CRLF>
+
+Stamp = From-domain By-domain Opt-info ";"  FWS date-time
+
+      ; where "date-time" is as defined in [32]
+      ; but the "obs-" forms, especially two-digit
+      ; years, are prohibited in SMTP and MUST NOT be used.
+
+From-domain = "FROM" FWS Extended-Domain CFWS
+
+By-domain = "BY" FWS Extended-Domain CFWS
+
+Extended-Domain = Domain /
+           ( Domain FWS "(" TCP-info ")" ) /
+           ( Address-literal FWS "(" TCP-info ")" )
+
+TCP-info = Address-literal / ( Domain FWS Address-literal )
+      ; Information derived by server from TCP connection
+      ; not client EHLO.
+
+Opt-info = [Via] [With] [ID] [For]
+
+Via = "VIA" FWS Link CFWS
+
+With = "WITH" FWS Protocol CFWS
+
+ID = "ID" FWS String / msg-id CFWS
+
+For = "FOR" FWS 1*( Path / Mailbox ) CFWS
+
+Link = "TCP" / Addtl-Link
+Addtl-Link = Atom
+      ; Additional standard names for links are registered with the
+         ; Internet Assigned Numbers Authority (IANA).  "Via" is
+         ; primarily of value with non-Internet transports.  SMTP
+
+
+
+Klensin                     Standards Track                    [Page 52]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+         ; servers SHOULD NOT use unregistered names.
+Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+Attdl-Protocol = Atom
+      ; Additional standard names for protocols are registered with the
+         ; Internet Assigned Numbers Authority (IANA).  SMTP servers
+         ; SHOULD NOT use unregistered names.
+
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+   In order to make SMTP workable, the following minimum implementation
+   is required for all receivers.  The following commands MUST be
+   supported to conform to this specification:
+
+      EHLO
+      HELO
+      MAIL
+      RCPT
+      DATA
+      RSET
+      NOOP
+      QUIT
+      VRFY
+
+   Any system that includes an SMTP server supporting mail relaying or
+   delivery MUST support the reserved mailbox "postmaster" as a case-
+   insensitive local name.  This postmaster address is not strictly
+   necessary if the server always returns 554 on connection opening (as
+   described in section 3.1).  The requirement to accept mail for
+   postmaster implies that RCPT commands which specify a mailbox for
+   postmaster at any of the domains for which the SMTP server provides
+   mail service, as well as the special case of "RCPT TO:<Postmaster>"
+   (with no domain specification), MUST be supported.
+
+   SMTP systems are expected to make every reasonable effort to accept
+   mail directed to Postmaster from any other system on the Internet.
+   In extreme cases --such as to contain a denial of service attack or
+   other breach of security-- an SMTP server may block mail directed to
+   Postmaster.  However, such arrangements SHOULD be narrowly tailored
+   so as to avoid blocking messages which are not part of such attacks.
+
+4.5.2 Transparency
+
+   Without some provision for data transparency, the character sequence
+   "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
+   In general, users are not aware of such "forbidden" sequences.  To
+
+
+
+
+Klensin                     Standards Track                    [Page 53]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   allow all user composed text to be transmitted transparently, the
+   following procedures are used:
+
+   -  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.
+
+   -  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
+      treated as the end of mail indicator.  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
+   spaces, vertical and horizontal tabs, and other control characters.
+   If the transmission channel provides an 8-bit byte (octet) data
+   stream, the 7-bit ASCII codes are transmitted right justified in the
+   octets, with the high order bits cleared to zero.  See 3.7 for
+   special treatment of these conditions in SMTP systems serving a relay
+   function.
+
+   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, that
+   store data in records rather than strings, or which use special
+   character sequences as delimiters inside mailboxes.  If such
+   transformations are necessary, they MUST be reversible, especially if
+   they are applied to mail being relayed.
+
+4.5.3 Sizes and Timeouts
+
+4.5.3.1 Size limits and minimums
+
+   There are several objects that have required minimum/maximum sizes.
+   Every implementation MUST be able to receive objects of at least
+   these sizes.  Objects larger than these sizes SHOULD be avoided when
+   possible.  However, some Internet mail constructs such as encoded
+   X.400 addresses [16] will often require larger objects: clients MAY
+   attempt to transmit these, but MUST be prepared for a server to
+   reject them if they cannot be handled by it.  To the maximum extent
+   possible, implementation techniques which impose no limits on the
+   length of these objects should be used.
+
+   local-part
+      The maximum total length of a user name or other local-part is 64
+      characters.
+
+
+
+
+Klensin                     Standards Track                    [Page 54]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   domain
+      The maximum total length of a domain name or number is 255
+      characters.
+
+   path
+      The maximum total length of a reverse-path or forward-path is 256
+      characters (including the punctuation and element separators).
+
+   command line
+      The maximum total length of a command line including the command
+      word and the <CRLF> is 512 characters.  SMTP extensions may be
+      used to increase this limit.
+
+   reply line
+      The maximum total length of a reply line including the reply code
+      and the <CRLF> is 512 characters.  More information may be
+      conveyed through multiple-line replies.
+
+   text line
+      The maximum total length of a text line including the <CRLF> is
+      1000 characters (not counting the leading dot duplicated for
+      transparency).  This number may be increased by the use of SMTP
+      Service Extensions.
+
+   message content
+      The maximum total length of a message content (including any
+      message headers as well as the message body) MUST BE at least 64K
+      octets.  Since the introduction of Internet standards for
+      multimedia mail [12], 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 [18],
+      and SMTP client systems that will send large messages SHOULD
+      utilize it when possible.
+
+   recipients buffer
+      The minimum total number of recipients that must be buffered is
+      100 recipients.  Rejection of messages (for excessive recipients)
+      with fewer than 100 RCPT commands is a violation of this
+      specification.  The general principle that relaying SMTP servers
+      MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
+      tests on message headers suggests that rejecting a message based
+      on the total number of recipients shown in header fields is to be
+      discouraged.  A server which imposes a limit on the number of
+      recipients MUST behave in an orderly fashion,  such as to reject
+      additional addresses over its limit rather than silently
+      discarding addresses previously accepted.  A client that needs to
+
+
+
+
+Klensin                     Standards Track                    [Page 55]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      deliver a message containing over 100 RCPT commands SHOULD be
+      prepared to transmit in 100-recipient "chunks" if the server
+      declines to accept more than 100 recipients in a single message.
+
+   Errors due to exceeding these limits may be reported by using the
+   reply codes.  Some examples of reply codes are:
+
+      500 Line too long.
+   or
+      501 Path too long
+   or
+      452 Too many recipients  (see below)
+   or
+      552 Too much mail data.
+
+   RFC 821 [30] incorrectly listed the error where an SMTP server
+   exhausts its implementation limit on the number of RCPT commands
+   ("too many recipients") as having reply code 552.  The correct reply
+   code for this condition is 452.  Clients SHOULD treat a 552 code in
+   this case as a temporary, rather than permanent, failure so the logic
+   below works.
+
+   When a conforming SMTP server encounters this condition, it has at
+   least 100 successful RCPT commands in its recipients buffer.  If the
+   server is able to accept the message, then at least these 100
+   addresses will be removed from the SMTP client's queue.  When the
+   client attempts retransmission of those addresses which received 452
+   responses, at least 100 of these will be able to fit in the SMTP
+   server's recipients buffer.  Each retransmission attempt which is
+   able to deliver anything will be able to dispose of at least 100 of
+   these recipients.
+
+   If an SMTP server has an implementation limit on the number of RCPT
+   commands and this limit is exhausted, it MUST use a response code of
+   452 (but the client SHOULD also be prepared for a 552, as noted
+   above).  If the server has a configured site-policy limitation on the
+   number of RCPT commands, it MAY instead use a 5XX response code.
+   This would be most appropriate if the policy limitation was intended
+   to apply if the total recipient count for a particular message body
+   were enforced even if that message body was sent in multiple mail
+   transactions.
+
+4.5.3.2 Timeouts
+
+   An SMTP client MUST provide a timeout mechanism.  It MUST use per-
+   command timeouts rather than somehow trying to time the entire mail
+   transaction.  Timeouts SHOULD be easily reconfigurable, preferably
+   without recompiling the SMTP code.  To implement this, a timer is set
+
+
+
+Klensin                     Standards Track                    [Page 56]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   for each SMTP command and for each buffer of the data transfer.  The
+   latter means that the overall timeout is inherently proportional to
+   the size of the message.
+
+   Based on extensive experience with busy mail-relay hosts, the minimum
+   per-command timeout values SHOULD be as follows:
+
+   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 accept a TCP connection but delay
+      delivery of the 220 message until their system load permits more
+      mail to be processed.
+
+   MAIL Command: 5 minutes
+
+   RCPT Command: 5 minutes
+      A longer timeout is required if processing of mailing lists and
+      aliases is not deferred until after the message was accepted.
+
+   DATA Initiation: 2 minutes
+      This is while awaiting the "354 Start Input" reply to a DATA
+      command.
+
+   Data Block: 3 minutes
+      This is while awaiting the completion of each TCP SEND call
+      transmitting a chunk of data.
+
+   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 and would
+      typically result in delivery of multiple copies of the message,
+      since it has been successfully sent and the server has accepted
+      responsibility for delivery.  See section 6.1 for additional
+      discussion.
+
+   An SMTP server SHOULD have a timeout of at least 5 minutes while it
+   is awaiting the next command from the sender.
+
+4.5.4 Retry Strategies
+
+   The common structure of a host SMTP implementation includes user
+   mailboxes, one or more areas for queuing 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
+
+
+
+
+Klensin                     Standards Track                    [Page 57]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   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 queuing strategy MUST include timeouts on all activities on a
+   per-command basis.  A queuing strategy MUST NOT send error messages
+   in response to error messages under any circumstances.
+
+4.5.4.1 Sending Strategy
+
+   The general model for 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 client SHOULD keep a list of hosts it cannot reach and
+   corresponding connection timeouts, rather than just retrying queued
+   mail items.
+
+   Experience suggests that failures are typically transient (the target
+   system or its connection has crashed), favoring a policy of two
+   connection attempts in the first hour the message is in the queue,
+   and then backing off to one every two or three hours.
+
+   The SMTP client can shorten the queuing delay in cooperation with the
+   SMTP server.  For example, if mail is received from a particular
+   address, it is likely that mail queued for that host can now be sent.
+   Application of this principle may, in many cases, eliminate the
+   requirement for an explicit "send queues now" function such as ETRN
+   [9].
+
+   The strategy may be further modified as a result of multiple
+   addresses per host (see below) to optimize delivery time vs. resource
+   usage.
+
+
+
+
+Klensin                     Standards Track                    [Page 58]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   An SMTP client may have a large queue of messages for each
+   unavailable destination host.  If all of these messages were retried
+   in every retry cycle, there would be excessive Internet overhead and
+   the sending system would be blocked for a long period.  Note that an
+   SMTP client can generally determine that a delivery attempt has
+   failed only after a timeout of several minutes and even a one-minute
+   timeout per connection will result in a very large delay if retries
+   are repeated for dozens, or even hundreds, of queued messages to the
+   same host.
+
+   At the same time, SMTP clients SHOULD use great care in caching
+   negative responses from servers.  In an extreme case, if EHLO is
+   issued multiple times during the same SMTP connection, different
+   answers may be returned by the server.  More significantly, 5yz
+   responses to the MAIL command MUST NOT be cached.
+
+   When a mail message is to be delivered to multiple recipients, and
+   the SMTP server to which a copy of the message is to be sent is the
+   same for multiple recipients, then only one copy of the message
+   SHOULD be transmitted.  That is, the SMTP client SHOULD use the
+   command sequence:  MAIL, RCPT, RCPT,... RCPT, DATA instead of the
+   sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA.  However, if there
+   are very many addresses, a limit on the number of RCPT commands per
+   MAIL command MAY be imposed.  Implementation of this efficiency
+   feature is strongly encouraged.
+
+   Similarly, to achieve timely delivery, the SMTP client MAY support
+   multiple concurrent outgoing mail transactions.  However, some limit
+   may be appropriate to protect the host from devoting all its
+   resources to mail.
+
+4.5.4.2 Receiving Strategy
+
+   The SMTP server SHOULD attempt to keep a pending listen on the SMTP
+   port at all times.  This requires the support of multiple incoming
+   TCP connections for SMTP.  Some limit MAY be imposed but servers that
+   cannot handle more than one SMTP transaction at a time are not in
+   conformance with the intent of this specification.
+
+   As discussed above, when the SMTP server receives mail from a
+   particular host address, it could activate its own SMTP queuing
+   mechanisms to retry any mail pending for that host address.
+
+4.5.5   Messages with a null reverse-path
+
+   There are several types of notification messages which are required
+   by existing and proposed standards to be sent with a null reverse
+   path, namely non-delivery notifications as discussed in section 3.7,
+
+
+
+Klensin                     Standards Track                    [Page 59]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   other kinds of Delivery Status Notifications (DSNs) [24], and also
+   Message Disposition Notifications (MDNs) [10].  All of these kinds of
+   messages are notifications about a previous message, and they are
+   sent to the reverse-path of the previous mail message.  (If the
+   delivery of such a notification message fails, that usually indicates
+   a problem with the mail system of the host to which the notification
+   message is addressed.  For this reason, at some hosts the MTA is set
+   up to forward such failed notification messages to someone who is
+   able to fix problems with the mail system, e.g., via the postmaster
+   alias.)
+
+   All other types of messages (i.e., any message which is not required
+   by a standards-track RFC to have a null reverse-path) SHOULD be sent
+   with with a valid, non-null reverse-path.
+
+   Implementors of automated email processors should be careful to make
+   sure that the various kinds of messages with null reverse-path are
+   handled correctly, in particular such systems SHOULD NOT reply to
+   messages with null reverse-path.
+
+5. Address Resolution and Mail Handling
+
+   Once an SMTP client lexically identifies a domain to which mail will
+   be delivered for processing (as described in sections 3.6 and 3.7), a
+   DNS lookup MUST be performed to resolve the domain name [22].  The
+   names are expected to be fully-qualified domain names (FQDNs):
+   mechanisms for inferring FQDNs from partial names or local aliases
+   are outside of this specification and, due to a history of problems,
+   are generally discouraged.  The lookup first attempts to locate an MX
+   record associated with the name.  If a CNAME record is found instead,
+   the resulting name is processed as if it were the initial name.  If
+   no MX records are found, but an A RR is found, the A RR is treated as
+   if it was associated with an implicit MX RR, with a preference of 0,
+   pointing to that host.  If one or more MX RRs are found for a given
+   name, SMTP systems MUST NOT utilize any A RRs associated with that
+   name unless they are located using the MX RRs; the "implicit MX" rule
+   above applies only if there are no MX records present.  If MX records
+   are present, but none of them are usable, this situation MUST be
+   reported as an error.
+
+   When the lookup succeeds, the mapping can result in a list of
+   alternative delivery addresses rather than a single address, because
+   of multiple MX records, multihoming, or both.  To provide reliable
+   mail transmission, the SMTP client MUST be able to try (and retry)
+   each of the relevant 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, the SMTP client SHOULD try at least two addresses.
+
+
+
+Klensin                     Standards Track                    [Page 60]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Two types of information is used to rank the host addresses: multiple
+   MX records, and multihomed hosts.
+
+   Multiple MX records contain a preference indication that MUST be used
+   in sorting (see below).  Lower numbers are more preferred than higher
+   ones.  If there are multiple destinations with the same preference
+   and there is no clear reason to favor one (e.g., by recognition of an
+   easily-reached address), then the sender-SMTP MUST randomize them to
+   spread the load across multiple mail exchangers for a specific
+   organization.
+
+   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 if necessary, and SMTP MUST try them in the
+   order presented.
+
+   Although the capability to try multiple alternative addresses is
+   required, specific installations may 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 4.5.4.1.
+
+   If an SMTP server receives a message with a destination for which it
+   is a designated Mail eXchanger, it MAY relay the message (potentially
+   after having rewritten the MAIL FROM and/or RCPT TO addresses), make
+   final delivery of the message, or hand it off using some mechanism
+   outside the SMTP-provided transport environment.  Of course, neither
+   of the latter require that the list of MX records be examined
+   further.
+
+   If it determines that it should relay the message without rewriting
+   the address, it MUST sort the MX records to determine candidates for
+   delivery.  The records are first ordered by preference, with the
+   lowest-numbered records being most preferred.  The relay host MUST
+   then inspect the list for any of the names or addresses by which it
+   might be known in mail transactions.  If a matching record is found,
+   all records at that preference level and higher-numbered ones MUST be
+   discarded from consideration.  If there are no records left at that
+   point, it is an error condition, and the message MUST be returned as
+   undeliverable.  If records do remain, they SHOULD be tried, best
+   preference first, as described above.
+
+
+
+Klensin                     Standards Track                    [Page 61]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+6. Problem Detection and Handling
+
+6.1 Reliable Delivery and Replies by Email
+
+   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
+   message in response to DATA), it is accepting responsibility for
+   delivering or relaying the message.  It must take this responsibility
+   seriously.  It MUST NOT lose the message for frivolous reasons, such
+   as because the host later crashes or because of a predictable
+   resource shortage.
+
+   If there is a delivery failure after acceptance of a message, the
+   receiver-SMTP MUST formulate and mail a notification message.  This
+   notification MUST be sent using a null ("<>") reverse path in the
+   envelope.  The recipient of this notification MUST be the address
+   from the envelope return path (or the Return-Path: line).  However,
+   if this address is null ("<>"), the receiver-SMTP MUST NOT send a
+   notification.  Obviously, nothing in this section can or should
+   prohibit local decisions (i.e., as part of the same system
+   environment as the receiver-SMTP) to log or otherwise transmit
+   information about null address events locally if that is desired.  If
+   the address is an explicit source route, it MUST be stripped down to
+   its final hop.
+
+   For example, suppose that an error notification must be sent for a
+   message that arrived with:
+
+      MAIL FROM:<@a,@b:user@d>
+
+   The notification message MUST be sent using:
+
+      RCPT TO:<user@d>
+
+   Some delivery failures after the message is accepted by SMTP will be
+   unavoidable.  For example, it may be impossible for the receiving
+   SMTP server to validate all the delivery addresses in RCPT command(s)
+   due to a "soft" domain system error, because the target is a mailing
+   list (see earlier discussion of RCPT), or because the server is
+   acting as a relay and has no immediate access to the delivering
+   system.
+
+   To avoid receiving duplicate messages as the result of timeouts, a
+   receiver-SMTP MUST seek to minimize the time required to respond to
+   the final <CRLF>.<CRLF> end of data indicator.  See RFC 1047 [28] for
+   a discussion of this problem.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 62]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+6.2 Loop Detection
+
+   Simple counting of the number of "Received:" headers in a message has
+   proven to be an effective, although rarely optimal, method of
+   detecting loops in mail systems.  SMTP servers using this technique
+   SHOULD use a large rejection threshold, normally at least 100
+   Received entries.  Whatever mechanisms are used, servers MUST contain
+   provisions for detecting and stopping trivial loops.
+
+6.3 Compensating for Irregularities
+
+   Unfortunately, variations, creative interpretations, and outright
+   violations of Internet mail protocols do occur; some would suggest
+   that they occur quite frequently.  The debate as to whether a well-
+   behaved SMTP receiver or relay should reject a malformed message,
+   attempt to pass it on unchanged, or attempt to repair it to increase
+   the odds of successful delivery (or subsequent reply) began almost
+   with the dawn of structured network mail and shows no signs of
+   abating.  Advocates of rejection claim that attempted repairs are
+   rarely completely adequate and that rejection of bad messages is the
+   only way to get the offending software repaired.  Advocates of
+   "repair" or "deliver no matter what" argue that users prefer that
+   mail go through it if at all possible and that there are significant
+   market pressures in that direction.  In practice, these market
+   pressures may be more important to particular vendors than strict
+   conformance to the standards, regardless of the preference of the
+   actual developers.
+
+   The problems associated with ill-formed messages were exacerbated by
+   the introduction of the split-UA mail reading protocols [3, 26, 5,
+   21].  These protocols have encouraged the use of SMTP as a posting
+   protocol, and SMTP servers as relay systems for these client hosts
+   (which are often only intermittently connected to the Internet).
+   Historically, many of those client machines lacked some of the
+   mechanisms and information assumed by SMTP (and indeed, by the mail
+   format protocol [7]).  Some could not keep adequate track of time;
+   others had no concept of time zones; still others could not identify
+   their own names or addresses; and, of course, none could satisfy the
+   assumptions that underlay RFC 822's conception of authenticated
+   addresses.
+
+   In response to these weak SMTP clients, many SMTP systems now
+   complete messages that are delivered to them in incomplete or
+   incorrect form.  This strategy is generally considered appropriate
+   when the server can identify or authenticate the client, and there
+   are prior agreements between them.  By contrast, there is at best
+   great concern about fixes applied by a relay or delivery SMTP server
+   that has little or no knowledge of the user or client machine.
+
+
+
+Klensin                     Standards Track                    [Page 63]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The following changes to a message being processed MAY be applied
+   when necessary by an originating SMTP server, or one used as the
+   target of SMTP as an initial posting protocol:
+
+   -  Addition of a message-id field when none appears
+
+   -  Addition of a date, time or time zone when none appears
+
+   -  Correction of addresses to proper FQDN format
+
+   The less information the server has about the client, the less likely
+   these changes are to be correct and the more caution and conservatism
+   should be applied when considering whether or not to perform fixes
+   and how.  These changes MUST NOT be applied by an SMTP server that
+   provides an intermediate relay function.
+
+   In all cases, properly-operating clients supplying correct
+   information are preferred to corrections by the SMTP server.  In all
+   cases, documentation of actions performed by the servers (in trace
+   fields and/or header comments) is strongly encouraged.
+
+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 mail
+   security lies only in end-to-end methods involving the message
+   bodies, such as those which use digital signatures (see [14] and,
+   e.g., PGP [4] or S/MIME [31]).
+
+   Various protocol extensions and configuration options that provide
+   authentication at the transport level (e.g., from an SMTP client to
+   an SMTP server) improve somewhat on the traditional situation
+   described above.  However, unless they are accompanied by careful
+   handoffs of responsibility in a carefully-designed trust environment,
+   they remain inherently weaker than end-to-end mechanisms which use
+   digitally signed messages rather than depending on the integrity of
+   the transport system.
+
+
+
+
+Klensin                     Standards Track                    [Page 64]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Efforts to make it more difficult for users to set envelope return
+   path and header "From" fields to point to valid addresses other than
+   their own are largely misguided: they 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.  (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 within the message data can be generated sensibly.)
+
+   This specification does not further address the authentication 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 that do not appear in the message headers may appear in the
+   RCPT commands to an SMTP server for a number of reasons.  The two
+   most common 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".  Especially when more than one RCPT
+   command is present, and in order to avoid defeating some of the
+   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
+   the full set of RCPT command arguments into the headers, either as
+   part of trace headers or 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 command.
+
+   There is no inherent relationship between either "reverse" (from
+   MAIL, SAML, etc., commands) or "forward" (RCPT) 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 as well as a
+   common source of unintended information disclosure and SHOULD NOT be
+   used.
+
+7.3 VRFY, EXPN, and Security
+
+   As discussed in section 3.5, individual sites may want to disable
+   either 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
+
+
+
+
+
+Klensin                     Standards Track                    [Page 65]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   disables these commands for security reasons, the SMTP server MUST
+   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 only for syntax 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.
+
+   Within the last few years, the contents of mailing lists have become
+   popular as an address information source for so-called "spammers."
+   The use of EXPN to "harvest" addresses has increased as list
+   administrators have installed protections against inappropriate uses
+   of the lists themselves.  Implementations SHOULD still provide
+   support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
+   As authentication mechanisms are introduced into SMTP, some sites may
+   choose to make EXPN available only to authenticated requestors.
+
+7.4 Information Disclosure in Announcements
+
+   There has been an ongoing debate about the tradeoffs between the
+   debugging advantages of announcing server type and version (and,
+   sometimes, even server domain name) in the greeting response or in
+   response to the HELP command and the disadvantages of exposing
+   information that might be useful in a potential hostile attack.  The
+   utility of the debugging information is beyond doubt.  Those who
+   argue for making it available point out that it is far better to
+   actually secure an SMTP server rather than hope that trying to
+   conceal known vulnerabilities by hiding the server's precise identity
+   will provide more protection.  Sites are encouraged to evaluate the
+   tradeoff with that issue in mind; implementations are strongly
+   encouraged to minimally provide for making type and version
+   information available in some way to other network hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+   In some circumstances, such as when mail originates from within a LAN
+   whose hosts are not directly on the public Internet, trace
+   ("Received") fields produced in conformance with this specification
+   may disclose host names and similar information that would not
+   normally be available.  This ordinarily does not pose a problem, but
+   sites with special concerns about name disclosure should be aware of
+   it.  Also, the optional FOR clause should be supplied with caution or
+   not at all when multiple recipients are involved lest it
+   inadvertently disclose the identities of "blind copy" recipients to
+   others.
+
+
+
+
+Klensin                     Standards Track                    [Page 66]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+7.6 Information Disclosure in Message Forwarding
+
+   As discussed in section 3.4, use of the 251 or 551 reply codes to
+   identify the replacement address associated with a mailbox may
+   inadvertently disclose sensitive information.  Sites that are
+   concerned about those issues should ensure that they select and
+   configure servers appropriately.
+
+7.7 Scope of Operation of SMTP Servers
+
+   It is a well-established principle that an SMTP server may refuse to
+   accept mail for any operational or technical reason that makes sense
+   to the site providing the server.  However, cooperation among sites
+   and installations makes the Internet possible.  If sites take
+   excessive advantage of the right to reject traffic, the ubiquity of
+   email availability (one of the strengths of the Internet) will be
+   threatened; considerable care should be taken and balance maintained
+   if a site decides to be selective about the traffic it will accept
+   and process.
+
+   In recent years, use of the relay function through arbitrary sites
+   has been used as part of hostile efforts to hide the actual origins
+   of mail.  Some sites have decided to limit the use of the relay
+   function to known or identifiable sources, and implementations SHOULD
+   provide the capability to perform this type of filtering.  When mail
+   is rejected for these or other policy reasons, a 550 code SHOULD be
+   used in response to EHLO, MAIL, or RCPT as appropriate.
+
+8. IANA Considerations
+
+   IANA will maintain three registries in support of this specification.
+   The first consists of SMTP service extensions with the associated
+   keywords, and, as needed, parameters and verbs.  As specified in
+   section 2.2.2, no entry may be made in this registry that starts in
+   an "X".  Entries may be made only for service extensions (and
+   associated keywords, parameters, or verbs) that are defined in
+   standards-track or experimental RFCs specifically approved by the
+   IESG for this purpose.
+
+   The second registry consists of "tags" that identify forms of domain
+   literals other than those for IPv4 addresses (specified in RFC 821
+   and in this document) and IPv6 addresses (specified in this
+   document).  Additional literal types require standardization before
+   being used; none are anticipated at this time.
+
+   The third, established by RFC 821 and renewed by this specification,
+   is a registry of link and protocol identifiers to be used with the
+   "via" and "with" subclauses of the time stamp ("Received: header")
+
+
+
+Klensin                     Standards Track                    [Page 67]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   described in section 4.4.  Link and protocol identifiers in addition
+   to those specified in this document may be registered only by
+   standardization or by way of an RFC-documented, IESG-approved,
+   Experimental protocol extension.
+
+9. References
+
+   [1]  American National Standards Institute (formerly United States of
+        America Standards Institute), X3.4, 1968, "USA Code for
+        Information Interchange". ANSI X3.4-1968 has been replaced by
+        newer versions with slight modifications, but the 1968 version
+        remains definitive for the Internet.
+
+   [2]  Braden, R., "Requirements for Internet hosts - application and
+        support", STD 3, RFC 1123, October 1989.
+
+   [3]  Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
+        Reynolds, "Post Office Protocol - version 2", RFC 937, February
+        1985.
+
+   [4]  Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
+        Message Format", RFC 2440, November 1998.
+
+   [5]  Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
+        1176, August 1990.
+
+   [6]  Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+        2060, December 1996.
+
+   [7]  Crocker, D., "Standard for the Format of ARPA Internet Text
+        Messages", RFC 822, August 1982.
+
+   [8]  Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [9]  De Winter, J., "SMTP Service Extension for Remote Message Queue
+        Starting", RFC 1985, August 1996.
+
+   [10] Fajman, R., "An Extensible Message Format for Message
+        Disposition Notifications", RFC 2298, March 1998.
+
+   [11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
+        RFC 2979, October 2000.
+
+   [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part One: Format of Internet Message Bodies",
+        RFC 2045, December 1996.
+
+
+
+
+Klensin                     Standards Track                    [Page 68]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
+        2920, September 2000.
+
+   [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
+        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+        RFC 1847, October 1995.
+
+   [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
+        December 1998.
+
+   [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
+        January 1998.
+
+   [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
+        Message Size Declaration", STD 10, RFC 1870, November 1995.
+
+   [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
+        "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
+
+   [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
+        "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
+        1994.
+
+   [21] Lambert, M., "PCMAIL: A distributed mail system for personal
+        computers", RFC 1056, July 1988.
+
+   [22] Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+        Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+        December 1996.
+
+   [24] Moore, K., "SMTP Service Extension for Delivery Status
+        Notifications", RFC 1891, January 1996.
+
+   [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+        Delivery Status Notifications", RFC 1894, January 1996.
+
+   [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
+        53, RFC 1939, May 1996.
+
+
+
+
+Klensin                     Standards Track                    [Page 69]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   [27] Partridge, C., "Mail routing and the domain system", RFC 974,
+        January 1986.
+
+   [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February
+        1988.
+
+   [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+        Program Protocol Specification", STD 7, RFC 793, September 1981.
+
+   [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
+        1982.
+
+   [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
+        2633, June 1999.
+
+   [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
+        2001.
+
+   [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
+        Large and Binary MIME Messages", RFC 1830, August 1995.
+
+   [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+        January 1996.
+
+10. Editor's Address
+
+   John C. Klensin
+   AT&T Laboratories
+   99 Bedford St
+   Boston, MA 02111 USA
+
+   Phone: 617-574-3076
+   EMail: klensin@research.att.com
+
+11. Acknowledgments
+
+   Many people worked long and hard on the many iterations of this
+   document.  There was wide-ranging debate in the IETF DRUMS Working
+   Group, both on its mailing list and in face to face discussions,
+   about many technical issues and the role of a revised standard for
+   Internet mail transport, and many contributors helped form the
+   wording in this specification.  The hundreds of participants in the
+   many discussions since RFC 821 was produced are too numerous to
+   mention, but they all helped this document become what it is.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 70]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+APPENDICES
+
+A. TCP Transport Service
+
+   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.  Service
+   extensions may modify this rule to permit transmission of full 8-bit
+   data bytes as part of the message body, but not in SMTP commands or
+   responses.
+
+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 ("submission
+   client") MTA with an envelope separate from the message itself.
+   However, if the envelope is not supplied, SMTP commands SHOULD be
+   generated as follows:
+
+   1. Each recipient address 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 as specified in
+      [32].
+
+   2. The return address in the MAIL command SHOULD, if possible, be
+      derived from the system's identity for the submitting (local)
+      user, and the "From:" header field otherwise.  If there is a
+      system identity available, it 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; see section 7.1.
+
+
+
+Klensin                     Standards Track                    [Page 71]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   When an MTA is being used in this way, it bears responsibility for
+   ensuring that the message being transmitted is valid.  The mechanisms
+   for checking that validity, and for handling (or returning) messages
+   that are not valid at the time of arrival, are part of the MUA-MTA
+   interface and not covered by this specification.
+
+   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.
+
+C. Source Routes
+
+   Historically, the <reverse-path> was a reverse source routing list of
+   hosts and a source mailbox.  The first host in the <reverse-path>
+   SHOULD be the host sending the MAIL command.  Similarly, the
+   <forward-path> may be a source routing lists of hosts and a
+   destination mailbox.  However, in general, the <forward-path> SHOULD
+   contain only a mailbox and domain name, relying on the domain name
+   system to supply routing information if required.  The use of source
+   routes is deprecated; while servers MUST be prepared to receive and
+   handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
+   transmit them and this section was included only to provide context.
+
+   For relay purposes, 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.
+
+   If source routes are used, RFC 821 and the text below should be
+   consulted for the mechanisms for constructing and updating the
+   forward- and reverse-paths.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 72]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   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.
+
+   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.
+
+   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).
+
+D. Scenarios
+
+   This section presents complete scenarios of several types of SMTP
+   sessions.  In the examples, "C:" indicates what is said by the SMTP
+   client, and "S:" indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+   This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+   Green, and Brown at host foo.com.  Here we assume that host bar.com
+   contacts host foo.com directly.  The mail is accepted for Jones and
+   Brown.  Green does not have a mailbox at host foo.com.
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<Smith@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@foo.com>
+      S: 250 OK
+      C: RCPT TO:<Green@foo.com>
+      S: 550 No such user here
+      C: RCPT TO:<Brown@foo.com>
+
+
+
+Klensin                     Standards Track                    [Page 73]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Blah blah blah...
+      C: ...etc. etc. etc.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<Smith@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@foo.com>
+      S: 250 OK
+      C: RCPT TO:<Green@foo.com>
+      S: 550 No such user here
+      C: RSET
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+   Step 1  --  Source Host to Relay Host
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<JQP@bar.com>
+      S: 250 OK
+      C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Date: Thu, 21 May 1998 05:33:29 -0700
+
+
+
+Klensin                     Standards Track                    [Page 74]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      C: From: John Q. Public <JQP@bar.com>
+      C: Subject:  The Next Meeting of the Board
+      C: To: Jones@xyz.com
+      C:
+      C: Bill:
+      C: The next meeting of the board of directors will be
+      C: on Tuesday.
+      C:                         John.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+   Step 2  --  Relay Host to Destination Host
+
+      S: 220 xyz.com Simple Mail Transfer Service Ready
+      C: EHLO foo.com
+      S: 250 xyz.com is on the air
+      C: MAIL FROM:<@foo.com:JQP@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@XYZ.COM>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Received: from bar.com by foo.com ; Thu, 21 May 1998
+      C:     05:33:29 -0700
+      C: Date: Thu, 21 May 1998 05:33:22 -0700
+      C: From: John Q. Public <JQP@bar.com>
+      C: Subject:  The Next Meeting of the Board
+      C: To: Jones@xyz.com
+      C:
+      C: Bill:
+      C: The next meeting of the board of directors will be
+      C: on Tuesday.
+      C:                         John.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+
+
+
+Klensin                     Standards Track                    [Page 75]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      S: 250-VRFY
+      S: 250 HELP
+      C: VRFY Crispin
+      S: 250 Mark Crispin <Admin.MRC@foo.com>
+      C: SEND FROM:<EAK@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Admin.MRC@foo.com>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Blah blah blah...
+      C: ...etc. etc. etc.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+E. 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,
+   (such as envelope information from one system to the message headers
+   or body of another) have generally proven to be inadequate in
+   important ways.  Systems translating between environments that do not
+   support both envelopes and headers and Internet mail must be written
+   with the understanding that some information loss is almost
+   inevitable.
+
+F. Deprecated Features of RFC 821
+
+   A few features of RFC 821 have proven to be problematic and SHOULD
+   NOT be used in Internet mail.
+
+F.1 TURN
+
+   This command, described in RFC 821, raises important security issues
+   since, in the absence of strong authentication of the host requesting
+   that the client and server switch roles, it can easily be used to
+   divert mail from its correct destination.  Its use is deprecated;
+   SMTP systems SHOULD NOT use it unless the server can authenticate the
+   client.
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 76]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+F.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.
+
+F.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 and process HELO in order to support older clients.
+
+F.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.
+
+F.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.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 77]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+F.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 78]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 79]
+
diff --git a/standards/rfc2822.txt b/standards/rfc2822.txt
new file mode 100644
index 000000000..9f698f77d
--- /dev/null
+++ b/standards/rfc2822.txt
@@ -0,0 +1,2859 @@
+
+
+
+
+
+
+Network Working Group                                 P. Resnick, Editor
+Request for Comments: 2822                         QUALCOMM Incorporated
+Obsoletes: 822                                                April 2001
+Category: Standards Track
+
+
+                        Internet Message Format
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This standard specifies a syntax for text messages that are sent
+   between computer users, within the framework of "electronic mail"
+   messages.  This standard supersedes the one specified in Request For
+   Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
+   Messages", updating it to reflect current practice and incorporating
+   incremental changes that were specified in other RFCs.
+
+Table of Contents
+
+   1. Introduction ............................................... 3
+   1.1. Scope .................................................... 3
+   1.2. Notational conventions ................................... 4
+   1.2.1. Requirements notation .................................. 4
+   1.2.2. Syntactic notation ..................................... 4
+   1.3. Structure of this document ............................... 4
+   2. Lexical Analysis of Messages ............................... 5
+   2.1. General Description ...................................... 5
+   2.1.1. Line Length Limits ..................................... 6
+   2.2. Header Fields ............................................ 7
+   2.2.1. Unstructured Header Field Bodies ....................... 7
+   2.2.2. Structured Header Field Bodies ......................... 7
+   2.2.3. Long Header Fields ..................................... 7
+   2.3. Body ..................................................... 8
+   3. Syntax ..................................................... 9
+   3.1. Introduction ............................................. 9
+   3.2. Lexical Tokens ........................................... 9
+
+
+
+Resnick                     Standards Track                     [Page 1]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   3.2.1. Primitive Tokens ....................................... 9
+   3.2.2. Quoted characters ......................................10
+   3.2.3. Folding white space and comments .......................11
+   3.2.4. Atom ...................................................12
+   3.2.5. Quoted strings .........................................13
+   3.2.6. Miscellaneous tokens ...................................13
+   3.3. Date and Time Specification ..............................14
+   3.4. Address Specification ....................................15
+   3.4.1. Addr-spec specification ................................16
+   3.5 Overall message syntax ....................................17
+   3.6. Field definitions ........................................18
+   3.6.1. The origination date field .............................20
+   3.6.2. Originator fields ......................................21
+   3.6.3. Destination address fields .............................22
+   3.6.4. Identification fields ..................................23
+   3.6.5. Informational fields ...................................26
+   3.6.6. Resent fields ..........................................26
+   3.6.7. Trace fields ...........................................28
+   3.6.8. Optional fields ........................................29
+   4. Obsolete Syntax ............................................29
+   4.1. Miscellaneous obsolete tokens ............................30
+   4.2. Obsolete folding white space .............................31
+   4.3. Obsolete Date and Time ...................................31
+   4.4. Obsolete Addressing ......................................33
+   4.5. Obsolete header fields ...................................33
+   4.5.1. Obsolete origination date field ........................34
+   4.5.2. Obsolete originator fields .............................34
+   4.5.3. Obsolete destination address fields ....................34
+   4.5.4. Obsolete identification fields .........................35
+   4.5.5. Obsolete informational fields ..........................35
+   4.5.6. Obsolete resent fields .................................35
+   4.5.7. Obsolete trace fields ..................................36
+   4.5.8. Obsolete optional fields ...............................36
+   5. Security Considerations ....................................36
+   6. Bibliography ...............................................37
+   7. Editor's Address ...........................................38
+   8. Acknowledgements ...........................................39
+   Appendix A. Example messages ..................................41
+   A.1. Addressing examples ......................................41
+   A.1.1. A message from one person to another with simple
+          addressing .............................................41
+   A.1.2. Different types of mailboxes ...........................42
+   A.1.3. Group addresses ........................................43
+   A.2. Reply messages ...........................................43
+   A.3. Resent messages ..........................................44
+   A.4. Messages with trace fields ...............................46
+   A.5. White space, comments, and other oddities ................47
+   A.6. Obsoleted forms ..........................................47
+
+
+
+Resnick                     Standards Track                     [Page 2]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   A.6.1. Obsolete addressing ....................................48
+   A.6.2. Obsolete dates .........................................48
+   A.6.3. Obsolete white space and comments ......................48
+   Appendix B. Differences from earlier standards ................49
+   Appendix C. Notices ...........................................50
+   Full Copyright Statement ......................................51
+
+1. Introduction
+
+1.1. Scope
+
+   This standard specifies a syntax for text messages that are sent
+   between computer users, within the framework of "electronic mail"
+   messages.  This standard supersedes the one specified in Request For
+   Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
+   Messages" [RFC822], updating it to reflect current practice and
+   incorporating incremental changes that were specified in other RFCs
+   [STD3].
+
+   This standard specifies a syntax only for text messages.  In
+   particular, it makes no provision for the transmission of images,
+   audio, or other sorts of structured data in electronic mail messages.
+   There are several extensions published, such as the MIME document
+   series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the
+   transmission of such data through electronic mail, either by
+   extending the syntax provided here or by structuring such messages to
+   conform to this syntax.  Those mechanisms are outside of the scope of
+   this standard.
+
+   In the context of electronic mail, messages are viewed as having an
+   envelope and contents.  The envelope contains whatever information is
+   needed to accomplish transmission and delivery.  (See [RFC2821] for a
+   discussion of the envelope.)  The contents comprise the object to be
+   delivered to the recipient.  This standard applies only to the format
+   and some of the semantics of message contents.  It contains no
+   specification of the information in the envelope.
+
+   However, some message systems may use information from the contents
+   to create the envelope.  It is intended that this standard facilitate
+   the acquisition of such information by programs.
+
+   This specification is intended as a definition of what message
+   content format is to be passed between systems.  Though some message
+   systems locally store messages in this format (which eliminates the
+   need for translation between formats) and others use formats that
+   differ from the one specified in this standard, local storage is
+   outside of the scope of this standard.
+
+
+
+
+Resnick                     Standards Track                     [Page 3]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   Note: This standard is not intended to dictate the internal formats
+   used by sites, the specific message system features that they are
+   expected to support, or any of the characteristics of user interface
+   programs that create or read messages.  In addition, this standard
+   does not specify an encoding of the characters for either transport
+   or storage; that is, it does not specify the number of bits used or
+   how those bits are specifically transferred over the wire or stored
+   on disk.
+
+1.2. Notational conventions
+
+1.2.1. Requirements notation
+
+   This document occasionally uses terms that appear in capital letters.
+   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
+   NOT", and "MAY" appear capitalized, they are being used to indicate
+   particular requirements of this specification.  A discussion of the
+   meanings of these terms appears in [RFC2119].
+
+1.2.2. Syntactic notation
+
+   This standard uses the Augmented Backus-Naur Form (ABNF) notation
+   specified in [RFC2234] for the formal definitions of the syntax of
+   messages.  Characters will be specified either by a decimal value
+   (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
+   a case-insensitive literal value enclosed in quotation marks (e.g.,
+   "A" for either uppercase or lowercase A).  See [RFC2234] for the full
+   description of the notation.
+
+1.3. Structure of this document
+
+   This document is divided into several sections.
+
+   This section, section 1, is a short introduction to the document.
+
+   Section 2 lays out the general description of a message and its
+   constituent parts.  This is an overview to help the reader understand
+   some of the general principles used in the later portions of this
+   document.  Any examples in this section MUST NOT be taken as
+   specification of the formal syntax of any part of a message.
+
+   Section 3 specifies formal ABNF rules for the structure of each part
+   of a message (the syntax) and describes the relationship between
+   those parts and their meaning in the context of a message (the
+   semantics).  That is, it describes the actual rules for the structure
+   of each part of a message (the syntax) as well as a description of
+   the parts and instructions on how they ought to be interpreted (the
+   semantics).  This includes analysis of the syntax and semantics of
+
+
+
+Resnick                     Standards Track                     [Page 4]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   subparts of messages that have specific structure.  The syntax
+   included in section 3 represents messages as they MUST be created.
+   There are also notes in section 3 to indicate if any of the options
+   specified in the syntax SHOULD be used over any of the others.
+
+   Both sections 2 and 3 describe messages that are legal to generate
+   for purposes of this standard.
+
+   Section 4 of this document specifies an "obsolete" syntax.  There are
+   references in section 3 to these obsolete syntactic elements.  The
+   rules of the obsolete syntax are elements that have appeared in
+   earlier revisions of this standard or have previously been widely
+   used in Internet messages.  As such, these elements MUST be
+   interpreted by parsers of messages in order to be conformant to this
+   standard.  However, since items in this syntax have been determined
+   to be non-interoperable or to cause significant problems for
+   recipients of messages, they MUST NOT be generated by creators of
+   conformant messages.
+
+   Section 5 details security considerations to take into account when
+   implementing this standard.
+
+   Section 6 is a bibliography of references in this document.
+
+   Section 7 contains the editor's address.
+
+   Section 8 contains acknowledgements.
+
+   Appendix A lists examples of different sorts of messages.  These
+   examples are not exhaustive of the types of messages that appear on
+   the Internet, but give a broad overview of certain syntactic forms.
+
+   Appendix B lists the differences between this standard and earlier
+   standards for Internet messages.
+
+   Appendix C has copyright and intellectual property notices.
+
+2. Lexical Analysis of Messages
+
+2.1. General Description
+
+   At the most basic level, a message is a series of characters.  A
+   message that is conformant with this standard is comprised of
+   characters with values in the range 1 through 127 and interpreted as
+   US-ASCII characters [ASCII].  For brevity, this document sometimes
+   refers to this range of characters as simply "US-ASCII characters".
+
+
+
+
+
+Resnick                     Standards Track                     [Page 5]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   Note: This standard specifies that messages are made up of characters
+   in the US-ASCII range of 1 through 127.  There are other documents,
+   specifically the MIME document series [RFC2045, RFC2046, RFC2047,
+   RFC2048, RFC2049], that extend this standard to allow for values
+   outside of that range.  Discussion of those mechanisms is not within
+   the scope of this standard.
+
+   Messages are divided into lines of characters.  A line is a series of
+   characters that is delimited with the two characters carriage-return
+   and line-feed; that is, the carriage return (CR) character (ASCII
+   value 13) followed immediately by the line feed (LF) character (ASCII
+   value 10).  (The carriage-return/line-feed pair is usually written in
+   this document as "CRLF".)
+
+   A message consists of header fields (collectively called "the header
+   of the message") followed, optionally, by a body.  The header is a
+   sequence of lines of characters with special syntax as defined in
+   this standard. The body is simply a sequence of characters that
+   follows the header and is separated from the header by an empty line
+   (i.e., a line with nothing preceding the CRLF).
+
+2.1.1. Line Length Limits
+
+   There are two limits that this standard places on the number of
+   characters in a line. Each line of characters MUST be no more than
+   998 characters, and SHOULD be no more than 78 characters, excluding
+   the CRLF.
+
+   The 998 character limit is due to limitations in many implementations
+   which send, receive, or store Internet Message Format messages that
+   simply cannot handle more than 998 characters on a line. Receiving
+   implementations would do well to handle an arbitrarily large number
+   of characters in a line for robustness sake. However, there are so
+   many implementations which (in compliance with the transport
+   requirements of [RFC2821]) do not accept messages containing more
+   than 1000 character including the CR and LF per line, it is important
+   for implementations not to create such messages.
+
+   The more conservative 78 character recommendation is to accommodate
+   the many implementations of user interfaces that display these
+   messages which may truncate, or disastrously wrap, the display of
+   more than 78 characters per line, in spite of the fact that such
+   implementations are non-conformant to the intent of this
+   specification (and that of [RFC2821] if they actually cause
+   information to be lost). Again, even though this limitation is put on
+   messages, it is encumbant upon implementations which display messages
+
+
+
+
+
+Resnick                     Standards Track                     [Page 6]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   to handle an arbitrarily large number of characters in a line
+   (certainly at least up to the 998 character limit) for the sake of
+   robustness.
+
+2.2. Header Fields
+
+   Header fields are lines composed of a field name, followed by a colon
+   (":"), followed by a field body, and terminated by CRLF.  A field
+   name MUST be composed of printable US-ASCII characters (i.e.,
+   characters that have values between 33 and 126, inclusive), except
+   colon.  A field body may be composed of any US-ASCII characters,
+   except for CR and LF.  However, a field body may contain CRLF when
+   used in header "folding" and  "unfolding" as described in section
+   2.2.3.  All field bodies MUST conform to the syntax described in
+   sections 3 and 4 of this standard.
+
+2.2.1. Unstructured Header Field Bodies
+
+   Some field bodies in this standard are defined simply as
+   "unstructured" (which is specified below as any US-ASCII characters,
+   except for CR and LF) with no further restrictions.  These are
+   referred to as unstructured field bodies.  Semantically, unstructured
+   field bodies are simply to be treated as a single line of characters
+   with no further processing (except for header "folding" and
+   "unfolding" as described in section 2.2.3).
+
+2.2.2. Structured Header Field Bodies
+
+   Some field bodies in this standard have specific syntactical
+   structure more restrictive than the unstructured field bodies
+   described above. These are referred to as "structured" field bodies.
+   Structured field bodies are sequences of specific lexical tokens as
+   described in sections 3 and 4 of this standard.  Many of these tokens
+   are allowed (according to their syntax) to be introduced or end with
+   comments (as described in section 3.2.3) as well as the space (SP,
+   ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
+   (together known as the white space characters, WSP), and those WSP
+   characters are subject to header "folding" and "unfolding" as
+   described in section 2.2.3.  Semantic analysis of structured field
+   bodies is given along with their syntax.
+
+2.2.3. Long Header Fields
+
+   Each header field is logically a single line of characters comprising
+   the field name, the colon, and the field body.  For convenience
+   however, and to deal with the 998/78 character limitations per line,
+   the field body portion of a header field can be split into a multiple
+   line representation; this is called "folding".  The general rule is
+
+
+
+Resnick                     Standards Track                     [Page 7]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   that wherever this standard allows for folding white space (not
+   simply WSP characters), a CRLF may be inserted before any WSP.  For
+   example, the header field:
+
+           Subject: This is a test
+
+   can be represented as:
+
+           Subject: This
+            is a test
+
+   Note: Though structured field bodies are defined in such a way that
+   folding can take place between many of the lexical tokens (and even
+   within some of the lexical tokens), folding SHOULD be limited to
+   placing the CRLF at higher-level syntactic breaks.  For instance, if
+   a field body is defined as comma-separated values, it is recommended
+   that folding occur after the comma separating the structured items in
+   preference to other places where the field could be folded, even if
+   it is allowed elsewhere.
+
+   The process of moving from this folded multiple-line representation
+   of a header field to its single line representation is called
+   "unfolding". Unfolding is accomplished by simply removing any CRLF
+   that is immediately followed by WSP.  Each header field should be
+   treated in its unfolded form for further syntactic and semantic
+   evaluation.
+
+2.3. Body
+
+   The body of a message is simply lines of US-ASCII characters.  The
+   only two limitations on the body are as follows:
+
+   - CR and LF MUST only occur together as CRLF; they MUST NOT appear
+     independently in the body.
+
+   - Lines of characters in the body MUST be limited to 998 characters,
+     and SHOULD be limited to 78 characters, excluding the CRLF.
+
+   Note: As was stated earlier, there are other standards documents,
+   specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049]
+   that extend this standard to allow for different sorts of message
+   bodies.  Again, these mechanisms are beyond the scope of this
+   document.
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 8]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+3. Syntax
+
+3.1. Introduction
+
+   The syntax as given in this section defines the legal syntax of
+   Internet messages.  Messages that are conformant to this standard
+   MUST conform to the syntax in this section.  If there are options in
+   this section where one option SHOULD be generated, that is indicated
+   either in the prose or in a comment next to the syntax.
+
+   For the defined expressions, a short description of the syntax and
+   use is given, followed by the syntax in ABNF, followed by a semantic
+   analysis.  Primitive tokens that are used but otherwise unspecified
+   come from [RFC2234].
+
+   In some of the definitions, there will be nonterminals whose names
+   start with "obs-".  These "obs-" elements refer to tokens defined in
+   the obsolete syntax in section 4.  In all cases, these productions
+   are to be ignored for the purposes of generating legal Internet
+   messages and MUST NOT be used as part of such a message.  However,
+   when interpreting messages, these tokens MUST be honored as part of
+   the legal syntax.  In this sense, section 3 defines a grammar for
+   generation of messages, with "obs-" elements that are to be ignored,
+   while section 4 adds grammar for interpretation of messages.
+
+3.2. Lexical Tokens
+
+   The following rules are used to define an underlying lexical
+   analyzer, which feeds tokens to the higher-level parsers.  This
+   section defines the tokens used in structured header field bodies.
+
+   Note: Readers of this standard need to pay special attention to how
+   these lexical tokens are used in both the lower-level and
+   higher-level syntax later in the document.  Particularly, the white
+   space tokens and the comment tokens defined in section 3.2.3 get used
+   in the lower-level tokens defined here, and those lower-level tokens
+   are in turn used as parts of the higher-level tokens defined later.
+   Therefore, the white space and comments may be allowed in the
+   higher-level tokens even though they may not explicitly appear in a
+   particular definition.
+
+3.2.1. Primitive Tokens
+
+   The following are primitive tokens referred to elsewhere in this
+   standard, but not otherwise defined in [RFC2234].  Some of them will
+   not appear anywhere else in the syntax, but they are convenient to
+   refer to in other parts of this document.
+
+
+
+
+Resnick                     Standards Track                     [Page 9]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   Note: The "specials" below are just such an example.  Though the
+   specials token does not appear anywhere else in this standard, it is
+   useful for implementers who use tools that lexically analyze
+   messages.  Each of the characters in specials can be used to indicate
+   a tokenization point in lexical analysis.
+
+NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
+                        %d11 /          ;  that do not include the
+                        %d12 /          ;  carriage return, line feed,
+                        %d14-31 /       ;  and white space characters
+                        %d127
+
+text            =       %d1-9 /         ; Characters excluding CR and LF
+                        %d11 /
+                        %d12 /
+                        %d14-127 /
+                        obs-text
+
+specials        =       "(" / ")" /     ; Special characters used in
+                        "<" / ">" /     ;  other parts of the syntax
+                        "[" / "]" /
+                        ":" / ";" /
+                        "@" / "\" /
+                        "," / "." /
+                        DQUOTE
+
+   No special semantics are attached to these tokens.  They are simply
+   single characters.
+
+3.2.2. Quoted characters
+
+   Some characters are reserved for special interpretation, such as
+   delimiting lexical tokens.  To permit use of these characters as
+   uninterpreted data, a quoting mechanism is provided.
+
+quoted-pair     =       ("\" text) / obs-qp
+
+   Where any quoted-pair appears, it is to be interpreted as the text
+   character alone.  That is to say, the "\" character that appears as
+   part of a quoted-pair is semantically "invisible".
+
+   Note: The "\" character may appear in a message where it is not part
+   of a quoted-pair.  A "\" character that does not appear in a
+   quoted-pair is not semantically invisible.  The only places in this
+   standard where quoted-pair currently appears are ccontent, qcontent,
+   dcontent, no-fold-quote, and no-fold-literal.
+
+
+
+
+
+Resnick                     Standards Track                    [Page 10]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+3.2.3. Folding white space and comments
+
+   White space characters, including white space used in folding
+   (described in section 2.2.3), may appear between many elements in
+   header field bodies.  Also, strings of characters that are treated as
+   comments may be included in structured field bodies as characters
+   enclosed in parentheses.  The following defines the folding white
+   space (FWS) and comment constructs.
+
+   Strings of characters enclosed in parentheses are considered comments
+   so long as they do not appear within a "quoted-string", as defined in
+   section 3.2.5.  Comments may nest.
+
+   There are several places in this standard where comments and FWS may
+   be freely inserted.  To accommodate that syntax, an additional token
+   for "CFWS" is defined for places where comments and/or FWS can occur.
+   However, where CFWS occurs in this standard, it MUST NOT be inserted
+   in such a way that any line of a folded header field is made up
+   entirely of WSP characters and nothing else.
+
+FWS             =       ([*WSP CRLF] 1*WSP) /   ; Folding white space
+                        obs-FWS
+
+ctext           =       NO-WS-CTL /     ; Non white space controls
+
+                        %d33-39 /       ; The rest of the US-ASCII
+                        %d42-91 /       ;  characters not including "(",
+                        %d93-126        ;  ")", or "\"
+
+ccontent        =       ctext / quoted-pair / comment
+
+comment         =       "(" *([FWS] ccontent) [FWS] ")"
+
+CFWS            =       *([FWS] comment) (([FWS] comment) / FWS)
+
+   Throughout this standard, where FWS (the folding white space token)
+   appears, it indicates a place where header folding, as discussed in
+   section 2.2.3, may take place.  Wherever header folding appears in a
+   message (that is, a header field body containing a CRLF followed by
+   any WSP), header unfolding (removal of the CRLF) is performed before
+   any further lexical analysis is performed on that header field
+   according to this standard.  That is to say, any CRLF that appears in
+   FWS is semantically "invisible."
+
+   A comment is normally used in a structured field body to provide some
+   human readable informational text.  Since a comment is allowed to
+   contain FWS, folding is permitted within the comment.  Also note that
+   since quoted-pair is allowed in a comment, the parentheses and
+
+
+
+Resnick                     Standards Track                    [Page 11]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   backslash characters may appear in a comment so long as they appear
+   as a quoted-pair.  Semantically, the enclosing parentheses are not
+   part of the comment; the comment is what is contained between the two
+   parentheses.  As stated earlier, the "\" in any quoted-pair and the
+   CRLF in any FWS that appears within the comment are semantically
+   "invisible" and therefore not part of the comment either.
+
+   Runs of FWS, comment or CFWS that occur between lexical tokens in a
+   structured field header are semantically interpreted as a single
+   space character.
+
+3.2.4. Atom
+
+   Several productions in structured header field bodies are simply
+   strings of certain basic characters.  Such productions are called
+   atoms.
+
+   Some of the structured header field bodies also allow the period
+   character (".", ASCII value 46) within runs of atext.  An additional
+   "dot-atom" token is defined for those purposes.
+
+atext           =       ALPHA / DIGIT / ; Any character except controls,
+                        "!" / "#" /     ;  SP, and specials.
+                        "$" / "%" /     ;  Used for atoms
+                        "&" / "'" /
+                        "*" / "+" /
+                        "-" / "/" /
+                        "=" / "?" /
+                        "^" / "_" /
+                        "`" / "{" /
+                        "|" / "}" /
+                        "~"
+
+atom            =       [CFWS] 1*atext [CFWS]
+
+dot-atom        =       [CFWS] dot-atom-text [CFWS]
+
+dot-atom-text   =       1*atext *("." 1*atext)
+
+   Both atom and dot-atom are interpreted as a single unit, comprised of
+   the string of characters that make it up.  Semantically, the optional
+   comments and FWS surrounding the rest of the characters are not part
+   of the atom; the atom is only the run of atext characters in an atom,
+   or the atext and "." characters in a dot-atom.
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 12]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+3.2.5. Quoted strings
+
+   Strings of characters that include characters other than those
+   allowed in atoms may be represented in a quoted string format, where
+   the characters are surrounded by quote (DQUOTE, ASCII value 34)
+   characters.
+
+qtext           =       NO-WS-CTL /     ; Non white space controls
+
+                        %d33 /          ; The rest of the US-ASCII
+                        %d35-91 /       ;  characters not including "\"
+                        %d93-126        ;  or the quote character
+
+qcontent        =       qtext / quoted-pair
+
+quoted-string   =       [CFWS]
+                        DQUOTE *([FWS] qcontent) [FWS] DQUOTE
+                        [CFWS]
+
+   A quoted-string is treated as a unit.  That is, quoted-string is
+   identical to atom, semantically.  Since a quoted-string is allowed to
+   contain FWS, folding is permitted.  Also note that since quoted-pair
+   is allowed in a quoted-string, the quote and backslash characters may
+   appear in a quoted-string so long as they appear as a quoted-pair.
+
+   Semantically, neither the optional CFWS outside of the quote
+   characters nor the quote characters themselves are part of the
+   quoted-string; the quoted-string is what is contained between the two
+   quote characters.  As stated earlier, the "\" in any quoted-pair and
+   the CRLF in any FWS/CFWS that appears within the quoted-string are
+   semantically "invisible" and therefore not part of the quoted-string
+   either.
+
+3.2.6. Miscellaneous tokens
+
+   Three additional tokens are defined, word and phrase for combinations
+   of atoms and/or quoted-strings, and unstructured for use in
+   unstructured header fields and in some places within structured
+   header fields.
+
+word            =       atom / quoted-string
+
+phrase          =       1*word / obs-phrase
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 13]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+utext           =       NO-WS-CTL /     ; Non white space controls
+                        %d33-126 /      ; The rest of US-ASCII
+                        obs-utext
+
+unstructured    =       *([FWS] utext) [FWS]
+
+3.3. Date and Time Specification
+
+   Date and time occur in several header fields.  This section specifies
+   the syntax for a full date and time specification.  Though folding
+   white space is permitted throughout the date-time specification, it
+   is RECOMMENDED that a single space be used in each place that FWS
+   appears (whether it is required or optional); some older
+   implementations may not interpret other occurrences of folding white
+   space correctly.
+
+date-time       =       [ day-of-week "," ] date FWS time [CFWS]
+
+day-of-week     =       ([FWS] day-name) / obs-day-of-week
+
+day-name        =       "Mon" / "Tue" / "Wed" / "Thu" /
+                        "Fri" / "Sat" / "Sun"
+
+date            =       day month year
+
+year            =       4*DIGIT / obs-year
+
+month           =       (FWS month-name FWS) / obs-month
+
+month-name      =       "Jan" / "Feb" / "Mar" / "Apr" /
+                        "May" / "Jun" / "Jul" / "Aug" /
+                        "Sep" / "Oct" / "Nov" / "Dec"
+
+day             =       ([FWS] 1*2DIGIT) / obs-day
+
+time            =       time-of-day FWS zone
+
+time-of-day     =       hour ":" minute [ ":" second ]
+
+hour            =       2DIGIT / obs-hour
+
+minute          =       2DIGIT / obs-minute
+
+second          =       2DIGIT / obs-second
+
+zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone
+
+
+
+
+
+Resnick                     Standards Track                    [Page 14]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   The day is the numeric day of the month.  The year is any numeric
+   year 1900 or later.
+
+   The time-of-day specifies the number of hours, minutes, and
+   optionally seconds since midnight of the date indicated.
+
+   The date and time-of-day SHOULD express local time.
+
+   The zone specifies the offset from Coordinated Universal Time (UTC,
+   formerly referred to as "Greenwich Mean Time") that the date and
+   time-of-day represent.  The "+" or "-" indicates whether the
+   time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
+   Universal Time.  The first two digits indicate the number of hours
+   difference from Universal Time, and the last two digits indicate the
+   number of minutes difference from Universal Time.  (Hence, +hhmm
+   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
+   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
+   Universal Time.  Though "-0000" also indicates Universal Time, it is
+   used to indicate that the time was generated on a system that may be
+   in a local time zone other than Universal Time and therefore
+   indicates that the date-time contains no information about the local
+   time zone.
+
+   A date-time specification MUST be semantically valid.  That is, the
+   day-of-the-week (if included) MUST be the day implied by the date,
+   the numeric day-of-month MUST be between 1 and the number of days
+   allowed for the specified month (in the specified year), the
+   time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
+   number of seconds allowing for a leap second; see [STD12]), and the
+   zone MUST be within the range -9959 through +9959.
+
+3.4. Address Specification
+
+   Addresses occur in several message header fields to indicate senders
+   and recipients of messages.  An address may either be an individual
+   mailbox, or a group of mailboxes.
+
+address         =       mailbox / group
+
+mailbox         =       name-addr / addr-spec
+
+name-addr       =       [display-name] angle-addr
+
+angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
+
+group           =       display-name ":" [mailbox-list / CFWS] ";"
+                        [CFWS]
+
+
+
+
+Resnick                     Standards Track                    [Page 15]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+display-name    =       phrase
+
+mailbox-list    =       (mailbox *("," mailbox)) / obs-mbox-list
+
+address-list    =       (address *("," address)) / obs-addr-list
+
+   A mailbox receives mail.  It is a conceptual entity which does not
+   necessarily pertain to file storage.  For example, some sites may
+   choose to print mail on a printer and deliver the output to the
+   addressee's desk.  Normally, a mailbox is comprised of two parts: (1)
+   an optional display name that indicates the name of the recipient
+   (which could be a person or a system) that could be displayed to the
+   user of a mail application, and (2) an addr-spec address enclosed in
+   angle brackets ("<" and ">").  There is also an alternate simple form
+   of a mailbox where the addr-spec address appears alone, without the
+   recipient's name or the angle brackets.  The Internet addr-spec
+   address is described in section 3.4.1.
+
+   Note: Some legacy implementations used the simple form where the
+   addr-spec appears without the angle brackets, but included the name
+   of the recipient in parentheses as a comment following the addr-spec.
+   Since the meaning of the information in a comment is unspecified,
+   implementations SHOULD use the full name-addr form of the mailbox,
+   instead of the legacy form, to specify the display name associated
+   with a mailbox.  Also, because some legacy implementations interpret
+   the comment, comments generally SHOULD NOT be used in address fields
+   to avoid confusing such implementations.
+
+   When it is desirable to treat several mailboxes as a single unit
+   (i.e., in a distribution list), the group construct can be used.  The
+   group construct allows the sender to indicate a named group of
+   recipients. This is done by giving a display name for the group,
+   followed by a colon, followed by a comma separated list of any number
+   of mailboxes (including zero and one), and ending with a semicolon.
+   Because the list of mailboxes can be empty, using the group construct
+   is also a simple way to communicate to recipients that the message
+   was sent to one or more named sets of recipients, without actually
+   providing the individual mailbox address for each of those
+   recipients.
+
+3.4.1. Addr-spec specification
+
+   An addr-spec is a specific Internet identifier that contains a
+   locally interpreted string followed by the at-sign character ("@",
+   ASCII value 64) followed by an Internet domain.  The locally
+   interpreted string is either a quoted-string or a dot-atom.  If the
+   string can be represented as a dot-atom (that is, it contains no
+   characters other than atext characters or "." surrounded by atext
+
+
+
+Resnick                     Standards Track                    [Page 16]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   characters), then the dot-atom form SHOULD be used and the
+   quoted-string form SHOULD NOT be used. Comments and folding white
+   space SHOULD NOT be used around the "@" in the addr-spec.
+
+addr-spec       =       local-part "@" domain
+
+local-part      =       dot-atom / quoted-string / obs-local-part
+
+domain          =       dot-atom / domain-literal / obs-domain
+
+domain-literal  =       [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
+
+dcontent        =       dtext / quoted-pair
+
+dtext           =       NO-WS-CTL /     ; Non white space controls
+
+                        %d33-90 /       ; The rest of the US-ASCII
+                        %d94-126        ;  characters not including "[",
+                                        ;  "]", or "\"
+
+   The domain portion identifies the point to which the mail is
+   delivered. In the dot-atom form, this is interpreted as an Internet
+   domain name (either a host name or a mail exchanger name) as
+   described in [STD3, STD13, STD14].  In the domain-literal form, the
+   domain is interpreted as the literal Internet address of the
+   particular host.  In both cases, how addressing is used and how
+   messages are transported to a particular host is covered in the mail
+   transport document [RFC2821].  These mechanisms are outside of the
+   scope of this document.
+
+   The local-part portion is a domain dependent string.  In addresses,
+   it is simply interpreted on the particular host as a name of a
+   particular mailbox.
+
+3.5 Overall message syntax
+
+   A message consists of header fields, optionally followed by a message
+   body.  Lines in a message MUST be a maximum of 998 characters
+   excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
+   characters excluding the CRLF.  (See section 2.1.1 for explanation.)
+   In a message body, though all of the characters listed in the text
+   rule MAY be used, the use of US-ASCII control characters (values 1
+   through 8, 11, 12, and 14 through 31) is discouraged since their
+   interpretation by receivers for display is not guaranteed.
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 17]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+message         =       (fields / obs-fields)
+                        [CRLF body]
+
+body            =       *(*998text CRLF) *998text
+
+   The header fields carry most of the semantic information and are
+   defined in section 3.6.  The body is simply a series of lines of text
+   which are uninterpreted for the purposes of this standard.
+
+3.6. Field definitions
+
+   The header fields of a message are defined here.  All header fields
+   have the same general syntactic structure: A field name, followed by
+   a colon, followed by the field body.  The specific syntax for each
+   header field is defined in the subsequent sections.
+
+   Note: In the ABNF syntax for each field in subsequent sections, each
+   field name is followed by the required colon.  However, for brevity
+   sometimes the colon is not referred to in the textual description of
+   the syntax.  It is, nonetheless, required.
+
+   It is important to note that the header fields are not guaranteed to
+   be in a particular order.  They may appear in any order, and they
+   have been known to be reordered occasionally when transported over
+   the Internet.  However, for the purposes of this standard, header
+   fields SHOULD NOT be reordered when a message is transported or
+   transformed.  More importantly, the trace header fields and resent
+   header fields MUST NOT be reordered, and SHOULD be kept in blocks
+   prepended to the message.  See sections 3.6.6 and 3.6.7 for more
+   information.
+
+   The only required header fields are the origination date field and
+   the originator address field(s).  All other header fields are
+   syntactically optional.  More information is contained in the table
+   following this definition.
+
+fields          =       *(trace
+                          *(resent-date /
+                           resent-from /
+                           resent-sender /
+                           resent-to /
+                           resent-cc /
+                           resent-bcc /
+                           resent-msg-id))
+                        *(orig-date /
+                        from /
+                        sender /
+                        reply-to /
+
+
+
+Resnick                     Standards Track                    [Page 18]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+                        to /
+                        cc /
+                        bcc /
+                        message-id /
+                        in-reply-to /
+                        references /
+                        subject /
+                        comments /
+                        keywords /
+                        optional-field)
+
+   The following table indicates limits on the number of times each
+   field may occur in a message header as well as any special
+   limitations on the use of those fields.  An asterisk next to a value
+   in the minimum or maximum column indicates that a special restriction
+   appears in the Notes column.
+
+Field           Min number      Max number      Notes
+
+trace           0               unlimited       Block prepended - see
+                                                3.6.7
+
+resent-date     0*              unlimited*      One per block, required
+                                                if other resent fields
+                                                present - see 3.6.6
+
+resent-from     0               unlimited*      One per block - see
+                                                3.6.6
+
+resent-sender   0*              unlimited*      One per block, MUST
+                                                occur with multi-address
+                                                resent-from - see 3.6.6
+
+resent-to       0               unlimited*      One per block - see
+                                                3.6.6
+
+resent-cc       0               unlimited*      One per block - see
+                                                3.6.6
+
+resent-bcc      0               unlimited*      One per block - see
+                                                3.6.6
+
+resent-msg-id   0               unlimited*      One per block - see
+                                                3.6.6
+
+orig-date       1               1
+
+from            1               1               See sender and 3.6.2
+
+
+
+Resnick                     Standards Track                    [Page 19]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+sender          0*              1               MUST occur with multi-
+                                                address from - see 3.6.2
+
+reply-to        0               1
+
+to              0               1
+
+cc              0               1
+
+bcc             0               1
+
+message-id      0*              1               SHOULD be present - see
+                                                3.6.4
+
+in-reply-to     0*              1               SHOULD occur in some
+                                                replies - see 3.6.4
+
+references      0*              1               SHOULD occur in some
+                                                replies - see 3.6.4
+
+subject         0               1
+
+comments        0               unlimited
+
+keywords        0               unlimited
+
+optional-field  0               unlimited
+
+   The exact interpretation of each field is described in subsequent
+   sections.
+
+3.6.1. The origination date field
+
+   The origination date field consists of the field name "Date" followed
+   by a date-time specification.
+
+orig-date       =       "Date:" date-time CRLF
+
+   The origination date specifies the date and time at which the creator
+   of the message indicated that the message was complete and ready to
+   enter the mail delivery system.  For instance, this might be the time
+   that a user pushes the "send" or "submit" button in an application
+   program.  In any case, it is specifically not intended to convey the
+   time that the message is actually transported, but rather the time at
+   which the human or other creator of the message has put the message
+   into its final form, ready for transport.  (For example, a portable
+   computer user who is not connected to a network might queue a message
+
+
+
+
+Resnick                     Standards Track                    [Page 20]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   for delivery.  The origination date is intended to contain the date
+   and time that the user queued the message, not the time when the user
+   connected to the network to send the message.)
+
+3.6.2. Originator fields
+
+   The originator fields of a message consist of the from field, the
+   sender field (when applicable), and optionally the reply-to field.
+   The from field consists of the field name "From" and a
+   comma-separated list of one or more mailbox specifications.  If the
+   from field contains more than one mailbox specification in the
+   mailbox-list, then the sender field, containing the field name
+   "Sender" and a single mailbox specification, MUST appear in the
+   message.  In either case, an optional reply-to field MAY also be
+   included, which contains the field name "Reply-To" and a
+   comma-separated list of one or more addresses.
+
+from            =       "From:" mailbox-list CRLF
+
+sender          =       "Sender:" mailbox CRLF
+
+reply-to        =       "Reply-To:" address-list CRLF
+
+   The originator fields indicate the mailbox(es) of the source of the
+   message.  The "From:" field specifies the author(s) of the message,
+   that is, the mailbox(es) of the person(s) or system(s) responsible
+   for the writing of the message.  The "Sender:" field specifies the
+   mailbox of the agent responsible for the actual transmission of the
+   message.  For example, if a secretary were to send a message for
+   another person, the mailbox of the secretary would appear in the
+   "Sender:" field and the mailbox of the actual author would appear in
+   the "From:" field.  If the originator of the message can be indicated
+   by a single mailbox and the author and transmitter are identical, the
+   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
+   appear.
+
+   The originator fields also provide the information required when
+   replying to a message.  When the "Reply-To:" field is present, it
+   indicates the mailbox(es) to which the author of the message suggests
+   that replies be sent.  In the absence of the "Reply-To:" field,
+   replies SHOULD by default be sent to the mailbox(es) specified in the
+   "From:" field unless otherwise specified by the person composing the
+   reply.
+
+   In all cases, the "From:" field SHOULD NOT contain any mailbox that
+   does not belong to the author(s) of the message.  See also section
+   3.6.3 for more information on forming the destination addresses for a
+   reply.
+
+
+
+Resnick                     Standards Track                    [Page 21]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+3.6.3. Destination address fields
+
+   The destination fields of a message consist of three possible fields,
+   each of the same form: The field name, which is either "To", "Cc", or
+   "Bcc", followed by a comma-separated list of one or more addresses
+   (either mailbox or group syntax).
+
+to              =       "To:" address-list CRLF
+
+cc              =       "Cc:" address-list CRLF
+
+bcc             =       "Bcc:" (address-list / [CFWS]) CRLF
+
+   The destination fields specify the recipients of the message.  Each
+   destination field may have one or more addresses, and each of the
+   addresses indicate the intended recipients of the message.  The only
+   difference between the three fields is how each is used.
+
+   The "To:" field contains the address(es) of the primary recipient(s)
+   of the message.
+
+   The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
+   making a copy on a typewriter using carbon paper) contains the
+   addresses of others who are to receive the message, though the
+   content of the message may not be directed at them.
+
+   The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
+   addresses of recipients of the message whose addresses are not to be
+   revealed to other recipients of the message.  There are three ways in
+   which the "Bcc:" field is used.  In the first case, when a message
+   containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
+   removed even though all of the recipients (including those specified
+   in the "Bcc:" field) are sent a copy of the message.  In the second
+   case, recipients specified in the "To:" and "Cc:" lines each are sent
+   a copy of the message with the "Bcc:" line removed as above, but the
+   recipients on the "Bcc:" line get a separate copy of the message
+   containing a "Bcc:" line.  (When there are multiple recipient
+   addresses in the "Bcc:" field, some implementations actually send a
+   separate copy of the message to each recipient with a "Bcc:"
+   containing only the address of that particular recipient.) Finally,
+   since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
+   sent without any addresses indicating to the recipients that blind
+   copies were sent to someone.  Which method to use with "Bcc:" fields
+   is implementation dependent, but refer to the "Security
+   Considerations" section of this document for a discussion of each.
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 22]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   When a message is a reply to another message, the mailboxes of the
+   authors of the original message (the mailboxes in the "From:" field)
+   or mailboxes specified in the "Reply-To:" field (if it exists) MAY
+   appear in the "To:" field of the reply since these would normally be
+   the primary recipients of the reply.  If a reply is sent to a message
+   that has destination fields, it is often desirable to send a copy of
+   the reply to all of the recipients of the message, in addition to the
+   author.  When such a reply is formed, addresses in the "To:" and
+   "Cc:" fields of the original message MAY appear in the "Cc:" field of
+   the reply, since these are normally secondary recipients of the
+   reply.  If a "Bcc:" field is present in the original message,
+   addresses in that field MAY appear in the "Bcc:" field of the reply,
+   but SHOULD NOT appear in the "To:" or "Cc:" fields.
+
+   Note: Some mail applications have automatic reply commands that
+   include the destination addresses of the original message in the
+   destination addresses of the reply.  How those reply commands behave
+   is implementation dependent and is beyond the scope of this document.
+   In particular, whether or not to include the original destination
+   addresses when the original message had a "Reply-To:" field is not
+   addressed here.
+
+3.6.4. Identification fields
+
+   Though optional, every message SHOULD have a "Message-ID:" field.
+   Furthermore, reply messages SHOULD have "In-Reply-To:" and
+   "References:" fields as appropriate, as described below.
+
+   The "Message-ID:" field contains a single unique message identifier.
+   The "References:" and "In-Reply-To:" field each contain one or more
+   unique message identifiers, optionally separated by CFWS.
+
+   The message identifier (msg-id) is similar in syntax to an angle-addr
+   construct without the internal CFWS.
+
+message-id      =       "Message-ID:" msg-id CRLF
+
+in-reply-to     =       "In-Reply-To:" 1*msg-id CRLF
+
+references      =       "References:" 1*msg-id CRLF
+
+msg-id          =       [CFWS] "<" id-left "@" id-right ">" [CFWS]
+
+id-left         =       dot-atom-text / no-fold-quote / obs-id-left
+
+id-right        =       dot-atom-text / no-fold-literal / obs-id-right
+
+no-fold-quote   =       DQUOTE *(qtext / quoted-pair) DQUOTE
+
+
+
+Resnick                     Standards Track                    [Page 23]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+no-fold-literal =       "[" *(dtext / quoted-pair) "]"
+
+   The "Message-ID:" field provides a unique message identifier that
+   refers to a particular version of a particular message.  The
+   uniqueness of the message identifier is guaranteed by the host that
+   generates it (see below).  This message identifier is intended to be
+   machine readable and not necessarily meaningful to humans.  A message
+   identifier pertains to exactly one instantiation of a particular
+   message; subsequent revisions to the message each receive new message
+   identifiers.
+
+   Note: There are many instances when messages are "changed", but those
+   changes do not constitute a new instantiation of that message, and
+   therefore the message would not get a new message identifier.  For
+   example, when messages are introduced into the transport system, they
+   are often prepended with additional header fields such as trace
+   fields (described in section 3.6.7) and resent fields (described in
+   section 3.6.6).  The addition of such header fields does not change
+   the identity of the message and therefore the original "Message-ID:"
+   field is retained.  In all cases, it is the meaning that the sender
+   of the message wishes to convey (i.e., whether this is the same
+   message or a different message) that determines whether or not the
+   "Message-ID:" field changes, not any particular syntactic difference
+   that appears (or does not appear) in the message.
+
+   The "In-Reply-To:" and "References:" fields are used when creating a
+   reply to a message.  They hold the message identifier of the original
+   message and the message identifiers of other messages (for example,
+   in the case of a reply to a message which was itself a reply).  The
+   "In-Reply-To:" field may be used to identify the message (or
+   messages) to which the new message is a reply, while the
+   "References:" field may be used to identify a "thread" of
+   conversation.
+
+   When creating a reply to a message, the "In-Reply-To:" and
+   "References:" fields of the resultant message are constructed as
+   follows:
+
+   The "In-Reply-To:" field will contain the contents of the "Message-
+   ID:" field of the message to which this one is a reply (the "parent
+   message").  If there is more than one parent message, then the "In-
+   Reply-To:" field will contain the contents of all of the parents'
+   "Message-ID:" fields.  If there is no "Message-ID:" field in any of
+   the parent messages, then the new message will have no "In-Reply-To:"
+   field.
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 24]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   The "References:" field will contain the contents of the parent's
+   "References:" field (if any) followed by the contents of the parent's
+   "Message-ID:" field (if any).  If the parent message does not contain
+   a "References:" field but does have an "In-Reply-To:" field
+   containing a single message identifier, then the "References:" field
+   will contain the contents of the parent's "In-Reply-To:" field
+   followed by the contents of the parent's "Message-ID:" field (if
+   any).  If the parent has none of the "References:", "In-Reply-To:",
+   or "Message-ID:" fields, then the new message will have no
+   "References:" field.
+
+   Note: Some implementations parse the "References:" field to display
+   the "thread of the discussion".  These implementations assume that
+   each new message is a reply to a single parent and hence that they
+   can walk backwards through the "References:" field to find the parent
+   of each message listed there.  Therefore, trying to form a
+   "References:" field for a reply that has multiple parents is
+   discouraged and how to do so is not defined in this document.
+
+   The message identifier (msg-id) itself MUST be a globally unique
+   identifier for a message.  The generator of the message identifier
+   MUST guarantee that the msg-id is unique.  There are several
+   algorithms that can be used to accomplish this.  Since the msg-id has
+   a similar syntax to angle-addr (identical except that comments and
+   folding white space are not allowed), a good method is to put the
+   domain name (or a domain literal IP address) of the host on which the
+   message identifier was created on the right hand side of the "@", and
+   put a combination of the current absolute date and time along with
+   some other currently unique (perhaps sequential) identifier available
+   on the system (for example, a process id number) on the left hand
+   side.  Using a date on the left hand side and a domain name or domain
+   literal on the right hand side makes it possible to guarantee
+   uniqueness since no two hosts use the same domain name or IP address
+   at the same time.  Though other algorithms will work, it is
+   RECOMMENDED that the right hand side contain some domain identifier
+   (either of the host itself or otherwise) such that the generator of
+   the message identifier can guarantee the uniqueness of the left hand
+   side within the scope of that domain.
+
+   Semantically, the angle bracket characters are not part of the
+   msg-id; the msg-id is what is contained between the two angle bracket
+   characters.
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 25]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+3.6.5. Informational fields
+
+   The informational fields are all optional.  The "Keywords:" field
+   contains a comma-separated list of one or more words or
+   quoted-strings. The "Subject:" and "Comments:" fields are
+   unstructured fields as defined in section 2.2.1, and therefore may
+   contain text or folding white space.
+
+subject         =       "Subject:" unstructured CRLF
+
+comments        =       "Comments:" unstructured CRLF
+
+keywords        =       "Keywords:" phrase *("," phrase) CRLF
+
+   These three fields are intended to have only human-readable content
+   with information about the message.  The "Subject:" field is the most
+   common and contains a short string identifying the topic of the
+   message.  When used in a reply, the field body MAY start with the
+   string "Re: " (from the Latin "res", in the matter of) followed by
+   the contents of the "Subject:" field body of the original message.
+   If this is done, only one instance of the literal string "Re: " ought
+   to be used since use of other strings or more than one instance can
+   lead to undesirable consequences.  The "Comments:" field contains any
+   additional comments on the text of the body of the message.  The
+   "Keywords:" field contains a comma-separated list of important words
+   and phrases that might be useful for the recipient.
+
+3.6.6. Resent fields
+
+   Resent fields SHOULD be added to any message that is reintroduced by
+   a user into the transport system.  A separate set of resent fields
+   SHOULD be added each time this is done.  All of the resent fields
+   corresponding to a particular resending of the message SHOULD be
+   together.  Each new set of resent fields is prepended to the message;
+   that is, the most recent set of resent fields appear earlier in the
+   message.  No other fields in the message are changed when resent
+   fields are added.
+
+   Each of the resent fields corresponds to a particular field elsewhere
+   in the syntax.  For instance, the "Resent-Date:" field corresponds to
+   the "Date:" field and the "Resent-To:" field corresponds to the "To:"
+   field.  In each case, the syntax for the field body is identical to
+   the syntax given previously for the corresponding field.
+
+   When resent fields are used, the "Resent-From:" and "Resent-Date:"
+   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.
+   "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
+   identical to "Resent-From:".
+
+
+
+Resnick                     Standards Track                    [Page 26]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+resent-date     =       "Resent-Date:" date-time CRLF
+
+resent-from     =       "Resent-From:" mailbox-list CRLF
+
+resent-sender   =       "Resent-Sender:" mailbox CRLF
+
+resent-to       =       "Resent-To:" address-list CRLF
+
+resent-cc       =       "Resent-Cc:" address-list CRLF
+
+resent-bcc      =       "Resent-Bcc:" (address-list / [CFWS]) CRLF
+
+resent-msg-id   =       "Resent-Message-ID:" msg-id CRLF
+
+   Resent fields are used to identify a message as having been
+   reintroduced into the transport system by a user.  The purpose of
+   using resent fields is to have the message appear to the final
+   recipient as if it were sent directly by the original sender, with
+   all of the original fields remaining the same.  Each set of resent
+   fields correspond to a particular resending event.  That is, if a
+   message is resent multiple times, each set of resent fields gives
+   identifying information for each individual time.  Resent fields are
+   strictly informational.  They MUST NOT be used in the normal
+   processing of replies or other such automatic actions on messages.
+
+   Note: Reintroducing a message into the transport system and using
+   resent fields is a different operation from "forwarding".
+   "Forwarding" has two meanings: One sense of forwarding is that a mail
+   reading program can be told by a user to forward a copy of a message
+   to another person, making the forwarded message the body of the new
+   message.  A forwarded message in this sense does not appear to have
+   come from the original sender, but is an entirely new message from
+   the forwarder of the message.  On the other hand, forwarding is also
+   used to mean when a mail transport program gets a message and
+   forwards it on to a different destination for final delivery.  Resent
+   header fields are not intended for use with either type of
+   forwarding.
+
+   The resent originator fields indicate the mailbox of the person(s) or
+   system(s) that resent the message.  As with the regular originator
+   fields, there are two forms: a simple "Resent-From:" form which
+   contains the mailbox of the individual doing the resending, and the
+   more complex form, when one individual (identified in the
+   "Resent-Sender:" field) resends a message on behalf of one or more
+   others (identified in the "Resent-From:" field).
+
+   Note: When replying to a resent message, replies behave just as they
+   would with any other message, using the original "From:",
+
+
+
+Resnick                     Standards Track                    [Page 27]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   "Reply-To:", "Message-ID:", and other fields.  The resent fields are
+   only informational and MUST NOT be used in the normal processing of
+   replies.
+
+   The "Resent-Date:" indicates the date and time at which the resent
+   message is dispatched by the resender of the message.  Like the
+   "Date:" field, it is not the date and time that the message was
+   actually transported.
+
+   The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
+   identically to the "To:", "Cc:", and "Bcc:" fields respectively,
+   except that they indicate the recipients of the resent message, not
+   the recipients of the original message.
+
+   The "Resent-Message-ID:" field provides a unique identifier for the
+   resent message.
+
+3.6.7. Trace fields
+
+   The trace fields are a group of header fields consisting of an
+   optional "Return-Path:" field, and one or more "Received:" fields.
+   The "Return-Path:" header field contains a pair of angle brackets
+   that enclose an optional addr-spec.  The "Received:" field contains a
+   (possibly empty) list of name/value pairs followed by a semicolon and
+   a date-time specification.  The first item of the name/value pair is
+   defined by item-name, and the second item is either an addr-spec, an
+   atom, a domain, or a msg-id.  Further restrictions may be applied to
+   the syntax of the trace fields by standards that provide for their
+   use, such as [RFC2821].
+
+trace           =       [return]
+                        1*received
+
+return          =       "Return-Path:" path CRLF
+
+path            =       ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) /
+                        obs-path
+
+received        =       "Received:" name-val-list ";" date-time CRLF
+
+name-val-list   =       [CFWS] [name-val-pair *(CFWS name-val-pair)]
+
+name-val-pair   =       item-name CFWS item-value
+
+item-name       =       ALPHA *(["-"] (ALPHA / DIGIT))
+
+item-value      =       1*angle-addr / addr-spec /
+                         atom / domain / msg-id
+
+
+
+Resnick                     Standards Track                    [Page 28]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   A full discussion of the Internet mail use of trace fields is
+   contained in [RFC2821].  For the purposes of this standard, the trace
+   fields are strictly informational, and any formal interpretation of
+   them is outside of the scope of this document.
+
+3.6.8. Optional fields
+
+   Fields may appear in messages that are otherwise unspecified in this
+   standard.  They MUST conform to the syntax of an optional-field.
+   This is a field name, made up of the printable US-ASCII characters
+   except SP and colon, followed by a colon, followed by any text which
+   conforms to unstructured.
+
+   The field names of any optional-field MUST NOT be identical to any
+   field name specified elsewhere in this standard.
+
+optional-field  =       field-name ":" unstructured CRLF
+
+field-name      =       1*ftext
+
+ftext           =       %d33-57 /               ; Any character except
+                        %d59-126                ;  controls, SP, and
+                                                ;  ":".
+
+   For the purposes of this standard, any optional field is
+   uninterpreted.
+
+4. Obsolete Syntax
+
+   Earlier versions of this standard allowed for different (usually more
+   liberal) syntax than is allowed in this version.  Also, there have
+   been syntactic elements used in messages on the Internet whose
+   interpretation have never been documented.  Though some of these
+   syntactic forms MUST NOT be generated according to the grammar in
+   section 3, they MUST be accepted and parsed by a conformant receiver.
+   This section documents many of these syntactic elements.  Taking the
+   grammar in section 3 and adding the definitions presented in this
+   section will result in the grammar to use for interpretation of
+   messages.
+
+   Note: This section identifies syntactic forms that any implementation
+   MUST reasonably interpret.  However, there are certainly Internet
+   messages which do not conform to even the additional syntax given in
+   this section.  The fact that a particular form does not appear in any
+   section of this document is not justification for computer programs
+   to crash or for malformed data to be irretrievably lost by any
+   implementation.  To repeat an example, though this document requires
+   lines in messages to be no longer than 998 characters, silently
+
+
+
+Resnick                     Standards Track                    [Page 29]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   discarding the 999th and subsequent characters in a line without
+   warning would still be bad behavior for an implementation.  It is up
+   to the implementation to deal with messages robustly.
+
+   One important difference between the obsolete (interpreting) and the
+   current (generating) syntax is that in structured header field bodies
+   (i.e., between the colon and the CRLF of any structured header
+   field), white space characters, including folding white space, and
+   comments can be freely inserted between any syntactic tokens.  This
+   allows many complex forms that have proven difficult for some
+   implementations to parse.
+
+   Another key difference between the obsolete and the current syntax is
+   that the rule in section 3.2.3 regarding lines composed entirely of
+   white space in comments and folding white space does not apply.  See
+   the discussion of folding white space in section 4.2 below.
+
+   Finally, certain characters that were formerly allowed in messages
+   appear in this section.  The NUL character (ASCII value 0) was once
+   allowed, but is no longer for compatibility reasons.  CR and LF were
+   allowed to appear in messages other than as CRLF; this use is also
+   shown here.
+
+   Other differences in syntax and semantics are noted in the following
+   sections.
+
+4.1. Miscellaneous obsolete tokens
+
+   These syntactic elements are used elsewhere in the obsolete syntax or
+   in the main syntax.  The obs-char and obs-qp elements each add ASCII
+   value 0. Bare CR and bare LF are added to obs-text and obs-utext.
+   The period character is added to obs-phrase. The obs-phrase-list
+   provides for "empty" elements in a comma-separated list of phrases.
+
+   Note: The "period" (or "full stop") character (".") in obs-phrase is
+   not a form that was allowed in earlier versions of this or any other
+   standard.  Period (nor any other character from specials) was not
+   allowed in phrase because it introduced a parsing difficulty
+   distinguishing between phrases and portions of an addr-spec (see
+   section 4.4).  It appears here because the period character is
+   currently used in many messages in the display-name portion of
+   addresses, especially for initials in names, and therefore must be
+   interpreted properly.  In the future, period may appear in the
+   regular syntax of phrase.
+
+obs-qp          =       "\" (%d0-127)
+
+obs-text        =       *LF *CR *(obs-char *LF *CR)
+
+
+
+Resnick                     Standards Track                    [Page 30]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+obs-char        =       %d0-9 / %d11 /          ; %d0-127 except CR and
+                        %d12 / %d14-127         ;  LF
+
+obs-utext       =       obs-text
+
+obs-phrase      =       word *(word / "." / CFWS)
+
+obs-phrase-list =       phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]
+
+   Bare CR and bare LF appear in messages with two different meanings.
+   In many cases, bare CR or bare LF are used improperly instead of CRLF
+   to indicate line separators.  In other cases, bare CR and bare LF are
+   used simply as ASCII control characters with their traditional ASCII
+   meanings.
+
+4.2. Obsolete folding white space
+
+   In the obsolete syntax, any amount of folding white space MAY be
+   inserted where the obs-FWS rule is allowed.  This creates the
+   possibility of having two consecutive "folds" in a line, and
+   therefore the possibility that a line which makes up a folded header
+   field could be composed entirely of white space.
+
+   obs-FWS         =       1*WSP *(CRLF 1*WSP)
+
+4.3. Obsolete Date and Time
+
+   The syntax for the obsolete date format allows a 2 digit year in the
+   date field and allows for a list of alphabetic time zone
+   specifications that were used in earlier versions of this standard.
+   It also permits comments and folding white space between many of the
+   tokens.
+
+obs-day-of-week =       [CFWS] day-name [CFWS]
+
+obs-year        =       [CFWS] 2*DIGIT [CFWS]
+
+obs-month       =       CFWS month-name CFWS
+
+obs-day         =       [CFWS] 1*2DIGIT [CFWS]
+
+obs-hour        =       [CFWS] 2DIGIT [CFWS]
+
+obs-minute      =       [CFWS] 2DIGIT [CFWS]
+
+obs-second      =       [CFWS] 2DIGIT [CFWS]
+
+obs-zone        =       "UT" / "GMT" /          ; Universal Time
+
+
+
+Resnick                     Standards Track                    [Page 31]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+                                                ; North American UT
+                                                ; offsets
+                        "EST" / "EDT" /         ; Eastern:  - 5/ - 4
+                        "CST" / "CDT" /         ; Central:  - 6/ - 5
+                        "MST" / "MDT" /         ; Mountain: - 7/ - 6
+                        "PST" / "PDT" /         ; Pacific:  - 8/ - 7
+
+                        %d65-73 /               ; Military zones - "A"
+                        %d75-90 /               ; through "I" and "K"
+                        %d97-105 /              ; through "Z", both
+                        %d107-122               ; upper and lower case
+
+   Where a two or three digit year occurs in a date, the year is to be
+   interpreted as follows: If a two digit year is encountered whose
+   value is between 00 and 49, the year is interpreted by adding 2000,
+   ending up with a value between 2000 and 2049.  If a two digit year is
+   encountered with a value between 50 and 99, or any three digit year
+   is encountered, the year is interpreted by adding 1900.
+
+   In the obsolete time zone, "UT" and "GMT" are indications of
+   "Universal Time" and "Greenwich Mean Time" respectively and are both
+   semantically identical to "+0000".
+
+   The remaining three character zones are the US time zones.  The first
+   letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
+   "Mountain" and "Pacific".  The second letter is either "S" for
+   "Standard" time, or "D" for "Daylight" (or summer) time.  Their
+   interpretations are as follows:
+
+   EDT is semantically equivalent to -0400
+   EST is semantically equivalent to -0500
+   CDT is semantically equivalent to -0500
+   CST is semantically equivalent to -0600
+   MDT is semantically equivalent to -0600
+   MST is semantically equivalent to -0700
+   PDT is semantically equivalent to -0700
+   PST is semantically equivalent to -0800
+
+   The 1 character military time zones were defined in a non-standard
+   way in [RFC822] and are therefore unpredictable in their meaning.
+   The original definitions of the military zones "A" through "I" are
+   equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
+   are equivalent to  "+1000", "+1100", and "+1200" respectively; "N"
+   through "Y" are equivalent to "-0100" through "-1200" respectively;
+   and "Z" is equivalent to "+0000".  However, because of the error in
+   [RFC822], they SHOULD all be considered equivalent to "-0000" unless
+   there is out-of-band information confirming their meaning.
+
+
+
+
+Resnick                     Standards Track                    [Page 32]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   Other multi-character (usually between 3 and 5) alphabetic time zones
+   have been used in Internet messages.  Any such time zone whose
+   meaning is not known SHOULD be considered equivalent to "-0000"
+   unless there is out-of-band information confirming their meaning.
+
+4.4. Obsolete Addressing
+
+   There are three primary differences in addressing.  First, mailbox
+   addresses were allowed to have a route portion before the addr-spec
+   when enclosed in "<" and ">".  The route is simply a comma-separated
+   list of domain names, each preceded by "@", and the list terminated
+   by a colon.  Second, CFWS were allowed between the period-separated
+   elements of local-part and domain (i.e., dot-atom was not used).  In
+   addition, local-part is allowed to contain quoted-string in addition
+   to just atom.  Finally, mailbox-list and address-list were allowed to
+   have "null" members.  That is, there could be two or more commas in
+   such a list with nothing in between them.
+
+obs-angle-addr  =       [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
+
+obs-route       =       [CFWS] obs-domain-list ":" [CFWS]
+
+obs-domain-list =       "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
+
+obs-local-part  =       word *("." word)
+
+obs-domain      =       atom *("." atom)
+
+obs-mbox-list   =       1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
+
+obs-addr-list   =       1*([address] [CFWS] "," [CFWS]) [address]
+
+   When interpreting addresses, the route portion SHOULD be ignored.
+
+4.5. Obsolete header fields
+
+   Syntactically, the primary difference in the obsolete field syntax is
+   that it allows multiple occurrences of any of the fields and they may
+   occur in any order.  Also, any amount of white space is allowed
+   before the ":" at the end of the field name.
+
+obs-fields      =       *(obs-return /
+                        obs-received /
+                        obs-orig-date /
+                        obs-from /
+                        obs-sender /
+                        obs-reply-to /
+                        obs-to /
+
+
+
+Resnick                     Standards Track                    [Page 33]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+                        obs-cc /
+                        obs-bcc /
+                        obs-message-id /
+                        obs-in-reply-to /
+                        obs-references /
+                        obs-subject /
+                        obs-comments /
+                        obs-keywords /
+                        obs-resent-date /
+                        obs-resent-from /
+                        obs-resent-send /
+                        obs-resent-rply /
+                        obs-resent-to /
+                        obs-resent-cc /
+                        obs-resent-bcc /
+                        obs-resent-mid /
+                        obs-optional)
+
+   Except for destination address fields (described in section 4.5.3),
+   the interpretation of multiple occurrences of fields is unspecified.
+   Also, the interpretation of trace fields and resent fields which do
+   not occur in blocks prepended to the message is unspecified as well.
+   Unless otherwise noted in the following sections, interpretation of
+   other fields is identical to the interpretation of their non-obsolete
+   counterparts in section 3.
+
+4.5.1. Obsolete origination date field
+
+obs-orig-date   =       "Date" *WSP ":" date-time CRLF
+
+4.5.2. Obsolete originator fields
+
+obs-from        =       "From" *WSP ":" mailbox-list CRLF
+
+obs-sender      =       "Sender" *WSP ":" mailbox CRLF
+
+obs-reply-to    =       "Reply-To" *WSP ":" mailbox-list CRLF
+
+4.5.3. Obsolete destination address fields
+
+obs-to          =       "To" *WSP ":" address-list CRLF
+
+obs-cc          =       "Cc" *WSP ":" address-list CRLF
+
+obs-bcc         =       "Bcc" *WSP ":" (address-list / [CFWS]) CRLF
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 34]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   When multiple occurrences of destination address fields occur in a
+   message, they SHOULD be treated as if the address-list in the first
+   occurrence of the field is combined with the address lists of the
+   subsequent occurrences by adding a comma and concatenating.
+
+4.5.4. Obsolete identification fields
+
+   The obsolete "In-Reply-To:" and "References:" fields differ from the
+   current syntax in that they allow phrase (words or quoted strings) to
+   appear.  The obsolete forms of the left and right sides of msg-id
+   allow interspersed CFWS, making them syntactically identical to
+   local-part and domain respectively.
+
+obs-message-id  =       "Message-ID" *WSP ":" msg-id CRLF
+
+obs-in-reply-to =       "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
+
+obs-references  =       "References" *WSP ":" *(phrase / msg-id) CRLF
+
+obs-id-left     =       local-part
+
+obs-id-right    =       domain
+
+   For purposes of interpretation, the phrases in the "In-Reply-To:" and
+   "References:" fields are ignored.
+
+   Semantically, none of the optional CFWS surrounding the local-part
+   and the domain are part of the obs-id-left and obs-id-right
+   respectively.
+
+4.5.5. Obsolete informational fields
+
+obs-subject     =       "Subject" *WSP ":" unstructured CRLF
+
+obs-comments    =       "Comments" *WSP ":" unstructured CRLF
+
+obs-keywords    =       "Keywords" *WSP ":" obs-phrase-list CRLF
+
+4.5.6. Obsolete resent fields
+
+   The obsolete syntax adds a "Resent-Reply-To:" field, which consists
+   of the field name, the optional comments and folding white space, the
+   colon, and a comma separated list of addresses.
+
+obs-resent-from =       "Resent-From" *WSP ":" mailbox-list CRLF
+
+obs-resent-send =       "Resent-Sender" *WSP ":" mailbox CRLF
+
+
+
+
+Resnick                     Standards Track                    [Page 35]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+obs-resent-date =       "Resent-Date" *WSP ":" date-time CRLF
+
+obs-resent-to   =       "Resent-To" *WSP ":" address-list CRLF
+
+obs-resent-cc   =       "Resent-Cc" *WSP ":" address-list CRLF
+
+obs-resent-bcc  =       "Resent-Bcc" *WSP ":"
+                         (address-list / [CFWS]) CRLF
+
+obs-resent-mid  =       "Resent-Message-ID" *WSP ":" msg-id CRLF
+
+obs-resent-rply =       "Resent-Reply-To" *WSP ":" address-list CRLF
+
+   As with other resent fields, the "Resent-Reply-To:" field is to be
+   treated as trace information only.
+
+4.5.7. Obsolete trace fields
+
+   The obs-return and obs-received are again given here as template
+   definitions, just as return and received are in section 3.  Their
+   full syntax is given in [RFC2821].
+
+obs-return      =       "Return-Path" *WSP ":" path CRLF
+
+obs-received    =       "Received" *WSP ":" name-val-list CRLF
+
+obs-path        =       obs-angle-addr
+
+4.5.8. Obsolete optional fields
+
+obs-optional    =       field-name *WSP ":" unstructured CRLF
+
+5. Security Considerations
+
+   Care needs to be taken when displaying messages on a terminal or
+   terminal emulator.  Powerful terminals may act on escape sequences
+   and other combinations of ASCII control characters with a variety of
+   consequences.  They can remap the keyboard or permit other
+   modifications to the terminal which could lead to denial of service
+   or even damaged data.  They can trigger (sometimes programmable)
+   answerback messages which can allow a message to cause commands to be
+   issued on the recipient's behalf.  They can also effect the operation
+   of terminal attached devices such as printers.  Message viewers may
+   wish to strip potentially dangerous terminal escape sequences from
+   the message prior to display.  However, other escape sequences appear
+   in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
+   RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
+   indiscriminately.
+
+
+
+Resnick                     Standards Track                    [Page 36]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   Transmission of non-text objects in messages raises additional
+   security issues.  These issues are discussed in [RFC2045, RFC2046,
+   RFC2047, RFC2048, RFC2049].
+
+   Many implementations use the "Bcc:" (blind carbon copy) field
+   described in section 3.6.3 to facilitate sending messages to
+   recipients without revealing the addresses of one or more of the
+   addressees to the other recipients.  Mishandling this use of "Bcc:"
+   has implications for confidential information that might be revealed,
+   which could eventually lead to security problems through knowledge of
+   even the existence of a particular mail address.  For example, if
+   using the first method described in section 3.6.3, where the "Bcc:"
+   line is removed from the message, blind recipients have no explicit
+   indication that they have been sent a blind copy, except insofar as
+   their address does not appear in the message header.  Because of
+   this, one of the blind addressees could potentially send a reply to
+   all of the shown recipients and accidentally reveal that the message
+   went to the blind recipient.  When the second method from section
+   3.6.3 is used, the blind recipient's address appears in the "Bcc:"
+   field of a separate copy of the message. If the "Bcc:" field sent
+   contains all of the blind addressees, all of the "Bcc:" recipients
+   will be seen by each "Bcc:" recipient.  Even if a separate message is
+   sent to each "Bcc:" recipient with only the individual's address,
+   implementations still need to be careful to process replies to the
+   message as per section 3.6.3 so as not to accidentally reveal the
+   blind recipient to other recipients.
+
+6. Bibliography
+
+   [ASCII]    American National Standards Institute (ANSI), Coded
+              Character Set - 7-Bit American National Standard Code for
+              Information Interchange, ANSI X3.4, 1986.
+
+   [ISO2022] International Organization for Standardization (ISO),
+              Information processing - ISO 7-bit and 8-bit coded
+              character sets - Code extension techniques, Third edition
+              - 1986-05-01, ISO 2022, 1986.
+
+   [RFC822]   Crocker, D., "Standard for the Format of ARPA Internet
+              Text Messages", RFC 822, August 1982.
+
+   [RFC2045]  Freed, N. and  N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+
+
+Resnick                     Standards Track                    [Page 37]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   [RFC2047]  Moore, K., "Multipurpose Internet Mail Extensions (MIME)
+              Part Three: Message Header Extensions for Non-ASCII Text",
+              RFC 2047, November 1996.
+
+   [RFC2048]  Freed, N., Klensin, J. and J. Postel, "Multipurpose
+              Internet Mail Extensions (MIME) Part Four: Format of
+              Internet Message Bodies", RFC 2048, November 1996.
+
+   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Five: Conformance Criteria and
+              Examples", RFC 2049, November 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2234]  Crocker, D., Editor, and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC2821]  Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
+              2821, March 2001.
+
+   [STD3]     Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC
+              1123, October 1989.
+
+   [STD12]    Mills, D., "Network Time Protocol", STD 12, RFC 1119,
+              September 1989.
+
+   [STD13]    Mockapetris, P., "Domain Name System", STD 13, RFC 1034
+              and RFC 1035,  November 1987.
+
+   [STD14]    Partridge, C., "Mail Routing and the Domain System", STD
+              14, RFC 974, January 1986.
+
+7. Editor's Address
+
+   Peter W. Resnick
+   QUALCOMM Incorporated
+   5775 Morehouse Drive
+   San Diego, CA 92121-1714
+   USA
+
+   Phone: +1 858 651 4478
+   Fax:   +1 858 651 1102
+   EMail: presnick@qualcomm.com
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 38]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+8. Acknowledgements
+
+   Many people contributed to this document.  They included folks who
+   participated in the Detailed Revision and Update of Messaging
+   Standards (DRUMS) Working Group of the Internet Engineering Task
+   Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
+   people who simply sent their comments in via e-mail.  The editor is
+   deeply indebted to them all and thanks them sincerely.  The below
+   list includes everyone who sent e-mail concerning this document.
+   Hopefully, everyone who contributed is named here:
+
+   Matti Aarnio              Barry Finkel           Larry Masinter
+   Tanaka Akira              Erik Forsberg          Denis McKeon
+   Russ Allbery              Chuck Foster           William P McQuillan
+   Eric Allman               Paul Fox               Alexey Melnikov
+   Harald Tveit Alvestrand   Klaus M. Frank         Perry E. Metzger
+   Ran Atkinson              Ned Freed              Steven Miller
+   Jos Backus                Jochen Friedrich       Keith Moore
+   Bruce Balden              Randall C. Gellens     John Gardiner Myers
+   Dave Barr                 Sukvinder Singh Gill   Chris Newman
+   Alan Barrett              Tim Goodwin            John W. Noerenberg
+   John Beck                 Philip Guenther        Eric Norman
+   J. Robert von Behren      Tony Hansen            Mike O'Dell
+   Jos den Bekker            John Hawkinson         Larry Osterman
+   D. J. Bernstein           Philip Hazel           Paul Overell
+   James Berriman            Kai Henningsen         Jacob Palme
+   Norbert Bollow            Robert Herriot         Michael A. Patton
+   Raj Bose                  Paul Hethmon           Uzi Paz
+   Antony Bowesman           Jim Hill               Michael A. Quinlan
+   Scott Bradner             Paul E. Hoffman        Eric S. Raymond
+   Randy Bush                Steve Hole             Sam Roberts
+   Tom Byrer                 Kari Hurtta            Hugh Sasse
+   Bruce Campbell            Marco S. Hyman         Bart Schaefer
+   Larry Campbell            Ofer Inbar             Tom Scola
+   W. J. Carpenter           Olle Jarnefors         Wolfgang Segmuller
+   Michael Chapman           Kevin Johnson          Nick Shelness
+   Richard Clayton           Sudish Joseph          John Stanley
+   Maurizio Codogno          Maynard Kang           Einar Stefferud
+   Jim Conklin               Prabhat Keni           Jeff Stephenson
+   R. Kelley Cook            John C. Klensin        Bernard Stern
+   Steve Coya                Graham Klyne           Peter Sylvester
+   Mark Crispin              Brad Knowles           Mark Symons
+   Dave Crocker              Shuhei Kobayashi       Eric Thomas
+   Matt Curtin               Peter Koch             Lee Thompson
+   Michael D'Errico          Dan Kohn               Karel De Vriendt
+   Cyrus Daboo               Christian Kuhtz        Matthew Wall
+   Jutta Degener             Anand Kumria           Rolf Weber
+   Mark Delany               Steen Larsen           Brent B. Welch
+
+
+
+Resnick                     Standards Track                    [Page 39]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   Steve Dorner              Eliot Lear             Dan Wing
+   Harold A. Driscoll        Barry Leiba            Jack De Winter
+   Michael Elkins            Jay Levitt             Gregory J. Woodhouse
+   Robert Elz                Lars-Johan Liman       Greg A. Woods
+   Johnny Eriksson           Charles Lindsey        Kazu Yamamoto
+   Erik E. Fair              Pete Loshin            Alain Zahm
+   Roger Fajman              Simon Lyall            Jamie Zawinski
+   Patrik Faltstrom          Bill Manning           Timothy S. Zurcher
+   Claus Andre Farber        John Martin
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 40]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+Appendix A. Example messages
+
+   This section presents a selection of messages.  These are intended to
+   assist in the implementation of this standard, but should not be
+   taken as normative; that is to say, although the examples in this
+   section were carefully reviewed, if there happens to be a conflict
+   between these examples and the syntax described in sections 3 and 4
+   of this document, the syntax in those sections is to be taken as
+   correct.
+
+   Messages are delimited in this section between lines of "----".  The
+   "----" lines are not part of the message itself.
+
+A.1. Addressing examples
+
+   The following are examples of messages that might be sent between two
+   individuals.
+
+A.1.1. A message from one person to another with simple addressing
+
+   This could be called a canonical message.  It has a single author,
+   John Doe, a single recipient, Mary Smith, a subject, the date, a
+   message identifier, and a textual message in the body.
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 41]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   If John's secretary Michael actually sent the message, though John
+   was the author and replies to this message should go back to him, the
+   sender field would be used:
+
+----
+From: John Doe <jdoe@machine.example>
+Sender: Michael Jones <mjones@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+A.1.2. Different types of mailboxes
+
+   This message includes multiple addresses in the destination fields
+   and also uses several different forms of addresses.
+
+----
+From: "Joe Q. Public" <john.q.public@example.com>
+To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
+Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
+Date: Tue, 1 Jul 2003 10:52:37 +0200
+Message-ID: <5678.21-Nov-1997@example.com>
+
+Hi everyone.
+----
+
+   Note that the display names for Joe Q. Public and Giant; "Big" Box
+   needed to be enclosed in double-quotes because the former contains
+   the period and the latter contains both semicolon and double-quote
+   characters (the double-quote characters appearing as quoted-pair
+   construct).  Conversely, the display name for Who? could appear
+   without them because the question mark is legal in an atom.  Notice
+   also that jdoe@example.org and boss@nil.test have no display names
+   associated with them at all, and jdoe@example.org uses the simpler
+   address form without the angle brackets.
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 42]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+A.1.3. Group addresses
+
+----
+From: Pete <pete@silly.example>
+To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
+Cc: Undisclosed recipients:;
+Date: Thu, 13 Feb 1969 23:32:54 -0330
+Message-ID: <testabcd.1234@silly.example>
+
+Testing.
+----
+
+   In this message, the "To:" field has a single group recipient named A
+   Group which contains 3 addresses, and a "Cc:" field with an empty
+   group recipient named Undisclosed recipients.
+
+A.2. Reply messages
+
+   The following is a series of three messages that make up a
+   conversation thread between John and Mary.  John firsts sends a
+   message to Mary, Mary then replies to John's message, and then John
+   replies to Mary's reply message.
+
+   Note especially the "Message-ID:", "References:", and "In-Reply-To:"
+   fields in each message.
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 43]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   When sending replies, the Subject field is often retained, though
+   prepended with "Re: " as described in section 3.6.5.
+
+----
+From: Mary Smith <mary@example.net>
+To: John Doe <jdoe@machine.example>
+Reply-To: "Mary Smith: Personal Account" <smith@home.example>
+Subject: Re: Saying Hello
+Date: Fri, 21 Nov 1997 10:01:10 -0600
+Message-ID: <3456@example.net>
+In-Reply-To: <1234@local.machine.example>
+References: <1234@local.machine.example>
+
+This is a reply to your hello.
+----
+
+   Note the "Reply-To:" field in the above message.  When John replies
+   to Mary's message above, the reply should go to the address in the
+   "Reply-To:" field instead of the address in the "From:" field.
+
+----
+To: "Mary Smith: Personal Account" <smith@home.example>
+From: John Doe <jdoe@machine.example>
+Subject: Re: Saying Hello
+Date: Fri, 21 Nov 1997 11:00:00 -0600
+Message-ID: <abcd.1234@local.machine.tld>
+In-Reply-To: <3456@example.net>
+References: <1234@local.machine.example> <3456@example.net>
+
+This is a reply to your reply.
+----
+
+A.3. Resent messages
+
+   Start with the message that has been used as an example several
+   times:
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+Resnick                     Standards Track                    [Page 44]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   Say that Mary, upon receiving this message, wishes to send a copy of
+   the message to Jane such that (a) the message would appear to have
+   come straight from John; (b) if Jane replies to the message, the
+   reply should go back to John; and (c) all of the original
+   information, like the date the message was originally sent to Mary,
+   the message identifier, and the original addressee, is preserved.  In
+   this case, resent fields are prepended to the message:
+
+----
+Resent-From: Mary Smith <mary@example.net>
+Resent-To: Jane Brown <j-brown@other.example>
+Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
+Resent-Message-ID: <78910@example.net>
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+   If Jane, in turn, wished to resend this message to another person,
+   she would prepend her own set of resent header fields to the above
+   and send that.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 45]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+A.4. Messages with trace fields
+
+   As messages are sent through the transport system as described in
+   [RFC2821], trace fields are prepended to the message.  The following
+   is an example of what those trace fields might look like.  Note that
+   there is some folding white space in the first one since these lines
+   can be long.
+
+----
+Received: from x.y.test
+   by example.net
+   via TCP
+   with ESMTP
+   id ABC12345
+   for <mary@example.net>;  21 Nov 1997 10:05:43 -0600
+Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 46]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+A.5. White space, comments, and other oddities
+
+   White space, including folding white space, and comments can be
+   inserted between many of the tokens of fields.  Taking the example
+   from A.1.3, white space and comments can be inserted into all of the
+   fields.
+
+----
+From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
+To:A Group(Some people)
+     :Chris Jones <c@(Chris's host.)public.example>,
+         joe@example.org,
+  John <jdoe@one.test> (my dear friend); (the end of the group)
+Cc:(Empty list)(start)Undisclosed recipients  :(nobody(that I know))  ;
+Date: Thu,
+      13
+        Feb
+          1969
+      23:32
+               -0330 (Newfoundland Time)
+Message-ID:              <testabcd.1234@silly.test>
+
+Testing.
+----
+
+   The above example is aesthetically displeasing, but perfectly legal.
+   Note particularly (1) the comments in the "From:" field (including
+   one that has a ")" character appearing as part of a quoted-pair); (2)
+   the white space absent after the ":" in the "To:" field as well as
+   the comment and folding white space after the group name, the special
+   character (".") in the comment in Chris Jones's address, and the
+   folding white space before and after "joe@example.org,"; (3) the
+   multiple and nested comments in the "Cc:" field as well as the
+   comment immediately following the ":" after "Cc"; (4) the folding
+   white space (but no comments except at the end) and the missing
+   seconds in the time of the date field; and (5) the white space before
+   (but not within) the identifier in the "Message-ID:" field.
+
+A.6. Obsoleted forms
+
+   The following are examples of obsolete (that is, the "MUST NOT
+   generate") syntactic elements described in section 4 of this
+   document.
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 47]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+A.6.1. Obsolete addressing
+
+   Note in the below example the lack of quotes around Joe Q. Public,
+   the route that appears in the address for Mary Smith, the two commas
+   that appear in the "To:" field, and the spaces that appear around the
+   "." in the jdoe address.
+
+----
+From: Joe Q. Public <john.q.public@example.com>
+To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test   . example
+Date: Tue, 1 Jul 2003 10:52:37 +0200
+Message-ID: <5678.21-Nov-1997@example.com>
+
+Hi everyone.
+----
+
+A.6.2. Obsolete dates
+
+   The following message uses an obsolete date format, including a non-
+   numeric time zone and a two digit year.  Note that although the
+   day-of-week is missing, that is not specific to the obsolete syntax;
+   it is optional in the current syntax as well.
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: 21 Nov 97 09:55:06 GMT
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+A.6.3. Obsolete white space and comments
+
+   White space and comments can appear between many more elements than
+   in the current syntax.  Also, folding lines that are made up entirely
+   of white space are legal.
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 48]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+----
+From  : John Doe <jdoe@machine(comment).  example>
+To    : Mary Smith
+__
+          <mary@example.net>
+Subject     : Saying Hello
+Date  : Fri, 21 Nov 1997 09(comment):   55  :  06 -0600
+Message-ID  : <1234   @   local(blah)  .machine .example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+   Note especially the second line of the "To:" field.  It starts with
+   two space characters.  (Note that "__" represent blank spaces.)
+   Therefore, it is considered part of the folding as described in
+   section 4.2.  Also, the comments and white space throughout
+   addresses, dates, and message identifiers are all part of the
+   obsolete syntax.
+
+Appendix B. Differences from earlier standards
+
+   This appendix contains a list of changes that have been made in the
+   Internet Message Format from earlier standards, specifically [RFC822]
+   and [STD3].  Items marked with an asterisk (*) below are items which
+   appear in section 4 of this document and therefore can no longer be
+   generated.
+
+   1. Period allowed in obsolete form of phrase.
+   2. ABNF moved out of document to [RFC2234].
+   3. Four or more digits allowed for year.
+   4. Header field ordering (and lack thereof) made explicit.
+   5. Encrypted header field removed.
+   6. Received syntax loosened to allow any token/value pair.
+   7. Specifically allow and give meaning to "-0000" time zone.
+   8. Folding white space is not allowed between every token.
+   9. Requirement for destinations removed.
+   10. Forwarding and resending redefined.
+   11. Extension header fields no longer specifically called out.
+   12. ASCII 0 (null) removed.*
+   13. Folding continuation lines cannot contain only white space.*
+   14. Free insertion of comments not allowed in date.*
+   15. Non-numeric time zones not allowed.*
+   16. Two digit years not allowed.*
+   17. Three digit years interpreted, but not allowed for generation.
+   18. Routes in addresses not allowed.*
+   19. CFWS within local-parts and domains not allowed.*
+   20. Empty members of address lists not allowed.*
+
+
+
+Resnick                     Standards Track                    [Page 49]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+   21. Folding white space between field name and colon not allowed.*
+   22. Comments between field name and colon not allowed.
+   23. Tightened syntax of in-reply-to and references.*
+   24. CFWS within msg-id not allowed.*
+   25. Tightened semantics of resent fields as informational only.
+   26. Resent-Reply-To not allowed.*
+   27. No multiple occurrences of fields (except resent and received).*
+   28. Free CR and LF not allowed.*
+   29. Routes in return path not allowed.*
+   30. Line length limits specified.
+   31. Bcc more clearly specified.
+
+Appendix C. Notices
+
+   Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 50]
+
+RFC 2822                Internet Message Format               April 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 51]
+
diff --git a/standards/rfc2910.txt b/standards/rfc2910.txt
new file mode 100644
index 000000000..e13631c2a
--- /dev/null
+++ b/standards/rfc2910.txt
@@ -0,0 +1,2579 @@
+
+
+
+
+
+
+Network Working Group                                 R. Herriot, Editor
+Request for Comments: 2910                             Xerox Corporation
+Obsoletes: 2565                                                S. Butler
+Category: Standards Track                                Hewlett-Packard
+                                                                P. Moore
+                                             Peerless Systems Networking
+                                                               R. Turner
+                                                               2wire.com
+                                                                 J. Wenn
+                                                       Xerox Corporation
+                                                          September 2000
+
+
+         Internet Printing Protocol/1.1: Encoding and Transport
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP). IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies. This document defines the
+   rules for encoding IPP operations and IPP attributes into a new
+   Internet mime media type called "application/ipp".  This document
+   also defines the rules for transporting over Hypertext Transfer
+   Protocol (HTTP) a message body whose Content-Type is
+   "application/ipp". This document defines a new scheme named 'ipp' for
+   identifying IPP printers and jobs.
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 1]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   The full set of IPP documents includes:
+
+   Design Goals for an Internet Printing Protocol [RFC2567]
+   Rationale for the Structure and Model and Protocol for the Internet
+   Printing Protocol [RFC2568]
+   Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+   Internet Printing Protocol/1.1: Encoding and Transport (this
+   document)
+   Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
+   Mapping between LPD and IPP Protocols [RFC2569]
+
+   The document, "Design Goals for an Internet Printing Protocol", takes
+   a broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet. It identifies
+   requirements for three types of users: end users, operators, and
+   administrators. It calls out a subset of end user requirements that
+   are satisfied in IPP/1.1. A few OPTIONAL operator operations have
+   been added to IPP/1.1.
+
+   The document, "Rationale for the Structure and Model and Protocol for
+   the Internet Printing Protocol", describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF working group's major decisions.
+
+   The document, "Internet Printing Protocol/1.1: Model and Semantics",
+   describes a simplified model with abstract objects, their attributes,
+   and their operations that are independent of encoding and transport.
+   It introduces a Printer and a Job object. The Job object optionally
+   supports multiple documents per Job. It also addresses security,
+   internationalization, and directory issues.
+
+   The document "Internet Printing Protocol/1.1: Implementer's Guide",
+   gives advice to implementers of IPP clients and IPP objects.
+
+   The document "Mapping between LPD and IPP Protocols", gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 2]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+Table of Contents
+
+   1. Introduction ...................................................4
+   2. Conformance Terminology ........................................4
+   3. Encoding of  the Operation Layer ...............................4
+      3.1  Picture of the Encoding ...................................6
+         3.1.1 Request and Response...................................6
+         3.1.2 Attribute Group........................................6
+         3.1.3 Attribute..............................................7
+         3.1.4 Picture of the Encoding of an Attribute-with-one-value.7
+         3.1.5 Additional-value.......................................8
+         3.1.6 Alternative Picture of the Encoding of a Request Or a
+               Response...............................................9
+      3.2  Syntax of Encoding ........................................9
+      3.3  Attribute-group ..........................................11
+      3.4  Required Parameters ......................................12
+         3.4.1 Version-number........................................12
+         3.4.2 Operation-id..........................................12
+         3.4.3 Status-code...........................................12
+         3.4.4 Request-id............................................13
+      3.5  Tags .....................................................13
+         3.5.1 Delimiter Tags........................................13
+         3.5.2 Value Tags............................................14
+      3.6  Name-Length ..............................................16
+      3.7  (Attribute) Name .........................................16
+      3.8  Value Length .............................................16
+      3.9  (Attribute) Value ........................................17
+      3.10 Data .....................................................18
+   4. Encoding of Transport Layer ...................................18
+      4.1  Printer-uri and job-uri ..................................19
+   5. IPP URL Scheme ................................................20
+   6. IANA Considerations ...........................................22
+   7. Internationalization Considerations ...........................23
+   8. Security Considerations .......................................23
+      8.1  Security Conformance Requirements ........................23
+         8.1.1 Digest Authentication.................................23
+         8.1.2 Transport Layer Security (TLS)........................24
+      8.2  Using IPP with TLS .......................................25
+   9. Interoperability with IPP/1.0 Implementations .................25
+      9.1  The "version-number" Parameter ...........................25
+      9.2  Security and URL Schemes .................................26
+   10. References ...................................................27
+   11. Authors' Addresses ...........................................29
+   12. Other Participants: ..........................................31
+   13. Appendix A: Protocol Examples ................................33
+      13.1 Print-Job Request ........................................33
+      13.2 Print-Job Response (successful) ..........................34
+      13.3 Print-Job Response (failure) .............................35
+
+
+
+Herriot, et al.             Standards Track                     [Page 3]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+      13.4 Print-Job Response (success with attributes ignored) .....36
+      13.5 Print-URI Request ........................................38
+      13.6 Create-Job Request .......................................39
+      13.7 Get-Jobs Request .........................................40
+      13.8 Get-Jobs Response ........................................41
+   14. Appendix B: Registration of MIME Media Type Information for
+       "application/ipp".............................................42
+   15. Appendix C: Changes from IPP/1.0 .............................44
+   16. Full Copyright Statement .....................................45
+
+1. Introduction
+
+   This document contains the rules for encoding IPP operations and
+   describes two layers: the transport layer and the operation layer.
+
+   The transport layer consists of an HTTP/1.1 request or response. RFC
+   2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP
+   headers that an IPP implementation supports.
+
+   The operation layer consists of a message body in an HTTP request or
+   response.  The document "Internet Printing Protocol/1.1: Model and
+   Semantics" [RFC2911] defines the semantics of such a message body and
+   the supported values. This document specifies the encoding of an IPP
+   operation. The aforementioned document [RFC2911] is henceforth
+   referred to as the "IPP model document" or simply "model document".
+
+   Note:  the version number of IPP (1.1) and HTTP (1.1) are not linked.
+   They both just happen to be 1.1.
+
+2. Conformance Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and  "OPTIONAL" in this document are to be
+   interpreted as described in RFC 2119 [RFC2119].
+
+3. Encoding of the Operation Layer
+
+   The operation layer is the message body part of the HTTP request or
+   response and it MUST contain a single IPP operation request or IPP
+   operation response.  Each request or response consists of a sequence
+   of values and attribute groups. Attribute groups consist of a
+   sequence of attributes each of which is a name and value.  Names and
+   values are ultimately sequences of octets.
+
+   The encoding consists of octets as the most primitive type. There are
+   several types built from octets, but three important types are
+   integers, character strings and octet strings, on which most other
+   data types are built. Every character string in this encoding MUST be
+
+
+
+Herriot, et al.             Standards Track                     [Page 4]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   a sequence of characters where the characters are associated with
+   some charset and some natural language. A character string MUST be in
+   "reading order" with the first character in the value (according to
+   reading order) being the first character in the encoding. A character
+   string whose associated charset is US-ASCII whose associated natural
+   language is US English is henceforth called a US-ASCII-STRING. A
+   character string whose associated charset and natural language are
+   specified in a request or response as described in the model document
+   is henceforth called a LOCALIZED-STRING.  An octet string MUST be in
+   "IPP model document order" with the first octet in the value
+   (according to the IPP model document order) being the first octet in
+   the encoding. Every integer in this encoding MUST be encoded as a
+   signed integer using two's-complement binary encoding with big-endian
+   format (also known as "network order" and "most significant byte
+   first"). The number of octets for an integer MUST be 1, 2 or 4,
+   depending on usage in the protocol. Such one-octet integers,
+   henceforth called SIGNED-BYTE, are used for the version-number and
+   tag fields. Such two-byte integers, henceforth called SIGNED-SHORT
+   are used for the operation-id, status-code and length fields. Four
+   byte integers, henceforth called SIGNED-INTEGER, are used for value
+   fields and the request-id.
+
+   The following two sections present the encoding of the operation
+   layer in two ways:
+
+      -  informally through pictures and description
+      -  formally through Augmented Backus-Naur Form (ABNF), as
+         specified by RFC 2234 [RFC2234]
+
+   An operation request or response MUST use the encoding described in
+   these two sections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 5]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+3.1 Picture of the Encoding
+
+3.1.1 Request and Response
+
+   An operation request or response is encoded as follows:
+
+   -----------------------------------------------
+   |                  version-number             |   2 bytes  - required
+   -----------------------------------------------
+   |               operation-id (request)        |
+   |                      or                     |   2 bytes  - required
+   |               status-code (response)        |
+   -----------------------------------------------
+   |                   request-id                |   4 bytes  - required
+   -----------------------------------------------
+   |                 attribute-group             |   n bytes - 0 or more
+   -----------------------------------------------
+   |              end-of-attributes-tag          |   1 byte   - required
+   -----------------------------------------------
+   |                     data                    |   q bytes  - optional
+   -----------------------------------------------
+
+   The first three fields in the above diagram contain the value of
+   attributes described in section 3.1.1 of the Model document.
+
+   The fourth field is the "attribute-group" field, and it occurs 0 or
+   more times. Each "attribute-group" field represents a single group of
+   attributes, such as an Operation Attributes group or a Job Attributes
+   group (see the Model document). The IPP model document specifies the
+   required attribute groups and their order for each operation request
+   and response.
+
+   The "end-of-attributes-tag" field is always present, even when the
+   "data" is not present.  The Model document specifies for each
+   operation request and response whether the "data" field is present or
+   absent.
+
+3.1.2 Attribute Group
+
+   Each "attribute-group" field is encoded as follows:
+
+   -----------------------------------------------
+   |           begin-attribute-group-tag         |  1 byte
+   ----------------------------------------------------------
+   |                   attribute                 |  p bytes |- 0 or more
+   ----------------------------------------------------------
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 6]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   The "begin-attribute-group-tag" field marks the beginning of an
+   "attribute-group" field and its value identifies the type of
+   attribute group, e.g. Operations Attributes group versus a Job
+   Attributes group.  The "begin-attribute-group-tag" field also marks
+   the end of the previous attribute group except for the "begin-
+   attribute-group-tag" field in the first "attribute-group" field of a
+   request or response.  The "begin-attribute-group-tag" field acts as
+   an "attribute-group" terminator because an "attribute-group" field
+   cannot nest inside another "attribute-group" field.
+
+   An "attribute-group" field contains zero or more "attribute" fields.
+
+   Note, the values of the "begin-attribute-group-tag" field and the
+   "end-of-attributes-tag" field are called "delimiter-tags".
+
+3.1.3 Attribute
+
+   An "attribute" field is encoded as follows:
+
+   -----------------------------------------------
+   |          attribute-with-one-value           |  q bytes
+   ----------------------------------------------------------
+   |             additional-value                |  r bytes |- 0 or more
+   ----------------------------------------------------------
+
+   When an attribute is single valued (e.g. "copies" with value of 10)
+   or multi-valued with one value (e.g. "sides-supported" with just the
+   value 'one-sided') it is encoded with just an "attribute-with-one-
+   value" field. When an attribute is multi-valued with n values (e.g.
+   "sides-supported" with the values 'one-sided' and 'two-sided-long-
+   edge'), it is encoded with an "attribute-with-one-value" field
+   followed by n-1 "additional-value" fields.
+
+3.1.4 Picture of the Encoding of an Attribute-with-one-value
+
+   Each "attribute-with-one-value" field is encoded as follows:
+
+   -----------------------------------------------
+   |                   value-tag                 |   1 byte
+   -----------------------------------------------
+   |               name-length  (value is u)     |   2 bytes
+   -----------------------------------------------
+   |                     name                    |   u bytes
+   -----------------------------------------------
+   |              value-length  (value is v)     |   2 bytes
+   -----------------------------------------------
+   |                     value                   |   v bytes
+   -----------------------------------------------
+
+
+
+Herriot, et al.             Standards Track                     [Page 7]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   An "attribute-with-one-value" field is encoded with five subfields:
+
+      The "value-tag" field specifies the attribute syntax, e.g. 0x44
+      for the attribute syntax 'keyword'.
+
+      The "name-length" field specifies the length of the "name" field
+      in bytes, e.g. u in the above diagram or 15 for the name "sides-
+      supported".
+
+      The "name" field contains the textual name of the attribute, e.g.
+      "sides-supported".
+
+      The "value-length" field specifies the length of the "value" field
+      in bytes, e.g. v in the above diagram or 9 for the (keyword) value
+      'one-sided'.
+
+      The "value" field contains the value of the attribute, e.g. the
+      textual value 'one-sided'.
+
+3.1.5 Additional-value
+
+   Each "additional-value" field is encoded as follows:
+
+   -----------------------------------------------
+   |                   value-tag                 |   1 byte
+   -----------------------------------------------
+   |            name-length  (value is 0x0000)   |   2 bytes
+   -----------------------------------------------
+   |              value-length (value is w)      |   2 bytes
+   -----------------------------------------------
+   |                     value                   |   w bytes
+   -----------------------------------------------
+
+   An "additional-value" is encoded with four subfields:
+
+      The "value-tag" field specifies the attribute syntax, e.g. 0x44
+      for the attribute syntax 'keyword'.
+
+      The "name-length" field has the value of 0 in order to signify
+      that it is an "additional-value". The value of the "name-length"
+      field distinguishes an "additional-value" field ("name-length" is
+      0) from an "attribute-with-one-value" field ("name-length" is not
+      0).
+
+      The "value-length" field specifies the length of the "value" field
+      in bytes, e.g. w in the above diagram or 19 for the (keyword)
+      value 'two-sided-long-edge'.
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 8]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+      The "value" field contains the value of the attribute, e.g. the
+      textual value 'two-sided-long-edge'.
+
+3.1.6 Alternative Picture of the Encoding of a Request Or a Response
+
+   From the standpoint of a parser that performs an action based on a
+   "tag" value, the encoding consists of:
+
+   -----------------------------------------------
+   |                  version-number             |   2 bytes  - required
+   -----------------------------------------------
+   |               operation-id (request)        |
+   |                      or                     |   2 bytes  - required
+   |               status-code (response)        |
+   -----------------------------------------------
+   |                   request-id                |   4 bytes  - required
+   -----------------------------------------------------------
+   |        tag (delimiter-tag or value-tag)     |   1 byte  |
+   -----------------------------------------------           |-0 or more
+   |           empty or rest of attribute        |   x bytes |
+   -----------------------------------------------------------
+   |              end-of-attributes-tag          |   1 byte   - required
+   -----------------------------------------------
+   |                     data                    |   y bytes  - optional
+   -----------------------------------------------
+
+   The following show what fields the parser would expect after each
+   type of  "tag":
+
+      -  "begin-attribute-group-tag": expect zero or more "attribute"
+         fields
+      -  "value-tag": expect the remainder of an "attribute-with-one-
+         value" or  an "additional-value".
+      -  "end-of-attributes-tag": expect that "attribute" fields are
+         complete and there is optional "data"
+
+3.2 Syntax of Encoding
+
+   The syntax below is ABNF [RFC2234] except 'strings of literals' MUST
+   be case sensitive. For example 'a' means lower case  'a' and not
+   upper case 'A'.   In addition, SIGNED-BYTE and SIGNED-SHORT fields
+   are represented as '%x' values which show their range of values.
+
+      ipp-message = ipp-request / ipp-response
+      ipp-request = version-number operation-id request-id
+               *attribute-group end-of-attributes-tag data
+      ipp-response = version-number status-code request-id
+               *attribute-group end-of-attributes-tag data
+
+
+
+Herriot, et al.             Standards Track                     [Page 9]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+      attribute-group = begin-attribute-group-tag *attribute
+
+      version-number = major-version-number minor-version-number
+      major-version-number = SIGNED-BYTE
+      minor-version-number = SIGNED-BYTE
+
+      operation-id = SIGNED-SHORT    ; mapping from model defined below
+      status-code = SIGNED-SHORT  ; mapping from model defined below
+      request-id = SIGNED-INTEGER ; whose value is > 0
+
+      attribute = attribute-with-one-value *additional-value
+
+      attribute-with-one-value = value-tag name-length name
+          value-length value
+      additional-value = value-tag zero-name-length value-length value
+
+      name-length = SIGNED-SHORT    ; number of octets of 'name'
+      name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
+      value-length = SIGNED-SHORT   ; number of octets of 'value'
+      value = OCTET-STRING
+
+      data = OCTET-STRING
+
+      zero-name-length = %x00.00            ; name-length of 0
+      value-tag = %x10-FF                  ;see section 3.7.2
+      begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1
+      end-of-attributes-tag = %x03                  ; tag of 3
+                                    ; see section 3.7.1
+      SIGNED-BYTE = BYTE
+      SIGNED-SHORT = 2BYTE
+      SIGNED-INTEGER = 4BYTE
+      DIGIT = %x30-39    ;  "0" to "9"
+      LALPHA = %x61-7A   ;  "a" to "z"
+      BYTE = %x00-FF
+      OCTET-STRING = *BYTE
+
+   The syntax below defines additional terms that are referenced in this
+   document. This syntax provides an alternate grouping of the delimiter
+   tags.
+
+      delimiter-tag = begin-attribute-group-tag  / ; see section 3.7.1
+                end-of-attributes-tag
+      delimiter-tag = %x00-0F                      ; see section 3.7.1
+
+      begin-attribute-group-tag = %x00 / operation-attributes-tag /
+         job-attributes-tag / printer-attributes-tag /
+         unsupported-attributes-tag /  %x06-0F
+      operation-attributes-tag =  %x01              ; tag of 1
+
+
+
+Herriot, et al.             Standards Track                    [Page 10]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+      job-attributes-tag    =  %x02                 ; tag of 2
+      printer-attributes-tag =  %x04                ; tag of 4
+      unsupported-attributes-tag =  %x05            ; tag of 5
+
+3.3 Attribute-group
+
+   Each "attribute-group" field MUST be encoded with the "begin-
+   attribute-group-tag" field followed by zero or more "attribute" sub-
+   fields.
+
+   The table below maps the model document group name to value of the
+   "begin-attribute-group-tag" field:
+
+      Model Document Group            "begin-attribute-group-tag" field
+                                      values
+
+      Operation Attributes            "operations-attributes-tag"
+      Job Template Attributes         "job-attributes-tag"
+      Job Object Attributes           "job-attributes-tag"
+      Unsupported Attributes          "unsupported-attributes-tag"
+      Requested Attributes            "job-attributes-tag"
+      (Get-Job-Attributes)
+      Requested Attributes            "printer-attributes-tag"
+      (Get-Printer-Attributes)
+      Document Content                in a special position as
+                                      described above
+
+   For each operation request and response, the model document
+   prescribes the required and optional attribute groups, along with
+   their order.  Within each attribute group, the model document
+   prescribes the required and optional attributes, along with their
+   order.
+
+   When the Model document requires an attribute group in a request or
+   response and the attribute group contains zero attributes, a request
+   or response SHOULD encode the attribute group with the "begin-
+   attribute-group-tag" field followed by zero "attribute" fields.  For
+   example, if the client requests a single unsupported attribute with
+   the Get-Printer-Attributes operation, the Printer MUST return no
+   "attribute" fields, and it SHOULD return a "begin-attribute-group-
+   tag" field for the Printer Attributes Group. The Unsupported
+   Attributes group is not such an example. According to the model
+   document, the Unsupported Attributes Group SHOULD be present only if
+   the unsupported attributes group contains at least one attribute.
+
+   A receiver of a request MUST be able to process the following as
+   equivalent empty attribute groups:
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 11]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+      a) A "begin-attribute-group-tag" field with zero following
+         "attribute" fields.
+
+      b) An expected but missing "begin-attribute-group-tag" field.
+
+   When the Model document requires a sequence of an unknown number of
+   attribute groups, each of the same type, the encoding MUST contain
+   one "begin-attribute-group-tag" field for each attribute group even
+   when an "attribute-group" field contains zero "attribute" sub-fields.
+   For example, for the Get-Jobs operation may return zero attributes
+   for some jobs and not others. The "begin-attribute-group-tag" field
+   followed by zero "attribute" fields tells the recipient that there is
+   a job in queue for which no information is available except that it
+   is in the queue.
+
+3.4 Required Parameters
+
+   Some operation elements are called parameters in the model document
+   [RFC2911]. They MUST be encoded in a special position and they MUST
+   NOT appear as operation attributes.  These parameters are described
+   in the subsections below.
+
+3.4.1 Version-number
+
+   The "version-number" field MUST consist of a major and minor
+   version-number, each of which MUST be represented by a SIGNED-BYTE.
+   The major version-number MUST be the first byte of the encoding and
+   the minor version-number MUST be the second byte of the encoding. The
+   protocol described in this document MUST have a major version-number
+   of 1 (0x01) and a minor version-number of 1 (0x01).  The ABNF for
+   these two bytes MUST be %x01.01.
+
+3.4.2 Operation-id
+
+   The "operation-id" field MUST contain an operation-id value defined
+   in the model document. The value MUST be encoded as a SIGNED-SHORT
+   and it MUST be in the third and fourth bytes of the encoding of an
+   operation request.
+
+3.4.3 Status-code
+
+   The "status-code" field MUST contain a status-code value defined in
+   the model document. The value MUST be encoded as a SIGNED-SHORT and
+   it MUST be in the third and fourth bytes of the encoding of an
+   operation response.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 12]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   The status-code is an operation attribute in the model document. In
+   the protocol, the status-code is in a special position, outside of
+   the operation attributes.
+
+   If an IPP status-code is returned, then the HTTP Status-Code MUST be
+   200 (successful-ok). With any other HTTP Status-Code value, the HTTP
+   response MUST NOT contain an IPP message-body, and thus no IPP
+   status-code is returned.
+
+3.4.4 Request-id
+
+   The "request-id" field MUST contain a request-id value as defined in
+   the model document. The value MUST be encoded as a SIGNED-INTEGER and
+   it MUST be in the fifth through eighth bytes of the encoding.
+
+3.5 Tags
+
+   There are two kinds of tags:
+
+      -  delimiter tags: delimit major sections of the protocol, namely
+         attributes and data
+      -  value tags: specify the type of each attribute value
+
+3.5.1 Delimiter Tags
+
+   The following table specifies the values for the delimiter tags:
+
+   Tag Value (Hex)    Meaning
+
+   0x00               reserved for definition in a future IETF
+                      standards track document
+   0x01               "operation-attributes-tag"
+   0x02               "job-attributes-tag"
+   0x03               "end-of-attributes-tag"
+   0x04               "printer-attributes-tag"
+   0x05               "unsupported-attributes-tag"
+   0x06-0x0f          reserved for future delimiters in IETF
+                      standards track documents
+
+   When a "begin-attribute-group-tag" field occurs in the protocol, it
+   means that zero or more following attributes up to the next delimiter
+   tag MUST be attributes belonging to the attribute group specified by
+   the value of the "begin-attribute-group-tag". For example, if the
+   value of "begin-attribute-group-tag" is 0x01, the following
+   attributes MUST be members of the Operations Attributes group.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 13]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in
+   an operation.  It MUST be the last "delimiter-tag". If the operation
+   has a document-content group, the document data in that group MUST
+   follow the "end-of-attributes-tag".
+
+   The order and presence of "attribute-group" fields (whose beginning
+   is marked by the "begin-attribute-group-tag" subfield) for each
+   operation request and each operation response MUST be that defined in
+   the model document. For further details, see section 3.7 "(Attribute)
+   Name" and 13 "Appendix A: Protocol Examples".
+
+   A Printer MUST treat a "delimiter-tag" (values from 0x00 through
+   0x0F) differently from a "value-tag" (values from 0x10 through 0xFF)
+   so that the Printer knows that there is an entire attribute group
+   that it doesn't understand as opposed to a single value that it
+   doesn't understand.
+
+3.5.2 Value Tags
+
+   The remaining tables show values for the "value-tag" field, which is
+   the first octet of an attribute. The "value-tag" field specifies the
+   type of the value of the attribute.
+
+   The following table specifies the "out-of-band" values for the
+   "value-tag" field.
+
+   Tag Value (Hex)  Meaning
+
+   0x10             unsupported
+   0x11             reserved for 'default' for definition in a future
+                    IETF standards track document
+   0x12             unknown
+   0x13             no-value
+   0x14-0x1F        reserved for "out-of-band" values in future IETF
+                    standards track documents.
+
+   The following table specifies the integer values for the "value-tag"
+   field:
+
+   Tag Value (Hex)   Meaning
+
+   0x20              reserved for definition in a future IETF
+                     standards track document
+   0x21              integer
+   0x22              boolean
+   0x23              enum
+   0x24-0x2F         reserved for integer types for definition in
+                     future IETF standards track documents
+
+
+
+Herriot, et al.             Standards Track                    [Page 14]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   NOTE: 0x20 is reserved for "generic integer" if it should ever be
+   needed.
+
+   The following table specifies the octetString values for the "value-
+   tag" field:
+
+   Tag Value (Hex)   Meaning
+
+   0x30              octetString with an  unspecified format
+   0x31              dateTime
+   0x32              resolution
+   0x33              rangeOfInteger
+   0x34              reserved for definition in a future IETF
+                     standards track document
+   0x35              textWithLanguage
+   0x36              nameWithLanguage
+   0x37-0x3F         reserved for octetString type definitions in
+                     future IETF standards track documents
+
+   The following table specifies the character-string values for the
+   "value-tag" field:
+
+   Tag Value (Hex)   Meaning
+
+   0x40              reserved for definition in a future IETF
+                     standards track document
+   0x41              textWithoutLanguage
+   0x42              nameWithoutLanguage
+   0x43              reserved for definition in a future IETF
+                     standards track document
+   0x44              keyword
+   0x45              uri
+   0x46              uriScheme
+   0x47              charset
+   0x48              naturalLanguage
+   0x49              mimeMediaType
+   0x4A-0x5F         reserved for character string type definitions
+                     in future IETF standards track documents
+
+   NOTE: 0x40 is reserved for "generic character-string" if it should
+   ever be needed.
+
+   NOTE:  an attribute value always has a type, which is explicitly
+   specified by its tag; one such tag value is "nameWithoutLanguage".
+   An attribute's name has an implicit type, which is keyword.
+
+   The values 0x60-0xFF are reserved for future type definitions in IETF
+   standards track documents.
+
+
+
+Herriot, et al.             Standards Track                    [Page 15]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   The tag 0x7F is reserved for extending types beyond the 255 values
+   available with a single byte. A tag value of 0x7F MUST signify that
+   the first 4 bytes of the value field are interpreted as the tag
+   value.  Note this future extension doesn't affect parsers that are
+   unaware of this special tag. The tag is like any other unknown tag,
+   and the value length specifies the length of a value, which contains
+   a value that the parser treats atomically.  Values from 0x00 to
+   0x37777777 are reserved for definition in future IETF standard track
+   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
+   vendor extensions.
+
+3.6 Name-Length
+
+   The "name-length" field MUST consist of a SIGNED-SHORT. This field
+   MUST specify the number of octets in the immediately following "name"
+   field.  The value of this field excludes the two bytes of the "name-
+   length" field. For example, if the "name" field contains "sides", the
+   value of this field is 5.
+
+   If a "name-length" field has a value of zero, the following "name"
+   field MUST be empty, and the following value MUST be treated as an
+   additional value for the attribute encoded in the nearest preceding
+   "attribute-with-one-value" field. Within an attribute group, if two
+   or more attributes have the same name, the attribute group is mal-
+   formed (see [RFC2911] section 3.1.3). The zero-length name is the
+   only mechanism for multi-valued attributes.
+
+3.7 (Attribute) Name
+
+   The "name" field MUST contain the name of an attribute. The model
+   document [RFC2911] specifies such names.
+
+3.8 Value Length
+
+   The "value-length" field MUST consist of a SIGNED-SHORT. This field
+   MUST specify the number of octets in the immediately following
+   "value" field.  The value of this field excludes the two bytes of the
+   "value-length" field. For example, if the "value" field contains the
+   keyword (text) value 'one-sided', the value of this field is 9.
+
+   For any of the types represented by binary signed integers, the
+   sender MUST encode the value in exactly four octets.
+
+   For any of the types represented by character-strings, the sender
+   MUST encode the value with all the characters of the string and
+   without any padding characters.
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 16]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   For "out-of-band" "value-tag" fields defined in this document, such
+   as "unsupported", the "value-length" MUST be 0 and the "value" empty;
+   the "value" has no meaning when the "value-tag" has one of these
+   "out-of-band" values. For future "out-of-band" "value-tag" fields,
+   the same rule holds unless the definition explicitly states that the
+   "value-length" MAY be non-zero and the "value" non-empty.
+
+3.9 (Attribute) Value
+
+   The syntax types (specified by the "value-tag" field) and most of the
+   details of the representation of attribute values are defined in the
+   IPP model document. The table below augments the information in the
+   model document, and defines the syntax types from the model document
+   in terms of the 5 basic types defined in section 3, "Encoding of the
+   Operation Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING,
+   SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
+
+  Syntax of Attribute   Encoding
+  Value
+
+  textWithoutLanguage,  LOCALIZED-STRING.
+  nameWithoutLanguage
+
+  textWithLanguage      OCTET-STRING consisting of 4 fields:
+                          a. a SIGNED-SHORT which is the number of
+                             octets in the following field
+                          b. a value of type natural-language,
+                          c. a SIGNED-SHORT which is the number of
+                             octets in the following field,
+                          d. a value of type textWithoutLanguage.
+                        The length of a textWithLanguage value MUST be
+                        4 + the value of field a + the value of field c.
+
+  nameWithLanguage      OCTET-STRING consisting of 4 fields:
+                          a. a SIGNED-SHORT which is the number of
+                             octets in the following field
+                          b. a value of type natural-language,
+                          c. a SIGNED-SHORT which is the number of
+                             octets in the following field
+                          d. a value of type nameWithoutLanguage.
+                        The length of a nameWithLanguage value MUST be
+                        4 + the value of field a + the value of field c.
+
+  charset,              US-ASCII-STRING.
+  naturalLanguage,
+  mimeMediaType,
+  keyword, uri, and
+  uriScheme
+
+
+
+Herriot, et al.             Standards Track                    [Page 17]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Syntax of Attribute   Encoding
+  Value
+
+  boolean               SIGNED-BYTE  where 0x00 is 'false' and 0x01 is
+                        'true'.
+
+  integer and enum      a SIGNED-INTEGER.
+
+  dateTime              OCTET-STRING consisting of eleven octets whose
+                        contents are defined by "DateAndTime" in RFC
+                        1903 [RFC1903].
+
+  resolution            OCTET-STRING consisting of nine octets of  2
+                        SIGNED-INTEGERs followed by a SIGNED-BYTE. The
+                        first SIGNED-INTEGER contains the value of
+                        cross feed direction resolution. The second
+                        SIGNED-INTEGER contains the value of feed
+                        direction resolution. The SIGNED-BYTE contains
+                        the units
+
+  rangeOfInteger        Eight octets consisting of 2 SIGNED-INTEGERs.
+                        The first SIGNED-INTEGER contains the lower
+                        bound and the second SIGNED-INTEGER contains
+                        the upper bound.
+
+  1setOf  X             Encoding according to the rules for an
+                        attribute with more than 1 value.  Each value
+                        X is encoded according to the rules for
+                        encoding its type.
+
+  octetString           OCTET-STRING
+
+
+   The attribute syntax type of the value determines its encoding and
+   the value of its "value-tag".
+
+3.10 Data
+
+   The "data" field MUST include any data required by the operation
+
+4. Encoding of Transport Layer
+
+   HTTP/1.1 [RFC2616] is the transport layer for this protocol.
+
+   The operation layer has been designed with the assumption that the
+   transport layer contains the following information:
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 18]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+      -  the URI of the target job or printer operation
+      -  the total length of the data in the operation layer, either as
+         a single length or as a sequence of chunks each with a length.
+
+   It is REQUIRED that a printer implementation support HTTP over the
+   IANA assigned Well Known Port 631 (the IPP default port), though a
+   printer implementation may support HTTP over some other port as well.
+
+   Each HTTP operation MUST use the POST method where the request-URI is
+   the object target of the operation, and where the "Content-Type" of
+   the message-body in each request and response MUST be
+   "application/ipp". The message-body MUST contain the operation layer
+   and MUST have the syntax described in section 3.2 "Syntax of
+   Encoding". A client implementation MUST adhere to the rules for a
+   client described for HTTP1.1 [RFC2616].  A printer (server)
+   implementation MUST adhere the rules for an origin server described
+   for HTTP1.1 [RFC2616].
+
+   An IPP server sends a response for each request that it receives.  If
+   an IPP server detects an error, it MAY send a response before it has
+   read the entire request.  If the HTTP layer of the IPP server
+   completes processing the HTTP headers successfully, it MAY send an
+   intermediate response, such as "100 Continue", with no IPP data
+   before sending the IPP response.  A client MUST expect such a variety
+   of responses from an IPP server. For further information on HTTP/1.1,
+   consult the HTTP documents [RFC2616].
+
+   An HTTP server MUST support chunking for IPP requests, and an IPP
+   client MUST support chunking for IPP responses according to  HTTP/1.1
+   [RFC2616].  Note: this rule causes a conflict with non-compliant
+   implementations of HTTP/1.1 that don't support chunking for POST
+   methods, and this rule may cause a conflict with non-compliant
+   implementations of HTTP/1.1 that don't support chunking for CGI
+   scripts.
+
+4.1 Printer-uri and job-uri
+
+   All Printer and Job objects are identified by a Uniform Resource
+   Identifier (URI) [RFC2396] so that they can be persistently and
+   unambiguously referenced.  Since every URL is a specialized form of a
+   URI, even though the more generic term URI is used throughout the
+   rest of this document, its usage is intended to cover the more
+   specific notion of URL as well.
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 19]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   Some operation elements are encoded twice, once as the request-URI on
+   the HTTP Request-Line and a second time as a REQUIRED operation
+   attribute in the application/ipp entity.  These attributes are the
+   target URI for the operation and are called printer-uri and job-uri.
+   Note: The target URI is included twice in an operation referencing
+   the same IPP object, but the two URIs NEED NOT be literally
+   identical. One can be a relative URI and the other can be an absolute
+   URI.  HTTP/1.1 allows clients to generate and send a relative URI
+   rather than an absolute URI.  A relative URI identifies a resource
+   with the scope of the HTTP server, but does not include scheme, host
+   or port.  The following statements characterize how URLs should be
+   used in the mapping of IPP onto HTTP/1.1:
+
+      1. Although potentially redundant, a client MUST supply the target
+         of the operation both as an operation attribute and as a URI at
+         the HTTP layer.  The rationale for this decision is to maintain
+         a consistent set of rules for mapping application/ipp to
+         possibly many communication layers, even where URLs are not
+         used as the addressing mechanism in the transport layer.
+      2. Even though these two URLs might not be literally identical
+         (one being relative and the other being absolute), they MUST
+         both reference the same IPP object. However, a Printer NEED NOT
+         verify that the two URLs reference the same IPP object, and
+         NEED NOT take any action if it determines the two URLs to be
+         different.
+      3. The URI in the HTTP layer is either relative or absolute and is
+         used by the HTTP server to route the HTTP request to the
+         correct resource relative to that HTTP server.  The HTTP server
+         need not be aware of the URI within the operation request.
+      4. Once the HTTP server resource begins to process the HTTP
+         request, it might get the reference to the appropriate IPP
+         Printer object from either the HTTP URI (using to the context
+         of the HTTP server for relative URLs) or from the URI within
+         the operation request; the choice is up to the implementation.
+      5. HTTP URIs can be relative or absolute, but the target URI in
+         the operation MUST be an absolute URI.
+
+5. IPP URL Scheme
+
+   The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL
+   that identifies either an IPP printer object or an IPP job object.
+   The IPP attributes using the 'ipp' scheme are specified below.
+   Because the HTTP layer does not support the 'ipp' scheme, a client
+   MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP
+   [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP
+   headers.  The mapping is simple because the 'ipp' scheme implies all
+   of the same protocol semantics as that of the 'http' scheme
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 20]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   [RFC2616], except that it represents a print service and the implicit
+   (default) port number that clients use to connect to a server is port
+   631.
+
+   In the remainder of this section the term 'ipp-URL' means a URL whose
+   scheme is 'ipp' and whose implicit (default) port is 631. The term
+   'http-URL' means a URL whose scheme is 'http', and the term 'https-
+   URL' means a URL whose scheme is 'https',
+
+   A client and an IPP object (i.e. the server) MUST support the ipp-URL
+   value in the following IPP attributes.
+       job attributes:
+           job-uri
+           job-printer-uri
+       printer attributes:
+           printer-uri-supported
+       operation attributes:
+           job-uri
+           printer-uri
+   Each of the above attributes identifies a printer or job object. The
+   ipp-URL is intended as the value of the attributes in this list, and
+   for no other attributes. All of these attributes have a syntax type
+   of 'uri', but there are attributes with a syntax type of 'uri' that
+   do not use the 'ipp' scheme, e.g. 'job-more-info'.
+
+   If a printer registers its URL with a directory service, the printer
+   MUST register an ipp-URL.
+
+   User interfaces are beyond the scope of this document. But if
+   software exposes the ipp-URL values of any of the above five
+   attributes to a human user, it is REQUIRED that the human see the
+   ipp-URL as is.
+
+   When a client sends a request, it MUST convert a target ipp-URL to a
+   target http-URL for the HTTP layer according to the following rules:
+
+      1. change the 'ipp' scheme to 'http'
+      2. add an explicit port 631 if the URL does not contain an
+         explicit port. Note: port 631 is the IANA assigned Well Known
+         Port for the 'ipp' scheme.
+
+   The client  MUST use the target http-URL in both the HTTP Request-
+   Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] .
+   However, the client MUST use the target ipp-URL for the value of the
+   "printer-uri" or "job-uri" operation attribute within the
+   application/ipp body of the request. The server MUST use the ipp-URL
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 21]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   for the value of the "printer-uri", "job-uri" or "printer-uri-
+   supported" attributes within the application/ipp body of the
+   response.
+
+   For example, when an IPP client sends a request directly (i.e. no
+   proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a
+   TCP connection to port 631 (the ipp implicit port) on the host
+   "myhost.com" and sends the following data:
+
+    POST /myprinter/myqueue HTTP/1.1
+    Host: myhost.com:631
+    Content-type: application/ipp
+    Transfer-Encoding: chunked
+    ...
+    "printer-uri" "ipp://myhost.com/myprinter/myqueue"
+              (encoded in application/ipp message body)
+    ...
+
+   As another example, when an IPP client sends the same request as
+   above via a proxy "myproxy.com", it opens a TCP connection to the
+   proxy port 8080 on the proxy host "myproxy.com" and sends the
+   following data:
+
+    POST http://myhost.com:631/myprinter/myqueue   HTTP/1.1
+    Host: myhost.com:631
+    Content-type: application/ipp
+    Transfer-Encoding: chunked
+    ...
+    "printer-uri" "ipp://myhost.com/myprinter/myqueue"
+              (encoded in application/ipp message body)
+    ...
+
+   The proxy then connects to the IPP origin server with headers that
+   are the same as the "no-proxy" example above.
+
+6. IANA Considerations
+
+   This section describes the procedures for allocating encoding for the
+   following IETF standards track extensions and vendor extensions to
+   the IPP/1.1 Encoding and Transport document:
+
+      1. attribute syntaxes - see [RFC2911] section 6.3
+      2. attribute groups - see [RFC2911] section 6.5
+      3. out-of-band attribute values - see [RFC2911] section 6.7
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 22]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   These extensions follow the "type2" registration procedures defined
+   in [RFC2911] section 6.  Extensions registered for use with IPP/1.1
+   are OPTIONAL for client and IPP object conformance to the IPP/1.1
+   Encoding and Transport document.
+
+   These extension procedures are aligned with the guidelines as set
+   forth by the IESG [IANA-CON].  The [RFC2911] Section 11 describes how
+   to propose new registrations for consideration.  IANA will reject
+   registration proposals that leave out required information or do not
+   follow the appropriate format described in [RFC2911] Section 11.  The
+   IPP/1.1 Encoding and Transport document may also be extended by an
+   appropriate RFC that specifies any of the above extensions.
+
+7. Internationalization Considerations
+
+   See the section on "Internationalization Considerations" in the
+   document "Internet Printing Protocol/1.1: Model and Semantics"
+   [RFC2911] for information on internationalization. This document adds
+   no additional issues.
+
+8. Security Considerations
+
+   The IPP Model and Semantics document [RFC2911] discusses high level
+   security requirements (Client Authentication, Server Authentication
+   and Operation Privacy). Client Authentication is the mechanism by
+   which the client proves its identity to the server in a secure
+   manner. Server Authentication is the mechanism by which the server
+   proves its identity to the client in a secure manner. Operation
+   Privacy is defined as a mechanism for protecting operations from
+   eavesdropping.
+
+8.1 Security Conformance Requirements
+
+   This section defines the security requirements for IPP clients and
+   IPP objects.
+
+8.1.1 Digest Authentication
+
+   IPP clients MUST support:
+
+      Digest Authentication [RFC2617].
+
+         MD5 and MD5-sess MUST be implemented and supported.
+
+         The Message Integrity feature NEED NOT be used.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 23]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   IPP Printers SHOULD support:
+
+      Digest Authentication [RFC2617].
+
+         MD5 and MD5-sess MUST be implemented and supported.
+
+         The Message Integrity feature NEED NOT be used.
+
+   The reasons that IPP Printers SHOULD (rather than MUST) support
+   Digest Authentication are:
+
+   1. While Client Authentication is important, there is a certain class
+      of printer devices where it does not make sense.  Specifically, a
+      low-end device with limited ROM space and low paper throughput may
+      not need Client Authentication.  This class of device typically
+      requires firmware designers to make trade-offs between protocols
+      and functionality to arrive at the lowest-cost solution possible.
+      Factored into the designer's decisions is not just the size of the
+      code, but also the testing, maintenance, usefulness, and time-to-
+      market impact for each feature delivered to the customer.  Forcing
+      such low-end devices to provide security in order to claim IPP/1.1
+      conformance would not make business sense and could potentially
+      stall the adoption of the standard.
+
+   2. Print devices that have high-volume throughput and have available
+      ROM space have a compelling argument to provide support for Client
+      Authentication that safeguards the device from unauthorized
+      access.  These devices are prone to a high loss of consumables and
+      paper if unauthorized access should occur.
+
+8.1.2 Transport Layer Security (TLS)
+
+   IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]
+   for Server Authentication and Operation Privacy. IPP Printers MAY
+   also support TLS for Client Authentication.  If an IPP Printer
+   supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
+   cipher suite as mandated by RFC 2246 [RFC2246].  All other cipher
+   suites are OPTIONAL.  An IPP Printer MAY support Basic Authentication
+   (described in HTTP/1.1 [RFC2617])  for Client Authentication if the
+   channel is secure. TLS with the above mandated cipher suite can
+   provide such a secure channel.
+
+   If a IPP client supports TLS, it MUST support the
+   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC
+   2246 [RFC2246].  All other cipher suites are OPTIONAL.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 24]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   The IPP Model and Semantics document defines two printer attributes
+   ("uri-authentication-supported" and "uri-security-supported") that
+   the client can use to discover the security policy of a printer. That
+   document also outlines IPP-specific security considerations and
+   should be the primary reference for security implications with regard
+   to the IPP protocol itself.  For backward compatibility with IPP
+   version 1.0, IPP clients and printers may also support SSL3 [ssl].
+   This is in addition to the security required in this document.
+
+8.2 Using IPP with TLS
+
+   IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism
+   [RFC2817].  An initial IPP request never uses TLS.  The client
+   requests a secure TLS connection by using the HTTP "Upgrade" header,
+   while the server agrees in the HTTP response.  The switch to TLS
+   occurs either because the server grants the client's request to
+   upgrade to TLS, or a server asks to switch to TLS in its response.
+   Secure communication begins with a server's response to switch to
+   TLS.
+
+9. Interoperability with IPP/1.0 Implementations
+
+   It is beyond the scope of this specification to mandate conformance
+   with previous versions.  IPP/1.1 was deliberately designed, however,
+   to make supporting previous versions easy.  It is worth noting that,
+   at the time of composing this specification (1999), we would expect
+   IPP/1.1 Printer implementations to:
+
+      understand any valid request in the format of IPP/1.0, or 1.1;
+
+      respond appropriately with a response containing the same
+      "version-number" parameter value used by the client in the
+      request.
+
+   And we would expect IPP/1.1 clients to:
+
+      understand any valid response in the format of IPP/1.0, or 1.1.
+
+9.1 The "version-number" Parameter
+
+   The following are rules regarding the "version-number" parameter (see
+   section 3.3):
+
+      1. Clients MUST send requests containing a "version-number"
+         parameter with a '1.1' value and SHOULD try supplying alternate
+         version numbers if they receive a 'server-error-version-not-
+         supported' error return in a response.
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 25]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+      2. IPP objects MUST accept requests containing a "version-number"
+         parameter with a '1.1' value (or reject the request for reasons
+         other than 'server-error-version-not-supported').
+
+      3. It is recommended that IPP objects accept any request with the
+         major version '1' (or reject the request for reasons other than
+         'server-error-version-not-supported').  See [RFC2911]
+         "versions" sub-section.
+
+      4. In any case, security MUST NOT be compromised when a client
+         supplies a lower "version-number" parameter in a request.  For
+         example, if an IPP/1.1 conforming Printer object accepts
+         version '1.0' requests and is configured to enforce Digest
+         Authentication, it MUST do the same for a version '1.0'
+         request.
+
+9.2 Security and URL Schemes
+
+   The following are rules regarding security, the "version-number"
+   parameter, and the URL scheme supplied in target attributes and
+   responses:
+
+      1. When a client supplies a request, the "printer-uri" or "job-
+         uri" target operation attribute MUST have the same scheme as
+         that indicated in one of the values of the "printer-uri-
+         supported" Printer attribute.
+
+      2. When the server returns the "job-printer-uri" or "job-uri" Job
+         Description attributes, it SHOULD return the same scheme
+         ('ipp', 'https', 'http', etc.) that the client supplied in the
+         "printer-uri" or "job-uri" target operation attributes in the
+         Get-Job-Attributes or Get-Jobs request, rather than the scheme
+         used when the job was created.  However, when a client requests
+         job attributes using the Get-Job-Attributes or Get-Jobs
+         operations, the jobs and job attributes that the server returns
+         depends on: (1) the security in effect when the job was
+         created, (2) the security in effect in the query request, and
+         (3) the security policy in force.
+
+      3. It is recommended that if a server registers a non-secure ipp-
+         URL with a directory service (see [RFC2911] "Generic Directory
+         Schema" Appendix), then it also register an http-URL for
+         interoperability with IPP/1.0 clients (see section 9).
+
+      4. In any case, security MUST NOT be compromised when a client
+         supplies an 'http' or other non-secure URL scheme in the target
+         "printer-uri" and "job-uri" operation attributes in a request.
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 26]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+10. References
+
+   [dpa]      ISO/IEC 10175 Document Printing Application (DPA), June
+              1996.
+
+   [iana]     IANA Registry of Coded Character Sets:
+              ftp://ftp.isi.edu/in-notes/iana/assignments/character-
+              sets.
+
+   [IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [ipp-iig]  Hastings, Tom, et al., "Internet Printing Protocol/1.1:
+              Implementer's Guide", Work in Progress.
+
+   [RFC822]   Crocker, D., "Standard for the Format of ARPA Internet
+              Text Messages", STD 11, RFC 822, August 1982.
+
+   [RFC1123]  Braden, S., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October, 1989.
+
+   [RFC1179]  McLaughlin, L. III, (editor), "Line Printer Daemon
+              Protocol", RFC 1179, August 1990.
+
+   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
+              RFC 2223, October 1997.
+
+   [RFC1738]  Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+              Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC1759]  Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+              Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+   [RFC1766]  Alvestrand, H., "Tags for the Identification of
+              Languages", RFC 1766, March 1995.
+
+   [RFC1808]  Fielding, R., "Relative Uniform Resource Locators", RFC
+              1808, June 1995.
+
+   [RFC1903]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+              "Textual Conventions for Version 2 of the Simple Network
+              Management Protocol (SNMPv2)", RFC 1903, January 1996.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 27]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   [RFC2048]  Freed, N., Klensin, J. and J. Postel, "Multipurpose
+              Internet Mail Extension (MIME) Part Four: Registration
+              Procedures", BCP 13, RFC 2048, November 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2184]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
+              Word Extensions: Character Sets, Languages, and
+              Continuations", RFC 2184, August 1997.
+
+   [RFC2234]  Crocker, D. and P. Overall, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246.
+              January 1999.
+
+   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Turner,
+              "Internet Printing Protocol/1.0: Encoding and Transport",
+              RFC 2565, April 1999.
+
+   [RFC2566]  deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
+              Powell, "Internet Printing Protocol/1.0: Model and
+              Semantics", RFC 2566, April 1999.
+
+   [RFC2567]  Wright, D., "Design Goals for an Internet Printing
+              Protocol", RFC2567, April 1999.
+
+   [RFC2568]  Zilles, S., "Rationale for the Structure and Model and
+              Protocol for the Internet Printing Protocol", RFC 2568,
+              April 1999.
+
+   [RFC2569]  Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+              "Mapping between LPD and IPP Protocols", RFC 2569, April
+              1999.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+              Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+              Leach, P., Luotonen, A. and L. Stewart, "HTTP
+              Authentication: Basic and Digest Access Authentication",
+              RFC 2617, June 1999.
+
+
+
+Herriot, et al.             Standards Track                    [Page 28]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   [RFC2817]  Khare, R. and S. Lawrence, "Upgrading to TLS Within
+              HTTP/1.1", RFC 2817, May 2000.
+
+   [RFC2910]  Herriot, R., Butler, S., Moore, P., Turner, R. and J.
+              Wenn, "Internet Printing Protocol/1.1: Encoding and
+              Transport", RFC 2910, September 2000.
+
+   [RFC2911]  Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
+              Powell, "Internet Printing Protocol/1.1: Model and
+              Semantics", RFC 2911, September 2000.
+
+   [SSL]      Netscape, The SSL Protocol, Version 3, (Text version
+              3.02), November 1996.
+
+11. Authors' Addresses
+
+   Robert Herriot, Editor
+   Xerox Corporation
+   3400 Hillview Ave., Bldg #1
+   Palo Alto, CA 94304
+
+   Phone: 650-813-7696
+   Fax:   650-813-6860
+   EMail: robert.herriot@pahv.xerox.com
+
+
+   Sylvan Butler
+   Hewlett-Packard
+   11311 Chinden Blvd.
+   Boise, ID 83714
+
+   Phone: 208-396-6000
+   Fax: 208-396-3457
+   EMail: sbutler@boi.hp.com
+
+
+   Paul Moore
+   Peerless Systems Networking
+   10900 NE 8th St #900
+   Bellevue, WA 98004
+
+   Phone: 425-462-5852
+   EMail: pmoore@peerless.com
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 29]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   Randy Turner
+   2Wire, Inc.
+   694 Tasman Dr.
+   Milpitas, CA 95035
+
+   Phone: 408-546-1273
+
+
+   John Wenn
+   Xerox Corporation
+   737 Hawaii St
+   El Segundo, CA  90245
+
+   Phone: 310-333-5764
+   Fax: 310-333-5514
+   EMail: jwenn@cp10.es.xerox.com
+
+
+   IPP Web Page: http://www.pwg.org/ipp/
+   IPP Mailing List: ipp@pwg.org
+
+   To subscribe to the ipp mailing list, send the following email:
+      1) send it to majordomo@pwg.org
+      2) leave the subject line blank
+      3) put the following two lines in the message body:
+              subscribe ipp
+              end
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 30]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+12. Other Participants:
+
+   Chuck Adams - Tektronix             Shivaun Albright - HP
+   Stefan Andersson - Axis             Jeff Barnett - IBM
+   Ron Bergman - Hitachi Koki Imaging  Dennis Carney - IBM
+   Systems
+   Keith Carter - IBM                  Angelo Caruso - Xerox
+   Rajesh Chawla - TR Computing        Nancy Chen - Okidata
+   Solutions
+   Josh Cohen - Microsoft              Jeff Copeland - QMS
+   Andy Davidson - Tektronix           Roger deBry - IBM
+   Maulik Desai - Auco                 Mabry Dozier - QMS
+   Lee Farrell - Canon Information     Satoshi Fujitami - Ricoh
+   Systems
+   Steve Gebert - IBM                  Sue Gleeson - Digital
+   Charles Gordon - Osicom             Brian Grimshaw - Apple
+   Jerry Hadsell - IBM                 Richard Hart - Digital
+   Tom Hastings - Xerox                Henrik Holst - I-data
+   Stephen Holmstead                   Zhi-Hong Huang - Zenographics
+   Scott Isaacson - Novell             Babek Jahromi - Microsoft
+   Swen Johnson - Xerox                David Kellerman - Northlake
+                                       Software
+   Robert Kline - TrueSpectra          Charles Kong - Panasonic
+   Carl Kugler - IBM                   Dave Kuntz - Hewlett-Packard
+   Takami Kurono - Brother             Rick Landau - Digital
+   Scott Lawrence - Agranot Systems    Greg LeClair - Epson
+   Dwight Lewis - Lexmark              Harry Lewis - IBM
+   Tony Liao - Vivid Image             Roy Lomicka - Digital
+   Pete Loya - HP                      Ray Lutz - Cognisys
+   Mike MacKay - Novell, Inc.          David Manchala - Xerox
+   Carl-Uno Manros - Xerox             Jay Martin - Underscore
+   Stan McConnell - Xerox              Larry Masinter - Xerox
+   Sandra Matts - Hewlett Packard      Peter Michalek - Shinesoft
+   Ira McDonald - High North Inc.      Mike Moldovan - G3 Nova
+   Tetsuya Morita - Ricoh              Yuichi Niwa - Ricoh
+   Pat Nogay - IBM                     Ron Norton - Printronics
+   Hugo Parra, Novell                  Bob Pentecost - Hewlett-Packard
+   Patrick Powell - Astart             Jeff Rackowitz - Intermec
+   Technologies
+   Eric Random - Peerless              Rob Rhoads - Intel
+   Xavier Riley - Xerox                Gary Roberts - Ricoh
+   David Roach - Unisys                Stuart Rowley - Kyocera
+   Yuji Sasaki - Japan Computer        Richard Schneider - Epson
+   Industry
+   Kris Schoff - HP                    Katsuaki Sekiguchi - Canon
+                                       Information Systems
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 31]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   Bob Setterbo - Adobe                Gail Songer - Peerless
+   Hideki Tanaka - Cannon Information  Devon Taylor - Novell, Inc.
+   Systems
+   Mike Timperman - Lexmark            Atsushi Uchino - Epson
+   Shigeru Ueda - Canon                Bob Von Andel - Allegro Software
+   William Wagner - NetSilicon/DPI     Jim Walker - DAZEL
+   Chris Wellens - Interworking Labs   Trevor Wells - Hewlett Packard
+   Craig Whittle - Sharp Labs          Rob Whittle - Novell, Inc.
+   Jasper Wong - Xionics               Don Wright - Lexmark
+   Michael Wu - Heidelberg Digital     Rick Yardumian - Xerox
+   Michael Yeung - Canon Information   Lloyd Young - Lexmark
+   Systems
+   Atsushi Yuki - Kyocera              Peter Zehler - Xerox
+   William Zhang - Canon Information   Frank Zhao - Panasonic
+   Systems
+   Steve Zilles - Adobe                Rob Zirnstein - Canon Information
+                                       Systems
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 32]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+13. Appendix A: Protocol Examples
+
+13.1 Print-Job Request
+
+   The following is an example of a Print-Job request with job-name,
+   copies, and sides specified. The "ipp-attribute-fidelity" attribute
+   is set to 'true' so that the print request will fail if the "copies"
+   or the "sides" attribute are not supported or their values are not
+   supported.
+
+  Octets          Symbolic Value                Protocol field
+
+  0x0101          1.1                           version-number
+  0x0002          Print-Job                     operation-id
+  0x00000001      1                             request-id
+  0x01            start operation-attributes    operation-attributes-tag
+  0x47            charset type                  value-tag
+  0x0012                                        name-length
+  attributes-     attributes-charset            name
+  charset
+  0x0008                                        value-length
+  us-ascii        US-ASCII                      value
+  0x48            natural-language type         value-tag
+  0x001B                                        name-length
+  attributes-                                   name
+  natural-        attributes-natural-language
+  language
+  0x0005                                        value-length
+  en-us           en-US                         value
+  0x45            uri type                      value-tag
+  0x000B                                        name-length
+  printer-uri     printer-uri                   name
+  0x0015                                        value-length
+  ipp://forest/   printer pinetree              value
+    pinetree
+  0x42            nameWithoutLanguage type      value-tag
+  0x0008                                        name-length
+  job-name        job-name                      name
+  0x0006                                        value-length
+  foobar          foobar                        value
+  0x22            boolean type                  value-tag
+  0x0016                                        name-length
+  ipp-attribute-  ipp-attribute-fidelity        name
+  fidelity
+  0x0001                                        value-length
+  0x01            true                          value
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 33]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets          Symbolic Value                Protocol field
+
+  0x02            start job-attributes          job-attributes-tag
+  0x21            integer type                  value-tag
+  0x0006                                        name-length
+  copies          copies                        name
+  0x0004                                        value-length
+  0x00000014      20                            value
+  0x44            keyword type                  value-tag
+  0x0005                                        name-length
+  sides           sides                         name
+  0x0013                                        value-length
+  two-sided-      two-sided-long-edge           value
+  long-edge
+  0x03            end-of-attributes             end-of-attributes-tag
+  %!PS...         <PostScript>                  data
+
+13.2 Print-Job Response (successful)
+
+   Here is an example of a successful Print-Job response to the previous
+   Print-Job request.  The printer supported the "copies" and "sides"
+   attributes and their supplied values.  The status code returned is
+   'successful-ok'.
+
+  Octets            Symbolic Value              Protocol field
+
+  0x0101            1.1                         version-number
+  0x0000            successful-ok               status-code
+  0x00000001        1                           request-id
+  0x01              start operation-attributes  operation-attributes-tag
+  0x47              charset type                value-tag
+  0x0012                                        name-length
+  attributes-       attributes-charset          name
+  charset
+  0x0008                                        value-length
+  us-ascii          US-ASCII                    value
+  0x48              natural-language type       value-tag
+  0x001B                                        name-length
+  attributes-       attributes-natural-         name
+  natural-language  language
+  0x0005                                        value-length
+  en-us             en-US                       value
+  0x41              textWithoutLanguage type    value-tag
+  0x000E                                        name-length
+  status-message    status-message              name
+  0x000D                                        value-length
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 34]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets            Symbolic Value              Protocol field
+
+  successful-ok     successful-ok               value
+  0x02              start job-attributes        job-attributes-tag
+  0x21              integer                     value-tag
+  0x0006                                        name-length
+  job-id            job-id                      name
+  0x0004                                        value-length
+  147               147                         value
+  0x45              uri type                    value-tag
+  0x0007                                        name-length
+  job-uri           job-uri                     name
+  0x0019                                        value-length
+  ipp://forest/     job 123 on pinetree         value
+    pinetree/123
+  0x23              enum type                   value-tag
+  0x0009                                        name-length
+  job-state         job-state                   name
+  0x0004                                        value-length
+  0x0003            pending                     value
+  0x03              end-of-attributes           end-of-attributes-tag
+
+13.3 Print-Job Response (failure)
+
+   Here is an example of an unsuccessful Print-Job response to the
+   previous Print-Job request. It fails because, in this case, the
+   printer does not support the "sides" attribute and because the value
+   '20' for the "copies" attribute is not supported. Therefore, no job
+   is created, and neither a "job-id" nor a "job-uri" operation
+   attribute is returned. The error code returned is 'client-error-
+   attributes-or-values-not-supported' (0x040B).
+
+  0x0101        1.1                           version-number
+  0x040B        client-error-attributes-or-   status-code
+                values-not-supported
+  0x00000001    1                             request-id
+  0x01          start operation-attributes    operation-attributes tag
+  0x47          charset type                  value-tag
+  0x0012                                      name-length
+  attributes-   attributes-charset            name
+  charset
+  0x0008                                      value-length
+  us-ascii      US-ASCII                      value
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 35]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets        Symbolic Value                Protocol field
+
+  0x48          natural-language type         value-tag
+  0x001B                                      name-length
+  attributes-   attributes-natural-language   name
+  natural-
+  language
+  0x0005                                      value-length
+  en-us         en-US                         value
+  0x41          textWithoutLanguage type      value-tag
+  0x000E                                      name-length
+  status-       status-message                name
+  message
+  0x002F                                      value-length
+  client-error-                               value
+  attributes-   values-not-supported
+  or-values-    client-error-attributes-or-
+  not-supported
+  0x05          start unsupported-attributes  unsupported-attributes tag
+  0x21          integer type                  value-tag
+  0x0006                                      name-length
+  copies        copies                        name
+  0x0004                                      value-length
+  0x00000014    20                            value
+  0x10          unsupported  (type)           value-tag
+  0x0005                                      name-length
+  sides         sides                         name
+  0x0000                                      value-length
+  0x03          end-of-attributes             end-of-attributes-tag
+
+13.4 Print-Job Response (success with attributes ignored)
+
+   Here is an example of a successful Print-Job response to a Print-Job
+   request like the previous Print-Job request, except that the value of
+   'ipp-attribute-fidelity' is false. The print request succeeds, even
+   though, in this case, the printer supports neither the "sides"
+   attribute nor the value '20' for the "copies" attribute. Therefore, a
+   job is created, and both a "job-id" and a "job-uri" operation
+   attribute are returned. The unsupported attributes are also returned
+   in an Unsupported Attributes Group. The error code returned is
+   'successful-ok-ignored-or-substituted-attributes' (0x0001).
+
+  Octets            Symbolic Value              Protocol field
+
+  0x0101            1.1                         version-number
+  0x0001            successful-ok-ignored-or-   status-code
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 36]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets            Symbolic Value              Protocol field
+
+                    substituted-attributes
+  0x00000001        1                           request-id
+  0x01              start operation-attributes  operation-attributes-tag
+  0x47              charset type                value-tag
+  0x0012                                        name-length
+  attributes-       attributes-charset          name
+  charset
+  0x0008                                        value-length
+  us-ascii          US-ASCII                    value
+  0x48              natural-language type       value-tag
+  0x001B                                        name-length
+  attributes-       attributes-natural-         name
+  natural-language  language
+  0x0005                                        value-length
+  en-us             en-US                       value
+  0x41              textWithoutLanguage type    value-tag
+  0x000E                                        name-length
+  status-message    status-message              name
+  0x002F                                        value-length
+  successful-ok-    successful-ok-ignored-or-   value
+  ignored-or-       substituted-attributes
+  substituted-
+  attributes
+  0x05              start unsupported-          unsupported-attributes
+                    attributes                  tag
+  0x21              integer type                value-tag
+  0x0006                                        name-length
+  copies            copies                      name
+  0x0004                                        value-length
+  0x00000014        20                          value
+  0x10              unsupported  (type)         value-tag
+  0x0005                                        name-length
+  sides             sides                       name
+  0x0000                                        value-length
+  0x02              start job-attributes        job-attributes-tag
+  0x21              integer                     value-tag
+  0x0006                                        name-length
+  job-id            job-id                      name
+  0x0004                                        value-length
+  147               147                         value
+  0x45              uri type                    value-tag
+  0x0007                                        name-length
+  job-uri           job-uri                     name
+  0x0019                                        value-length
+  ipp://forest/     job 123 on pinetree         value
+    pinetree/123
+
+
+
+Herriot, et al.             Standards Track                    [Page 37]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets           Symbolic Value               Protocol field
+
+  0x23              enum  type                  value-tag
+  0x0009                                        name-length
+  job-state         job-state                   name
+  0x0004                                        value-length
+  0x0003            pending                     value
+  0x03              end-of-attributes           end-of-attributes-tag
+
+13.5 Print-URI Request
+
+   The following is an example of Print-URI request with copies and
+   job-name parameters:
+
+  Octets         Symbolic Value               Protocol field
+
+  0x0101         1.1                          version-number
+  0x0003         Print-URI                    operation-id
+  0x00000001     1                            request-id
+  0x01           start operation-attributes   operation-attributes-tag
+  0x47           charset type                 value-tag
+  0x0012                                      name-length
+  attributes-    attributes-charset           name
+  charset
+  0x0008                                      value-length
+  us-ascii       US-ASCII                     value
+  0x48           natural-language type        value-tag
+  0x001B                                      name-length
+  attributes-    attributes-natural-language  name
+  natural-
+  language
+  0x0005                                      value-length
+  en-us          en-US                        value
+  0x45           uri type                     value-tag
+  0x000B                                      name-length
+  printer-uri    printer-uri                  name
+  0x0015                                      value-length
+  ipp://forest/  printer pinetree             value
+    pinetree
+  0x45           uri type                     value-tag
+  0x000C                                      name-length
+  document-uri   document-uri                 name
+  0x0011                                      value-length
+  ftp://foo.com  ftp://foo.com/foo            value
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 38]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets         Symbolic Value               Protocol field
+
+  /foo
+  0x42           nameWithoutLanguage type     value-tag
+  0x0008                                      name-length
+  job-name       job-name                     name
+  0x0006                                      value-length
+  foobar         foobar                       value
+  0x02           start job-attributes         job-attributes-tag
+  0x21           integer type                 value-tag
+  0x0006                                      name-length
+  copies         copies                       name
+  0x0004                                      value-length
+  0x00000001     1                            value
+  0x03           end-of-attributes            end-of-attributes-tag
+
+13.6 Create-Job Request
+
+   The following is an example of Create-Job request with no parameters
+   and no attributes:
+
+  Octets         Symbolic Value               Protocol field
+
+  0x0101         1.1                          version-number
+  0x0005         Create-Job                   operation-id
+  0x00000001     1                            request-id
+  0x01           start operation-attributes   operation-attributes-tag
+  0x47           charset type                 value-tag
+  0x0012                                      name-length
+  attributes-    attributes-charset           name
+  charset
+  0x0008                                      value-length
+  us-ascii       US-ASCII                     value
+  0x48           natural-language type        value-tag
+  0x001B                                      name-length
+  attributes-    attributes-natural-language  name
+  natural-
+  language
+  0x0005                                      value-length
+  en-us          en-US                        value
+  0x45           uri type                     value-tag
+  0x000B                                      name-length
+  printer-uri    printer-uri                  name
+  0x0015                                      value-length
+  ipp://forest/  printer pinetree             value
+    pinetree
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 39]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets         Symbolic Value               Protocol field
+
+  inetree
+  0x03           end-of-attributes            end-of-attributes-tag
+
+13.7 Get-Jobs Request
+
+   The following is an example of Get-Jobs request with parameters but
+   no attributes:
+
+  Octets           Symbolic Value               Protocol field
+
+  0x0101           1.1                          version-number
+  0x000A           Get-Jobs                     operation-id
+  0x00000123       0x123                        request-id
+  0x01             start operation-attributes   operation-attributes-tag
+  0x47             charset type                 value-tag
+  0x0012                                        name-length
+  attributes-      attributes-charset           name
+  charset
+  0x0008                                        value-length
+  us-ascii         US-ASCII                     value
+  0x48             natural-language type        value-tag
+  0x001B                                        name-length
+  attributes-      attributes-natural-language  name
+  natural-
+  language
+  0x0005                                        value-length
+  en-us            en-US                        value
+  0x45             uri type                     value-tag
+  0x000B                                        name-length
+  printer-uri      printer-uri                  name
+  0x0015                                        value-length
+  ipp://forest/    printer pinetree             value
+  pinetree
+  0x21             integer type                 value-tag
+  0x0005                                        name-length
+  limit            limit                        name
+  0x0004                                        value-length
+  0x00000032       50                           value
+  0x44             keyword type                 value-tag
+  0x0014                                        name-length
+  requested-       requested-attributes         name
+  attributes
+  0x0006                                        value-length
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 40]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets           Symbolic Value               Protocol field
+
+  job-id           job-id                       value
+  0x44             keyword type                 value-tag
+  0x0000           additional value             name-length
+  0x0008                                        value-length
+  job-name         job-name                     value
+  0x44             keyword type                 value-tag
+  0x0000           additional value             name-length
+  0x000F                                        value-length
+  document-format  document-format              value
+  0x03             end-of-attributes            end-of-attributes-tag
+
+13.8 Get-Jobs Response
+
+   The following is an of Get-Jobs response from previous request with 3
+   jobs. The Printer returns no information about the second job
+   (because of security reasons):
+
+  Octets           Symbolic Value                Protocol field
+
+  0x0101           1.1                           version-number
+  0x0000           successful-ok                 status-code
+  0x00000123       0x123                         request-id (echoed
+                                                 back)
+  0x01             start operation-attributes    operation-attributes-tag
+  0x47             charset type                  value-tag
+  0x0012                                         name-length
+  attributes-      attributes-charset            name
+  charset
+  0x000A                                         value-length
+  ISO-8859-1       ISO-8859-1                    value
+  0x48             natural-language type         value-tag
+  0x001B                                         name-length
+  attributes-      attributes-natural-language   name
+  natural-
+  language
+  0x0005                                         value-length
+  en-us            en-US                         value
+  0x41             textWithoutLanguage type      value-tag
+  0x000E                                         name-length
+  status-message   status-message                name
+  0x000D                                         value-length
+  successful-ok    successful-ok                 value
+  0x02             start job-attributes (1st     job-attributes-tag
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 41]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+  Octets           Symbolic Value                Protocol field
+
+                   object)
+  0x21             integer type                  value-tag
+  0x0006                                         name-length
+  job-id           job-id                        name
+  0x0004                                         value-length
+  147              147                           value
+  0x36             nameWithLanguage              value-tag
+  0x0008                                         name-length
+  job-name         job-name                      name
+  0x000C                                         value-length
+  0x0005                                         sub-value-length
+  fr-ca            fr-CA                         value
+  0x0003                                         sub-value-length
+  fou              fou                           name
+  0x02             start job-attributes (2nd     job-attributes-tag
+                   object)
+  0x02             start job-attributes (3rd     job-attributes-tag
+                   object)
+  0x21             integer type                  value-tag
+  0x0006                                         name-length
+  job-id           job-id                        name
+  0x0004                                         value-length
+  148              149                           value
+  0x36             nameWithLanguage              value-tag
+  0x0008                                         name-length
+  job-name         job-name                      name
+  0x0012                                         value-length
+  0x0005                                         sub-value-length
+  de-CH            de-CH                         value
+  0x0009                                         sub-value-length
+  isch guet        isch guet                     name
+  0x03             end-of-attributes             end-of-attributes-tag
+
+14. Appendix B: Registration of MIME Media Type Information for
+   "application/ipp"
+
+   This appendix contains the information that IANA requires for
+   registering a MIME media type.  The information following this
+   paragraph will be forwarded to IANA to register application/ipp whose
+   contents are defined in Section 3 "Encoding of  the Operation Layer"
+   in this document:
+
+   MIME type name: application
+
+   MIME subtype name: ipp
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 42]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   A Content-Type of "application/ipp" indicates an Internet Printing
+   Protocol message body (request or response). Currently there is one
+   version: IPP/1.1, whose syntax is described in Section 3 "Encoding of
+   the Operation Layer" of [RFC2910], and whose semantics are described
+   in [RFC2911].
+
+   Required parameters:  none
+
+   Optional parameters:  none
+
+   Encoding considerations:
+
+   IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS
+   contain binary data (for example attribute value lengths).
+
+   Security considerations:
+
+   IPP/1.1 protocol requests/responses do not introduce any security
+   risks not already inherent in the underlying transport protocols.
+   Protocol mixed-version interworking rules in [RFC2911] as well as
+   protocol encoding rules in [RFC2910] are complete and unambiguous.
+
+   Interoperability considerations:
+
+   IPP/1.1 requests (generated by clients) and responses (generated by
+   servers) MUST comply with all conformance requirements imposed by the
+   normative specifications [RFC2911] and [RFC2910]. Protocol encoding
+   rules specified in [RFC2910] are comprehensive, so that
+   interoperability between conforming implementations is guaranteed
+   (although support for specific optional features is not ensured).
+   Both the "charset" and "natural-language" of all IPP/1.1 attribute
+   values which are a LOCALIZED-STRING  are explicit within IPP protocol
+   requests/responses (without recourse to any external information in
+   HTTP, SMTP, or other message transport headers).
+
+   Published specifications:
+
+   [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S.  and P.
+             Powell, "Internet Printing Protocol/1.1: Model and
+             Semantics", RFC 2911, September 2000.
+
+   [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R.  and J.
+             Wenn, "Internet Printing Protocol/1.1: Encoding and
+             Transport", RFC 2910, September 2000.
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 43]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   Applications which use this media type:
+
+   Internet Printing Protocol (IPP) print clients and print servers,
+   communicating using HTTP/1.1 (see [RFC2910]), SMTP/ESMTP, FTP, or
+   other transport protocol. Messages of type "application/ipp" are
+   self-contained and transport-independent, including "charset" and
+   "natural-language" context for any LOCALIZED-STRING value.
+
+   Person & email address to contact for further information:
+
+   Tom Hastings
+   Xerox Corporation
+   737 Hawaii St. ESAE-231
+   El Segundo, CA
+
+   Phone: 310-333-6413
+   Fax: 310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+   or
+
+   Robert Herriot
+   Xerox Corporation
+   3400 Hillview Ave., Bldg #1
+   Palo Alto, CA 94304
+
+   Phone: 650-813-7696
+   Fax: 650-813-6860
+   EMail: robert.herriot@pahv.xerox.com
+
+   Intended usage:
+
+   COMMON
+
+15. Appendix C: Changes from IPP/1.0
+
+   IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
+
+   1. Attributes values that identify a printer or job object use a new
+      'ipp' scheme.  The 'http' and 'https' schemes are supported only
+      for backward compatibility.  See section 5.
+
+   2. Clients MUST support of Digest Authentication, IPP Printers SHOULD
+      support Digest Authentication.  See Section 8.1.1
+
+   3. TLS is recommended for channel security.  In addition, SSL3 may be
+      supported for backward compatibility.  See Section 8.1.2
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 44]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+   4. It is recommended that IPP/1.1 objects accept any request with
+      major version number '1'.  See section 9.1.
+
+   5. IPP objects SHOULD return the URL scheme requested for "job-
+      printer-uri" and "job-uri" Job Attributes, rather than the URL
+      scheme used to create the job.   See section 9.2.
+
+   6. The IANA and Internationalization sections have been added.  The
+      terms "private use" and "experimental" have been changed to
+      "vendor extension".  The reserved allocations for attribute group
+      tags, attribute syntax tags, and out-of-band attribute values have
+      been clarified as to which are reserved to future IETF standards
+      track documents and which are reserved to vendor extension.   Both
+      kinds of extensions use the type2 registration procedures as
+      defined in [RFC2911].
+
+   7. Clarified that future "out-of-band" value definitions may use the
+      value field if additional information is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 45]
+
+RFC 2910            IPP/1.1: Encoding and Transport       September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 46]
+
diff --git a/standards/rfc2911.txt b/standards/rfc2911.txt
new file mode 100644
index 000000000..29c85a426
--- /dev/null
+++ b/standards/rfc2911.txt
@@ -0,0 +1,12547 @@
+
+
+
+
+
+
+Network Working Group                                T. Hastings, Editor
+Request for Comments: 2911                                    R. Herriot
+Obsoletes: 2566                                        Xerox Corporation
+Category: Standards Track                                       R. deBry
+                                               Utah Valley State College
+                                                             S. Isaacson
+                                                            Novell, Inc.
+                                                               P. Powell
+                                                     Astart Technologies
+                                                          September 2000
+
+
+          Internet Printing Protocol/1.1: Model and Semantics
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document is one of a set of documents, which together describe
+   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
+   application level protocol that can be used for distributed printing
+   using Internet tools and technologies.  This document describes a
+   simplified model consisting of abstract objects, their attributes,
+   and their operations that is independent of encoding and transport.
+   The model consists of a Printer and a Job object.  A Job optionally
+   supports multiple documents.  IPP 1.1 semantics allow end-users and
+   operators to query printer capabilities, submit print jobs, inquire
+   about the status of print jobs and printers, cancel, hold, release,
+   and restart print jobs.  IPP 1.1 semantics allow operators to pause,
+   resume, and purge (jobs from) Printer objects.  This document also
+   addresses security, internationalization, and directory issues.
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                     [Page 1]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The full set of IPP documents includes:
+
+     Design Goals for an Internet Printing Protocol [RFC2567]
+     Rationale for the Structure and Model and Protocol for the Internet
+     Printing Protocol [RFC2568]
+     Internet Printing Protocol/1.1: Model and Semantics (this document)
+     Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+     Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
+     Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0.  A few OPTIONAL operator operations have
+   been added to IPP/1.1.
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF working group's major decisions.
+
+   The "Internet Printing Protocol/1.1: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1 [RFC2616].  It defines the
+   encoding rules for a new Internet MIME media type called
+   "application/ipp".  This document also defines the rules for
+   transporting over HTTP a message body whose Content-Type is
+   "application/ipp".  This document defines a new scheme named 'ipp'
+   for identifying IPP printers and jobs.
+
+   The "Internet Printing Protocol/1.1: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.1 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                     [Page 2]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+Table of Contents
+
+   1.   Introduction                                                 9
+   1.1   Simplified Printing Model                                  10
+   2.   IPP Objects                                                 12
+   2.1   Printer Object                                             13
+   2.2   Job Object                                                 15
+   2.3   Object Relationships                                       16
+   2.4   Object Identity                                            17
+   3.   IPP Operations                                              20
+   3.1   Common Semantics                                           21
+   3.1.1  Required Parameters                                       21
+   3.1.2  Operation IDs and Request IDs                             22
+   3.1.3  Attributes                                                22
+   3.1.4  Character Set and Natural Language Operation Attribute    24
+   3.1.4.1   Request Operation Attributes                           25
+   3.1.4.2   Response Operation Attributes                          29
+   3.1.5  Operation Targets                                         30
+   3.1.6  Operation Response Status Codes and Status Messages       32
+   3.1.6.1   "status-code" (type2 enum)                             32
+   3.1.6.2   "status-message" (text(255))                           33
+   3.1.6.3   "detailed-status-message" (text(MAX))                  33
+   3.1.6.4   "document-access-error" (text(MAX))                    34
+   3.1.7  Unsupported Attributes                                    34
+   3.1.8  Versions                                                  36
+   3.1.9  Job Creation Operations                                   38
+   3.2   Printer Operations                                         41
+   3.2.1  Print-Job Operation                                       41
+   3.2.1.1   Print-Job Request                                      41
+   3.2.1.2   Print-Job Response                                     46
+   3.2.2  Print-URI Operation                                       48
+   3.2.3  Validate-Job Operation                                    49
+   3.2.4  Create-Job Operation                                      49
+   3.2.5  Get-Printer-Attributes Operation                          50
+   3.2.5.1   Get-Printer-Attributes Request                         51
+   3.2.5.2   Get-Printer-Attributes Response                        53
+   3.2.6  Get-Jobs Operation                                        54
+   3.2.6.1   Get-Jobs Request                                       54
+   3.2.6.2   Get-Jobs Response                                      56
+   3.2.7  Pause-Printer Operation                                   57
+   3.2.7.1   Pause-Printer Request                                  59
+   3.2.7.2   Pause-Printer Response                                 60
+   3.2.8  Resume-Printer Operation                                  60
+   3.2.9  Purge-Jobs Operation                                      61
+   3.3   Job Operations                                             62
+   3.3.1  Send-Document Operation                                   62
+   3.3.1.1   Send-Document Request                                  64
+   3.3.1.2   Send-Document Response                                 65
+
+
+
+Hastings, et al.            Standards Track                     [Page 3]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   3.3.2  Send-URI Operation                                        66
+   3.3.3  Cancel-Job Operation                                      66
+   3.3.3.1   Cancel-Job Request                                     67
+   3.3.3.2   Cancel-Job Response                                    68
+   3.3.4  Get-Job-Attributes Operation                              69
+   3.3.4.1   Get-Job-Attributes Request                             69
+   3.3.4.2   Get-Job-Attributes Response                            70
+   3.3.5  Hold-Job Operation                                        71
+   3.3.5.1   Hold-Job Request                                       72
+   3.3.5.2   Hold-Job Response                                      73
+   3.3.6  Release-Job Operation                                     74
+   3.3.7  Restart-Job Operation                                     75
+   3.3.7.1   Restart-Job Request                                    76
+   3.3.7.2   Restart-Job Response                                   78
+   4.   Object Attributes                                           78
+   4.1   Attribute Syntaxes                                         78
+   4.1.1  'text'                                                    79
+   4.1.1.1   'textWithoutLanguage'                                  80
+   4.1.1.2   'textWithLanguage'                                     80
+   4.1.2  'name'                                                    81
+   4.1.2.1   'nameWithoutLanguage'                                  82
+   4.1.2.2   'nameWithLanguage'                                     82
+   4.1.2.3   Matching 'name' attribute values                       83
+   4.1.3  'keyword'                                                 84
+   4.1.4  'enum'                                                    85
+   4.1.5  'uri'                                                     85
+   4.1.6  'uriScheme'                                               86
+   4.1.7  'charset'                                                 86
+   4.1.8  'naturalLanguage'                                         87
+   4.1.9  'mimeMediaType'                                           87
+   4.1.9.1 Application/octet-stream -- Auto-Sensing                 88
+           the document format
+   4.1.10 'octetString'                                             89
+   4.1.11 'boolean'                                                 89
+   4.1.12 'integer'                                                 89
+   4.1.13 'rangeOfInteger'                                          90
+   4.1.14 'dateTime'                                                90
+   4.1.15 'resolution'                                              90
+   4.1.16 '1setOf  X'                                               90
+   4.2   Job Template Attributes                                    91
+   4.2.1  job-priority (integer(1:100))                             94
+   4.2.2  job-hold-until (type3 keyword | name (MAX))               95
+   4.2.3  job-sheets (type3 keyword | name(MAX))                    96
+   4.2.4  multiple-document-handling (type2 keyword)                96
+   4.2.5  copies (integer(1:MAX))                                   98
+   4.2.6  finishings (1setOf type2 enum)                            98
+   4.2.7  page-ranges (1setOf rangeOfInteger (1:MAX))              101
+   4.2.8  sides (type2 keyword)                                    102
+
+
+
+Hastings, et al.            Standards Track                     [Page 4]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   4.2.9  number-up (integer(1:MAX))                               102
+   4.2.10 orientation-requested (type2 enum)                       103
+   4.2.11 media (type3 keyword | name(MAX))                        104
+   4.2.12 printer-resolution (resolution)                          105
+   4.2.13 print-quality (type2 enum)                               105
+   4.3   Job Description Attributes                                106
+   4.3.1  job-uri (uri)                                            107
+   4.3.2  job-id (integer(1:MAX))                                  108
+   4.3.3  job-printer-uri (uri)                                    108
+   4.3.4  job-more-info (uri)                                      108
+   4.3.5  job-name (name(MAX))                                     108
+   4.3.6  job-originating-user-name (name(MAX))                    109
+   4.3.7  job-state (type1 enum)                                   109
+   4.3.7.1   Forwarding Servers                                    112
+   4.3.7.2   Partitioning of Job States                            112
+   4.3.8  job-state-reasons (1setOf  type2 keyword)                113
+   4.3.9  job-state-message (text(MAX))                            118
+   4.3.10 job-detailed-status-messages (1setOf text(MAX))          118
+   4.3.11 job-document-access-errors (1setOf text(MAX))            118
+   4.3.12 number-of-documents (integer(0:MAX))                     119
+   4.3.13 output-device-assigned (name(127))                       119
+   4.3.14 Event Time Job Description Attributes                    119
+   4.3.14.1  time-at-creation (integer(MIN:MAX))                   120
+   4.3.14.2  time-at-processing (integer(MIN:MAX))                 120
+   4.3.14.3  time-at-completed (integer(MIN:MAX))                  120
+   4.3.14.4  job-printer-up-time (integer(1:MAX))                  120
+   4.3.14.5  date-time-at-creation (dateTime)                      121
+   4.3.14.6  date-time-at-processing (dateTime)                    121
+   4.3.14.7  date-time-at-completed (dateTime)                     121
+   4.3.15 number-of-intervening-jobs (integer(0:MAX))              121
+   4.3.16 job-message-from-operator (text(127))                    121
+   4.3.17 Job Size Attributes                                      121
+   4.3.17.1  job-k-octets (integer(0:MAX))                         122
+   4.3.17.2  job-impressions (integer(0:MAX))                      122
+   4.3.17.3  job-media-sheets (integer(0:MAX))                     123
+   4.3.18 Job Progress Attributes                                  123
+   4.3.18.1  job-k-octets-processed (integer(0:MAX))               123
+   4.3.18.2  job-impressions-completed (integer(0:MAX))            123
+   4.3.18.3  job-media-sheets-completed (integer(0:MAX))           124
+   4.3.19 attributes-charset (charset)                             124
+   4.3.20 attributes-natural-language (naturalLanguage)            124
+   4.4   Printer Description Attributes                            124
+   4.4.1  printer-uri-supported (1setOf uri)                       126
+   4.4.2  uri-authentication-supported (1setOf type2 keyword)      127
+   4.4.3  uri-security-supported (1setOf type2 keyword)            128
+   4.4.4  printer-name (name(127))                                 129
+   4.4.5  printer-location (text(127))                             129
+   4.4.6  printer-info (text(127))                                 130
+
+
+
+Hastings, et al.            Standards Track                     [Page 5]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   4.4.7  printer-more-info (uri)                                  130
+   4.4.8  printer-driver-installer (uri)                           130
+   4.4.9  printer-make-and-model (text(127))                       130
+   4.4.10 printer-more-info-manufacturer (uri)                     130
+   4.4.11 printer-state (type1 enum)                               131
+   4.4.12 printer-state-reasons (1setOf type2 keyword)             131
+   4.4.13 printer-state-message (text(MAX))                        134
+   4.4.14 ipp-versions-supported (1setOf type2 keyword)            134
+   4.4.15 operations-supported (1setOf type2 enum)                 135
+   4.4.16 multiple-document-jobs-supported (boolean)               136
+   4.4.17 charset-configured (charset)                             136
+   4.4.18 charset-supported (1setOf charset)                       137
+   4.4.19 natural-language-configured (naturalLanguage)            137
+   4.4.20 generated-natural-language-supported
+          (1setOf naturalLanguage)                                 137
+   4.4.21 document-format-default (mimeMediaType)                  138
+   4.4.22 document-format-supported (1setOf mimeMediaType)         138
+   4.4.23 printer-is-accepting-jobs (boolean)                      138
+   4.4.24 queued-job-count (integer(0:MAX))                        138
+   4.4.25 printer-message-from-operator (text(127))                139
+   4.4.26 color-supported (boolean)                                139
+   4.4.27 reference-uri-schemes-supported (1setOf uriScheme)       139
+   4.4.28 pdl-override-supported (type2 keyword)                   139
+   4.4.29 printer-up-time (integer(1:MAX))                         140
+   4.4.30 printer-current-time (dateTime)                          140
+   4.4.31 multiple-operation-time-out (integer(1:MAX))             141
+   4.4.32 compression-supported (1setOf type3 keyword)             141
+   4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX))           142
+   4.4.34 job-impressions-supported (rangeOfInteger(0:MAX))        142
+   4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX))       142
+   4.4.36 pages-per-minute (integer(0:MAX))                        142
+   4.4.37 pages-per-minute-color (integer(0:MAX))                  142
+   5.   Conformance                                                143
+   5.1   Client Conformance Requirements                           143
+   5.2   IPP Object Conformance Requirements                       145
+   5.2.1  Objects                                                  145
+   5.2.2  Operations                                               145
+   5.2.3  IPP Object Attributes                                    146
+   5.2.4  Versions                                                 146
+   5.2.5  Extensions                                               147
+   5.2.6  Attribute Syntaxes                                       147
+   5.2.7  Security                                                 148
+   5.3   Charset and Natural Language Requirements                 148
+   6.   IANA Considerations                                        148
+   6.1   Typed 'keyword' and 'enum' Extensions                     149
+   6.2   Attribute Extensibility                                   151
+   6.3   Attribute Syntax Extensibility                            152
+   6.4   Operation Extensibility                                   152
+
+
+
+Hastings, et al.            Standards Track                     [Page 6]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   6.5   Attribute Group Extensibility                             153
+   6.6   Status Code Extensibility                                 153
+   6.7   Out-of-band Attribute Value Extensibility                 154
+   6.8   Registration of MIME types/sub-types for document-formats 154
+   6.9   Registration of charsets for use in 'charset'
+         attribute values                                          154
+   7.   Internationalization Considerations                        154
+   8.   Security Considerations                                    158
+   8.1   Security Scenarios                                        159
+   8.1.1  Client and Server in the Same Security Domain            159
+   8.1.2  Client and Server in Different Security Domains          159
+   8.1.3  Print by Reference                                       160
+   8.2   URIs in Operation, Job, and Printer attributes            160
+   8.3   URIs for each authentication mechanisms                   160
+   8.4   Restricted Queries                                        161
+   8.5   Operations performed by operators and system
+         administrators                                            161
+   8.6   Queries on jobs submitted using non-IPP protocols         162
+   9.   References                                                 162
+   10.  Authors' Addresses                                         166
+   11.  Formats for IPP Registration Proposals                     168
+   11.1  Type2 keyword attribute values registration               169
+   11.2  Type3 keyword attribute values registration               169
+   11.3  Type2 enum attribute values registration                  169
+   11.4  Type3 enum attribute values registration                  170
+   11.5  Attribute registration                                    170
+   11.6  Attribute Syntax registration                             171
+   11.7  Operation registration                                    171
+   11.8  Attribute Group registration                              171
+   11.9  Status code registration                                  172
+   11.10 Out-of-band Attribute Value registration                  172
+   12.  APPENDIX A: Terminology                                    173
+   12.1  Conformance Terminology                                   173
+   12.1.1 NEED NOT                                                 173
+   12.2  Model Terminology                                         173
+   12.2.1 Keyword                                                  173
+   12.2.2 Attributes                                               173
+   12.2.2.1  Attribute Name                                        173
+   12.2.2.2  Attribute Group Name                                  174
+   12.2.2.3  Attribute Value                                       174
+   12.2.2.4  Attribute Syntax                                      174
+   12.2.3 Supports                                                 174
+   12.2.4 print-stream page                                        176
+   12.2.5 impression                                               177
+   13. APPENDIX B: Status Codes and Suggested Status Code Messages 177
+   13.1  Status Codes                                              178
+   13.1.1 Informational                                            178
+   13.1.2 Successful Status Codes                                  178
+
+
+
+Hastings, et al.            Standards Track                     [Page 7]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   13.1.2.1  successful-ok (0x0000)                                178
+   13.1.2.2  successful-ok-ignored-or-substituted-attributes
+             (0x0001)                                              179
+   13.1.2.3  successful-ok-conflicting-attributes (0x0002)         179
+   13.1.3 Redirection Status Codes                                 179
+   13.1.4 Client Error Status Codes                                179
+   13.1.4.1  client-error-bad-request (0x0400)                     180
+   13.1.4.2  client-error-forbidden (0x0401)                       180
+   13.1.4.3  client-error-not-authenticated (0x0402)               180
+   13.1.4.4  client-error-not-authorized (0x0403)                  180
+   13.1.4.5  client-error-not-possible (0x0404)                    180
+   13.1.4.6  client-error-timeout (0x0405)                         181
+   13.1.4.7  client-error-not-found (0x0406)                       181
+   13.1.4.8  client-error-gone (0x0407)                            181
+   13.1.4.9  client-error-request-entity-too-large (0x0408)        182
+   13.1.4.10 client-error-request-value-too-long (0x0409)          182
+   13.1.4.11 client-error-document-format-not-supported (0x040A)   182
+   13.1.4.12 client-error-attributes-or-values-not-supported
+             (0x040B)                                              183
+   13.1.4.13 client-error-uri-scheme-not-supported (0x040C)        183
+   13.1.4.14 client-error-charset-not-supported (0x040D)           183
+   13.1.4.15 client-error-conflicting-attributes (0x040E)          183
+   13.1.4.16 client-error-compression-not-supported (0x040F)       184
+   13.1.4.17 client-error-compression-error (0x0410)               184
+   13.1.4.18 client-error-document-format-error (0x0411)           184
+   13.1.4.19 client-error-document-access-error (0x0412)           184
+   13.1.5    Server Error Status Codes                             185
+   13.1.5.1  server-error-internal-error (0x0500)                  185
+   13.1.5.2  server-error-operation-not-supported (0x0501)         185
+   13.1.5.3  server-error-service-unavailable (0x0502)             185
+   13.1.5.4  server-error-version-not-supported (0x0503)           185
+   13.1.5.5  server-error-device-error (0x0504)                    186
+   13.1.5.6  server-error-temporary-error (0x0505)                 186
+   13.1.5.7  server-error-not-accepting-jobs (0x0506)              187
+   13.1.5.8  server-error-busy (0x0507)                            187
+   13.1.5.9  server-error-job-canceled (0x0508)                    187
+   13.1.5.10 server-error-multiple-document-jobs-not-supported
+             (0x0509)                                              187
+   13.2  Status Codes for IPP Operations                           187
+   14.  APPENDIX C:  "media" keyword values                        190
+   15.  APPENDIX D: Processing IPP Attributes                      208
+   15.1  Fidelity                                                  209
+   15.2  Page Description Language (PDL) Override                  210
+   15.3  Using Job Template Attributes During Document Processing  212
+   16.  APPENDIX E: Generic Directory Schema                       214
+   17.  APPENDIX F:  Differences between the IPP/1.0 and IPP/1.1
+        "Model and Semantics" Documents                            215
+   18.  Full Copyright Statement                                   224
+
+
+
+Hastings, et al.            Standards Track                     [Page 8]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+1. Introduction
+
+   The Internet Printing Protocol (IPP) is an application level protocol
+   that can be used for distributed printing using Internet tools and
+   technologies.  IPP version 1.1 (IPP/1.1) focuses primarily on end
+   user functionality with a few administrative operations included.
+   This document is just one of a suite of documents that fully define
+   IPP.  The full set of IPP documents includes:
+
+     Design Goals for an Internet Printing Protocol [RFC2567]
+     Rationale for the Structure and Model and Protocol for the Internet
+     Printing Protocol [RFC2568]
+     Internet Printing Protocol/1.1: Model and Semantics (this document)
+     Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+     Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
+     Mapping between LPD and IPP Protocols [RFC2569]
+
+   Anyone reading these documents for the first time is strongly
+   encouraged to read the IPP documents in the above order.
+
+   This document is laid out as follows:
+
+   - The rest of Section 1 is an introduction to the IPP simplified
+     model for distributed printing.
+   - Section 2 introduces the object types covered in the model with
+     their basic behaviors, attributes, and interactions.
+   - Section 3 defines the operations included in IPP/1.1.  IPP
+     operations are synchronous, therefore, for each operation, there is
+     a both request and a response.
+   - Section 4 defines the attributes (and their syntaxes) that are used
+     in the model.
+   - Sections 5 - 6 summarizes the implementation conformance
+     requirements for objects that support the protocol and IANA
+     considerations, respectively.
+   - Sections 7 - 11 cover the Internationalization and Security
+     considerations as well as References, Author contact information,
+     and Formats for Registration Proposals.
+   - Sections 12 - 14 are appendices that cover Terminology, Status
+     Codes and Messages, and "media" keyword values.
+
+       Note: This document uses terms such as "attributes", "keywords",
+       and "support".  These terms have special meaning and are defined
+       in the model terminology section 12.2.  Capitalized terms, such
+       as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT,
+       and OPTIONAL, have special meaning relating to conformance.
+       These terms are defined in section 12.1 on conformance
+       terminology, most of which is taken from RFC 2119 [RFC2119].
+
+
+
+
+Hastings, et al.            Standards Track                     [Page 9]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   - Section 15 is an appendix that helps to clarify the effects of
+     interactions between related attributes and their values.
+   - Section 16 is an appendix that enumerates the subset of Printer
+     attributes that form a generic directory schema.  These attributes
+     are useful when registering a Printer so that a client can find the
+     Printer not just by name, but by filtered searches as well.
+   - Section 17 is an appendix summarizing the additions and changes
+     from the IPP/1.0 "Model and Semantics" document [RFC2566] to make
+     this IPP/1.1 document.
+   - Section 18 is the full copyright notice.
+
+1.1 Simplified Printing Model
+
+   In order to achieve its goal of realizing a workable printing
+   protocol for the Internet, the Internet Printing Protocol (IPP) is
+   based on a simplified printing model that abstracts the many
+   components of real world printing solutions.  The Internet is a
+   distributed computing environment where requesters of print services
+   (clients, applications, printer drivers, etc.) cooperate and interact
+   with print service providers.  This model and semantics document
+   describes a simple, abstract model for IPP even though the underlying
+   configurations may be complex "n-tier" client/server systems.  An
+   important simplifying step in the IPP model is to expose only the key
+   objects and interfaces required for printing.  The model described in
+   this model document does not include features, interfaces, and
+   relationships that are beyond the scope of the first version of IPP
+   (IPP/1.1).  IPP/1.1 incorporates many of the relevant ideas and
+   lessons learned from other specification and development efforts
+   [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP].  IPP is
+   heavily influenced by the printing model introduced in the Document
+   Printing Application (DPA) [ISO10175] standard.  Although DPA
+   specifies both end user and administrative features, IPP version 1.1
+   (IPP/1.1) focuses primarily on end user functionality with a few
+   additional OPTIONAL operator operations.
+
+   The IPP/1.1 model encapsulates the important components of
+   distributed printing into two object types:
+
+      - Printer (Section 2.1)
+      - Job (Section 2.2)
+
+   Each object type has an associated set of operations (see section 3)
+   and attributes (see section 4).
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 10]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   It is important, however, to understand that in real system
+   implementations (which lie underneath the abstracted IPP/1.1 model),
+   there are other components of a print service which are not
+   explicitly defined in the IPP/1.1 model. The following figure
+   illustrates where IPP/1.1 fits with respect to these other
+   components.
+
+                                +--------------+
+                                |  Application |
+                      o         +. . . . . . . |
+                     \|/        |   Spooler    |
+                     / \        +. . . . . . . |   +---------+
+                   End-User     | Print Driver |---|  File   |
+         +-----------+ +-----+  +------+-------+   +----+----+
+         |  Browser  | | GUI |         |                |
+         +-----+-----+ +--+--+         |                |
+               |          |            |                |
+               |      +---+------------+---+            |
+   N   D   S   |      |      IPP Client    |------------+
+   O   I   E   |      +---------+----------+
+   T   R   C   |                |
+   I   E   U   |
+   F   C   R   -------------- Transport ------------------
+   I   T   I
+   C   O   T                    |         --+
+   A   R   Y           +--------+--------+  |
+   T   Y               |    IPP Server   |  |
+   I                   +--------+--------+  |
+   O                            |           |
+   N                   +-----------------+  | IPP Printer
+                       |  Print Service  |  |
+                       +-----------------+  |
+                                |         --+
+                       +-----------------+
+                       | Output Device(s)|
+                       +-----------------+
+
+   An IPP Printer object encapsulates the functions normally associated
+   with physical output devices along with the spooling, scheduling and
+   multiple device management functions often associated with a print
+   server. Printer objects are optionally registered as entries in a
+   directory where end users find and select them based on some sort of
+   filtered and context based searching mechanism (see section 16).  The
+   directory is used to store relatively static information about the
+   Printer, allowing end users to search for and find Printers that
+   match their search criteria, for example: name, context, printer
+   capabilities, etc.  The more dynamic information, such as state,
+   currently loaded and ready media, number of jobs at the Printer,
+
+
+
+Hastings, et al.            Standards Track                    [Page 11]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   errors, warnings, and so forth, is directly associated with the
+   Printer object itself rather than with the entry in the directory
+   which only represents the Printer object.
+
+   IPP clients implement the IPP protocol on the client side and give
+   end users (or programs running on behalf of end users) the ability to
+   query Printer objects and submit and manage print jobs.  An IPP
+   server is just that part of the Printer object that implements the
+   server-side protocol.  The rest of the Printer object implements (or
+   gateways into) the application semantics of the print service itself.
+   The Printer objects may be embedded in an output device or may be
+   implemented on a host on the network that communicates with an output
+   device.
+
+   When a job is submitted to the Printer object and the Printer object
+   validates the attributes in the submission request, the Printer
+   object creates a new Job object.  The end user then interacts with
+   this new Job object to query its status and monitor the progress of
+   the job.  An end user can also cancel their print jobs by using the
+   Job object's Cancel-Job operation.  An end-user can also hold,
+   release, and restart their print jobs using the Job object's OPTIONAL
+   Hold-Job, Release-Job, and Restart-Job operations, if implemented.
+
+   A privileged operator or administrator of a Printer object can
+   cancel, hold, release, and restart any user's job using the REQUIRED
+   Cancel-Job and the OPTIONAL Hold-Job, Release-Job, and Restart-Job
+   operations.  In additional privileged operator or administrator of a
+   Printer object can pause, resume, or purge (jobs from) a Printer
+   object using the OPTIONAL Pause-Printer, Resume-Printer, and Purge-
+   Jobs operations, if implemented.
+
+   The notification service is out of scope for this IPP/1.1 document,
+   but using such a notification service, the end user is able to
+   register for and receive Printer specific and Job specific events.
+   An end user can query the status of Printer objects and can follow
+   the progress of Job objects by polling using the Get-Printer-
+   Attributes, Get-Jobs, and Get-Job-Attributes operations.
+
+2. IPP Objects
+
+   The IPP/1.1 model introduces objects of type Printer and Job.  Each
+   type of object models relevant aspects of a real-world entity such as
+   a real printer or real print job.  Each object type is defined as a
+   set of possible attributes that may be supported by instances of that
+   object type.  For each object (instance), the actual set of supported
+   attributes and values describe a specific implementation.  The
+   object's attributes and values describe its state, capabilities,
+   realizable features, job processing functions, and default behaviors
+
+
+
+Hastings, et al.            Standards Track                    [Page 12]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   and characteristics.  For example, the Printer object type is defined
+   as a set of attributes that each Printer object potentially supports.
+   In the same manner, the Job object type is defined as a set of
+   attributes that are potentially supported by each Job object.
+
+   Each attribute included in the set of attributes defining an object
+   type is labeled as:
+
+   - "REQUIRED": each object MUST support the attribute.
+   - "RECOMMENDED": each object SHOULD support the attribute.
+   - "OPTIONAL": each object MAY support the attribute.
+
+   Some definitions of attribute values indicate that an object MUST or
+   SHOULD support the value; otherwise, support of the value is
+   OPTIONAL.
+
+   However, if an implementation supports an attribute, it MUST support
+   at least one of the possible values for that attribute.
+
+2.1 Printer Object
+
+   The major component of the IPP/1.1 model is the Printer object.  A
+   Printer object implements the server-side of the IPP/1.1 protocol.
+   Using the protocol, end users may query the attributes of the Printer
+   object and submit print jobs to the Printer object.  The actual
+   implementation components behind the Printer abstraction may take on
+   different forms and different configurations.  However, the model
+   abstraction allows the details of the configuration of real
+   components to remain opaque to the end user.  Section 3 describes
+   each of the Printer operations in detail.
+
+   The capabilities and state of a Printer object are described by its
+   attributes.  Printer attributes are divided into two groups:
+
+   - "job-template" attributes: These attributes describe supported job
+     processing capabilities and defaults for the Printer object. (See
+     section 4.2)
+   - "printer-description" attributes: These attributes describe the
+     Printer object's identification, state, location, references to
+     other sources of information about the Printer object, etc. (see
+     section 4.4)
+
+   Since a Printer object is an abstraction of a generic document output
+   device and print service provider, a Printer object could be used to
+   represent any real or virtual device with semantics consistent with
+   the Printer object, such as a fax device, an imager, or even a CD
+   writer.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 13]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Some examples of configurations supporting a Printer object include:
+
+      1) An output device with no spooling capabilities
+      2) An output device with a built-in spooler
+      3) A print server supporting IPP with one or more associated
+         output devices
+         3a) The associated output devices may or may not be capable of
+             spooling jobs
+         3b) The associated output devices may or may not support IPP
+
+   The following figures show some examples of how Printer objects can
+   be realized on top of various distributed printing configurations.
+   The embedded case below represents configurations 1 and 2. The hosted
+   and fan-out figures below represent configurations 3a and 3b.
+
+   In this document the term "client" refers to a software entity that
+   sends IPP operation requests to an IPP Printer object and accepts IPP
+   operation responses.  A client MAY be:
+
+      1. contained within software controlled by an end user, e.g.
+         activated by the "Print" menu item in an application or
+
+      2. the print server component that sends IPP requests to either an
+         output device or another "downstream" print server.
+
+   The term "IPP Printer" is a network entity that accepts IPP operation
+   requests and returns IPP operation responses.  As such, an IPP object
+   MAY be:
+
+      1. an (embedded) device component that accepts IPP requests and
+         controls the device or
+
+      2. a component of a print server that accepts IPP requests (where
+         the print server controls one or more networked devices using
+         IPP or other protocols).
+
+   Legend:
+
+   ##### indicates a Printer object which is
+         either embedded in an output device or is
+         hosted in a server.  The Printer object
+         might or might not be capable of queuing/spooling.
+
+   any   indicates any network protocol or direct
+         connect, including IPP
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 14]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   embedded printer:
+                                             output device
+                                           +---------------+
+    O   +--------+                         |  ###########  |
+   /|\  | client |------------IPP------------># Printer #  |
+   / \  +--------+                         |  # Object  #  |
+                                           |  ###########  |
+                                           +---------------+
+
+   hosted printer:
+                                           +---------------+
+    O   +--------+        ###########      |               |
+   /|\  | client |--IPP--># Printer #-any->| output device |
+   / \  +--------+        # Object  #      |               |
+                          ###########      +---------------+
+
+
+                                            +---------------+
+   fan out:                                 |               |
+                                        +-->| output device |
+                                    any/    |               |
+    O   +--------+      ###########   /     +---------------+
+   /|\  | client |-IPP-># Printer #--*
+   / \  +--------+      # Object  #   \     +---------------+
+                        ########### any\    |               |
+                                        +-->| output device |
+                                            |               |
+                                            +---------------+
+
+2.2 Job Object
+
+   A Job object is used to model a print job.  A Job object contains
+   documents.  The information required to create a Job object is sent
+   in a create request from the end user via an IPP Client to the
+   Printer object.  The Printer object validates the create request, and
+   if the Printer object accepts the request, the Printer object creates
+   the new Job object.  Section 3 describes each of the Job operations
+   in detail.
+
+   The characteristics and state of a Job object are described by its
+   attributes.  Job attributes are grouped into two groups as follows:
+
+      - "job-template" attributes: These attributes can be supplied by
+        the client or end user and include job processing instructions
+        which are intended to override any Printer object defaults
+        and/or instructions embedded within the document data. (See
+        section 4.2)
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 15]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - "job-description" attributes: These attributes describe the Job
+        object's identification, state, size, etc. The client supplies
+        some of these attributes, and the Printer object generates
+        others. (See section 4.3)
+
+   An implementation MUST support at least one document per Job object.
+   An implementation MAY support multiple documents per Job object.  A
+   document is either:
+
+      - a stream of document data in a format supported by the Printer
+        object (typically a Page Description Language - PDL), or
+      - a reference to such a stream of document data
+
+   In IPP/1.1, a document is not modeled as an IPP object, therefore it
+   has no object identifier or associated attributes.  All job
+   processing instructions are modeled as Job object attributes.  These
+   attributes are called Job Template attributes and they apply equally
+   to all documents within a Job object.
+
+2.3 Object Relationships
+
+   IPP objects have relationships that are maintained persistently along
+   with the persistent storage of the object attributes.
+
+   A Printer object can represent either one or more physical output
+   devices or a logical device which "processes" jobs but never actually
+   uses a physical output device to put marks on paper.  Examples of
+   logical devices include a Web page publisher or a gateway into an
+   online document archive or repository.  A Printer object contains
+   zero or more Job objects.
+
+   A Job object is contained by exactly one Printer object, however the
+   identical document data associated with a Job object could be sent to
+   either the same or a different Printer object.  In this case, a
+   second Job object would be created which would be almost identical to
+   the first Job object, however it would have new (different) Job
+   object identifiers (see section 2.4).
+
+   A Job object is either empty (before any documents have been added)
+   or contains one or more documents.  If the contained document is a
+   stream of document data, that stream can be contained in only one
+   document.  However, there can be identical copies of the stream in
+   other documents in the same or different Job objects.  If the
+   contained document is just a reference to a stream of document data,
+   other documents (in the same or different Job object(s)) may contain
+   the same reference.
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 16]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+2.4 Object Identity
+
+   All Printer and Job objects are identified by a Uniform Resource
+   Identifier (URI) [RFC2396] so that they can be persistently and
+   unambiguously referenced.  Since every URL is a specialized form of a
+   URI, even though the more generic term URI is used throughout the
+   rest of this document, its usage is intended to cover the more
+   specific notion of URL as well.
+
+   An administrator configures Printer objects to either support or not
+   support authentication and/or message privacy using Transport Layer
+   Security (TLS) [RFC2246] (the mechanism for security configuration is
+   outside the scope of this IPP/1.1 document).  In some situations,
+   both types of connections (both authenticated and unauthenticated)
+   can be established using a single communication channel that has some
+   sort of negotiation mechanism.  In other situations, multiple
+   communication channels are used, one for each type of security
+   configuration.  Section 8 provides a full description of all security
+   considerations and configurations.
+
+   If a Printer object supports more than one communication channel,
+   some or all of those channels might support and/or require different
+   security mechanisms.  In such cases, an administrator could expose
+   the simultaneous support for these multiple communication channels as
+   multiple URIs for a single Printer object where each URI represents
+   one of the communication channels to the Printer object. To support
+   this flexibility, the IPP Printer object type defines a multi-valued
+   identification attribute called the "printer-uri-supported"
+   attribute.  It MUST contain at least one URI.  It MAY contain more
+   than one URI.  That is, every Printer object will have at least one
+   URI that identifies at least one communication channel to the Printer
+   object, but it may have more than one URI where each URI identifies a
+   different communication channel to the Printer object.  The
+   "printer-uri-supported" attribute has two companion attributes, the
+   "uri-security-supported" attribute and the "uri-authentication-
+   supported". Both have the same cardinality as "printer-uri-
+   supported".  The purpose of the "uri-security-supported" attribute is
+   to indicate the security mechanisms (if any) used for each URI listed
+   in "printer-uri-supported". The purpose of the "uri-authentication-
+   supported" attribute is to indicate the authentication mechanisms (if
+   any) used for each URI listed in "printer-uri-supported".  These
+   three attributes are fully described in sections 4.4.1, 4.4.2, and
+   4.4.3.
+
+   When a job is submitted to the Printer object via a create request,
+   the client supplies only a single Printer object URI.  The client
+   supplied Printer object URI MUST be one of the values in the
+   "printer-uri-supported" Printer attribute.
+
+
+
+Hastings, et al.            Standards Track                    [Page 17]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   IPP/1.1 does not specify how the client obtains the client supplied
+   URI, but it is RECOMMENDED that a Printer object be registered as an
+   entry in a directory service.  End-users and programs can then
+   interrogate the directory searching for Printers. Section 16 defines
+   a generic schema for Printer object entries in the directory service
+   and describes how the entry acts as a bridge to the actual IPP
+   Printer object.  The entry in the directory that represents the IPP
+   Printer object includes the possibly many URIs for that Printer
+   object as values in one its attributes.
+
+   When a client submits a create request to the Printer object, the
+   Printer object validates the request and creates a new Job object.
+   The Printer object assigns the new Job object a URI which is stored
+   in the "job-uri" Job attribute.  This URI is then used by clients as
+   the target for subsequent Job operations.  The Printer object
+   generates a Job URI based on its configured security policy and the
+   URI used by the client in the create request.
+
+   For example, consider a Printer object that supports both a
+   communication channel secured by the use of SSL3 (using HTTP over
+   SSL3 with an "https" schemed URI) and another open communication
+   channel that is not secured with SSL3 (using a simple "http" schemed
+   URI).  If a client were to submit a job using the secure URI, the
+   Printer object would assign the new Job object a secure URI as well.
+   If a client were to submit a job using the open-channel URI, the
+   Printer would assign the new Job object an open-channel URI.
+
+   In addition, the Printer object also populates the Job object's
+   "job-printer-uri" attribute.  This is a reference back to the Printer
+   object that created the Job object.  If a client only has access to a
+   Job object's "job-uri" identifier, the client can query the Job's
+   "job-printer-uri" attribute in order to determine which Printer
+   object created the Job object.  If the Printer object supports more
+   than one URI, the Printer object picks the one URI supplied by the
+   client when creating the job to build the value for and to populate
+   the Job's "job-printer-uri" attribute.
+
+   Allowing Job objects to have URIs allows for flexibility and
+   scalability.  For example, in some implementations, the Printer
+   object might create Jobs that are processed in the same local
+   environment as the Printer object itself.  In this case, the Job URI
+   might just be a composition of the Printer's URI and some unique
+   component for the Job object, such as the unique 32-bit positive
+   integer mentioned later in this paragraph.  In other implementations,
+   the Printer object might be a central clearing-house for validating
+   all Job object creation requests, but the Job object itself might be
+   created in some environment that is remote from the Printer object.
+   In this case, the Job object's URI may have no physical-location
+
+
+
+Hastings, et al.            Standards Track                    [Page 18]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   relationship at all to the Printer object's URI.  Again, the fact
+   that Job objects have URIs allows for flexibility and scalability,
+   however, many existing printing systems have local models or
+   interface constraints that force print jobs to be identified using
+   only a 32-bit positive integer rather than an independent URI.  This
+   numeric Job ID is only unique within the context of the Printer
+   object to which the create request was originally submitted.
+   Therefore, in order to allow both types of client access to IPP Job
+   objects (either by Job URI or by numeric Job ID), when the Printer
+   object successfully processes a create request and creates a new Job
+   object, the Printer object MUST generate both a Job URI and a Job ID.
+   The Job ID (stored in the "job-id" attribute) only has meaning in the
+   context of the Printer object to which the create request was
+   originally submitted. This requirement to support both Job URIs and
+   Job IDs allows all types of clients to access Printer objects and Job
+   objects no matter the local constraints imposed on the client
+   implementation.
+
+   In addition to identifiers, Printer objects and Job objects have
+   names ("printer-name" and "job-name").  An object name NEED NOT be
+   unique across all instances of all objects. A Printer object's name
+   is chosen and set by an administrator through some mechanism outside
+   the scope of this IPP/1.1 document.  A Job object's name is
+   optionally chosen and supplied by the IPP client submitting the job.
+   If the client does not supply a Job object name, the Printer object
+   generates a name for the new Job object.  In all cases, the name only
+   has local meaning.
+
+   To summarize:
+
+      - Each Printer object is identified with one or more URIs.  The
+        Printer's "printer-uri-supported" attribute contains the URI(s).
+      - The Printer object's "uri-security-supported" attribute
+        identifies the communication channel security protocols that may
+        or may not have been configured for the various Printer object
+        URIs (e.g., 'tls' or 'none').
+      - The Printer object's "uri-authentication-supported" attribute
+        identifies the authentication mechanisms that may or may not
+        have been configured for the various Printer object URIs (e.g.,
+        'digest' or 'none').
+      - Each Job object is identified with a Job URI.  The Job's "job-
+        uri" attribute contains the URI.
+      - Each Job object is also identified with Job ID which is a 32-
+        bit, positive integer.  The Job's "job-id" attribute contains
+        the Job ID.  The Job ID is only unique within the context of the
+        Printer object  which created the Job object.
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 19]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - Each Job object has a "job-printer-uri" attribute which contains
+        the URI of the Printer object that was used to create the Job
+        object.  This attribute is used to determine the Printer object
+        that created a Job object when given only the URI for the Job
+        object.  This linkage is necessary to determine the languages,
+        charsets, and operations which are supported on that Job (the
+        basis for such support comes from the creating Printer object).
+      - Each Printer object has a name (which is not necessarily
+        unique).  The administrator chooses and sets this name through
+        some mechanism outside the scope of this IPP/1.1 document.  The
+        Printer object's "printer-name" attribute contains the name.
+      - Each Job object has a name (which is not necessarily unique).
+        The client optionally supplies this name in the create request.
+        If the client does not supply this name, the Printer object
+        generates a name for the Job object. The Job object's "job-name"
+        attribute contains the name.
+
+3. IPP Operations
+
+   IPP objects support operations.  An operation consists of a request
+   and a response.  When a client communicates with an IPP object, the
+   client issues an operation request to the URI for that object.
+   Operation requests and responses have parameters that identify the
+   operation.  Operations also have attributes that affect the run-time
+   characteristics of the operation (the intended target, localization
+   information, etc.).  These operation-specific attributes are called
+   operation attributes (as compared to object attributes such as
+   Printer object attributes or Job object attributes).  Each request
+   carries along with it any operation attributes, object attributes,
+   and/or document data required to perform the operation.  Each request
+   requires a response from the object.  Each response indicates success
+   or failure of the operation with a status code as a response
+   parameter.  The response contains any operation attributes, object
+   attributes, and/or status messages generated during the execution of
+   the operation request.
+
+   This section describes the semantics of the IPP operations, both
+   requests and responses, in terms of the parameters, attributes, and
+   other data associated with each operation.
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 20]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The IPP/1.1 Printer operations are:
+
+     Print-Job (section 3.2.1)
+     Print-URI (section 3.2.2)
+     Validate-Job (section 3.2.3)
+     Create-Job (section 3.2.4)
+     Get-Printer-Attributes (section 3.2.5)
+     Get-Jobs (section 3.2.6)
+     Pause-Printer (section 3.3.5)
+     Resume-Printer (section 3.3.6)
+     Purge-Jobs (section 3.3.7)
+
+   The Job operations are:
+
+     Send-Document (section 3.3.1)
+     Send-URI (section 3.3.2)
+     Cancel-Job (section 3.3.3)
+     Get-Job-Attributes (section 3.3.4)
+     Hold-Job (section 3.3.5)
+     Release-Job (section 3.3.6)
+     Restart-Job (section 3.3.7)
+
+   The Send-Document and Send-URI Job operations are used to add a new
+   document to an existing multi-document Job object created using the
+   Create-Job operation.
+
+3.1 Common Semantics
+
+   All IPP operations require some common parameters and operation
+   attributes.  These common elements and their semantic characteristics
+   are defined and described in more detail in the following sections.
+
+3.1.1 Required Parameters
+
+   Every operation request contains the following REQUIRED parameters:
+
+      - a "version-number",
+      - an "operation-id",
+      - a "request-id", and
+      - the attributes that are REQUIRED for that type of request.
+
+   Every operation response contains the following REQUIRED parameters:
+
+      - a "version-number",
+      - a "status-code",
+      - the "request-id" that was supplied in the corresponding request,
+        and
+      - the attributes that are REQUIRED for that type of response.
+
+
+
+Hastings, et al.            Standards Track                    [Page 21]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The "Encoding and Transport" document [RFC2910] defines special rules
+   for the encoding of these parameters.  All other operation elements
+   are represented using the more generic encoding rules for attributes
+   and groups of attributes.
+
+3.1.2 Operation IDs and Request IDs
+
+   Each IPP operation request includes an identifying "operation-id"
+   value.  Valid values are defined in the "operations-supported"
+   Printer attribute section (see section 4.4.15).  The client specifies
+   which operation is being requested by supplying the correct
+   "operation-id" value.
+
+   In addition, every invocation of an operation is identified by a
+   "request-id" value. For each request, the client chooses the
+   "request-id" which MUST be an integer (possibly unique depending on
+   client requirements) in the range from 1 to 2**31 - 1 (inclusive).
+   This "request-id" allows clients to manage multiple outstanding
+   requests. The receiving IPP object copies all 32-bits of the client-
+   supplied "request-id" attribute into the response so that the client
+   can match the response with the correct outstanding request, even if
+   the "request-id" is out of range.  If the request is terminated
+   before the complete "request-id" is received, the IPP object rejects
+   the request and returns a response with a "request-id" of 0.
+
+   Note: In some cases, the transport protocol underneath IPP might be a
+   connection oriented protocol that would make it impossible for a
+   client to receive responses in any order other than the order in
+   which the corresponding requests were sent.  In such cases, the
+   "request-id" attribute would not be essential for correct protocol
+   operation.  However, in other mappings, the operation responses can
+   come back in any order.  In these cases, the "request-id" would be
+   essential.
+
+3.1.3 Attributes
+
+   Operation requests and responses are both composed of groups of
+   attributes and/or document data.  The attributes groups are:
+
+      - Operation Attributes: These attributes are passed in the
+        operation and affect the IPP object's behavior while processing
+        the operation request and may affect other attributes or groups
+        of attributes.  Some operation attributes describe the document
+        data associated with the print job and are associated with new
+        Job objects, however most operation attributes do not persist
+        beyond the life of the operation.  The description of each
+        operation attribute includes conformance statements indicating
+        which operation attributes are REQUIRED and which are OPTIONAL
+
+
+
+Hastings, et al.            Standards Track                    [Page 22]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+        for an IPP object to support and which attributes a client MUST
+        supply in a request and an IPP object MUST supply in a response.
+      - Job Template Attributes: These attributes affect the processing
+        of a job.  A client OPTIONALLY supplies Job Template Attributes
+        in a create request, and the receiving object MUST be prepared
+        to receive all supported attributes.  The Job object can later
+        be queried to find out what Job Template attributes were
+        originally requested in the create request, and such attributes
+        are returned in the response as Job Object Attributes.  The
+        Printer object can be queried about its Job Template attributes
+        to find out what type of job processing capabilities are
+        supported and/or what the default job processing behaviors are,
+        though such attributes are returned in the response as Printer
+        Object Attributes.  The "ipp-attribute-fidelity" operation
+        attribute affects processing of all client-supplied Job Template
+        attributes (see sections 3.2.1.2 and 15 for a full description
+        of "ipp-attribute-fidelity" and its relationship to other
+        attributes).
+      - Job Object Attributes: These attributes are returned in response
+        to a query operation directed at a Job object.
+      - Printer Object Attributes: These attributes are returned in
+        response to a query operation directed at a Printer object.
+      - Unsupported Attributes: In a create request, the client supplies
+        a set of Operation and Job Template attributes.  If any of these
+        attributes or their values is unsupported by the Printer object,
+        the Printer object returns the set of unsupported attributes in
+        the response.  Sections 3.1.7, 3.2.1.2, and  15 give a full
+        description of how Job Template attributes supplied by the
+        client in a create request are processed by the Printer object
+        and how unsupported attributes are returned to the client.
+        Because of extensibility, any IPP object might receive a request
+        that contains new or unknown attributes or values for which it
+        has no support. In such cases, the IPP object processes what it
+        can and returns the unsupported attributes in the response. The
+        Unsupported Attribute group is defined for all operation
+        responses for returning unsupported attributes that the client
+        supplied in the request.
+
+   Later in this section, each operation is formally defined by
+   identifying the allowed and expected groups of attributes for each
+   request and response.  The model identifies a specific order for each
+   group in each request or response, but the attributes within each
+   group may be in any order, unless specified otherwise.
+
+   The attributes within a group MUST be unique; if an attribute with
+   the same name occurs more than once, the group is mal-formed.
+   Clients MUST NOT submit such malformed requests and Printers MUST NOT
+   return such malformed responses.  If such a malformed request is
+
+
+
+Hastings, et al.            Standards Track                    [Page 23]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   submitted to a Printer, the Printer MUST either (1) reject the
+   request with the 'client-error-bad-request' status code (see section
+   13.1.4.1) or (2) process the request normally after selecting only
+   one of the attribute instances, depending on implementation.  Which
+   attribute is selected when there are duplicate attributes depends on
+   implementation.  The IPP Printer MUST NOT use the values from more
+   than one such duplicate attribute instance.
+
+   Each attribute definition includes the attribute's name followed by
+   the name of its attribute syntax(es) in parenthesizes.  In addition,
+   each 'integer' attribute is followed by the allowed range in
+   parentheses, (m:n), for values of that attribute.  Each 'text' or
+   'name' attribute is followed by the maximum size in octets in
+   parentheses, (size), for values of that attribute. For more details
+   on attribute syntax notation, see the descriptions of these
+   attributes syntaxes in section 4.1.
+
+   Note: Document data included in the operation is not strictly an
+   attribute, but it is treated as a special attribute group for
+   ordering purposes.  The only operations that support supplying the
+   document data within an operation request are Print-Job and Send-
+   Document.  There are no operation responses that include document
+   data.
+
+   Some operations are REQUIRED for IPP objects to support; the others
+   are OPTIONAL (see section 5.2.2).  Therefore, before using an
+   OPTIONAL operation, a client SHOULD first use the REQUIRED Get-
+   Printer-Attributes operation to query the Printer's "operations-
+   supported" attribute in order to determine which OPTIONAL Printer and
+   Job operations are actually supported.  The client SHOULD NOT use an
+   OPTIONAL operation that is not supported.  When an IPP object
+   receives a request to perform an operation it does not support, it
+   returns the 'server-error-operation-not-supported' status code (see
+   section 13.1.5.2).  An IPP object is non-conformant if it does not
+   support a REQUIRED operation.
+
+3.1.4 Character Set and Natural Language Operation Attributes
+
+   Some Job and Printer attributes have values that are text strings and
+   names intended for human understanding rather than machine
+   understanding (see the 'text' and 'name' attribute syntax
+   descriptions in section 4.1).  The following sections describe two
+   special Operation Attributes called "attributes-charset" and
+   "attributes-natural-language".  These attributes are always part of
+   the Operation Attributes group.  For most attribute groups, the order
+   of the attributes within the group is not important.  However, for
+   these two attributes within the Operation Attributes group, the order
+   is critical.  The "attributes-charset" attribute MUST be the first
+
+
+
+Hastings, et al.            Standards Track                    [Page 24]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   attribute in the group and the "attributes-natural-language"
+   attribute MUST be the second attribute in the group.  In other words,
+   these attributes MUST be supplied in every IPP request and response,
+   they MUST come first in the group, and MUST come in the specified
+   order.  For job creation operations, the IPP Printer implementation
+   saves these two attributes with the new Job object as Job Description
+   attributes.  For the sake of brevity in this document, these
+   operation attribute descriptions are not repeated with every
+   operation request and response, but have a reference back to this
+   section instead.
+
+3.1.4.1 Request Operation Attributes
+
+   The client MUST supply and the Printer object MUST support the
+   following REQUIRED operation attributes in every IPP/1.1 operation
+   request:
+
+      "attributes-charset" (charset):
+         This operation attribute identifies the charset (coded
+         character set and encoding method) used by any 'text' and
+         'name' attributes that the client is supplying in this request.
+         It also identifies the charset that the Printer object MUST use
+         (if supported) for all 'text' and 'name' attributes and status
+         messages that the Printer object returns in the response to
+         this request. See Sections 4.1.1 and 4.1.2 for the definition
+         of the 'text' and 'name' attribute syntaxes.
+
+         All clients and IPP objects MUST support the 'utf-8' charset
+         [RFC2279] and MAY support additional charsets provided that
+         they are registered with IANA [IANA-CS].  If the Printer object
+         does not support the client supplied charset value, the Printer
+         object MUST reject the request, set the "attributes-charset" to
+         'utf-8' in the response, and return the 'client-error-charset-
+         not-supported' status code and any 'text' or 'name' attributes
+         using the 'utf-8' charset. The Printer NEED NOT return any
+         attributes in the Unsupported Attributes Group (See sections
+         3.1.7 and 3.2.1.2).  The Printer object MUST indicate the
+         charset(s) supported as the values of the "charset-supported"
+         Printer attribute (see Section 4.4.18), so that the client can
+         query to determine which charset(s) are supported.
+
+         Note to client implementers: Since IPP objects are only
+         required to support the 'utf-8' charset, in order to maximize
+         interoperability with multiple IPP object implementations, a
+         client may want to supply 'utf-8' in the "attributes-charset"
+         operation attribute, even though the client is only passing and
+         able to present a simpler charset, such as US-ASCII [ASCII] or
+         ISO-8859-1 [ISO8859-1].  Then the client will have to filter
+
+
+
+Hastings, et al.            Standards Track                    [Page 25]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         out (or charset convert) those characters that are returned in
+         the response that it cannot present to its user.  On the other
+         hand, if both the client and the IPP objects also support a
+         charset in common besides utf-8, the client may want to use
+         that charset in order to avoid charset conversion or data loss.
+
+         See the 'charset' attribute syntax description in Section 4.1.7
+         for the syntax and semantic interpretation of the values of
+         this attribute and for example values.
+
+      "attributes-natural-language" (naturalLanguage):
+         This operation attribute identifies the natural language used
+         by any 'text' and 'name' attributes that the client is
+         supplying in this request.  This attribute also identifies the
+         natural language that the Printer object SHOULD use for all
+         'text' and 'name' attributes and status messages that the
+         Printer object returns in the response to this request.  See
+         the 'naturalLanguage' attribute syntax description in section
+         4.1.8 for the syntax and semantic interpretation of the values
+         of this attribute and for example values.
+
+         There are no REQUIRED natural languages required for the
+         Printer object to support.  However, the Printer object's
+         "generated-natural-language-supported" attribute identifies the
+         natural languages supported by the Printer object and any
+         contained Job objects for all text strings generated by the IPP
+         object.  A client MAY query this attribute to determine which
+         natural language(s) are supported for generated messages.
+
+         For any of the attributes for which the Printer object
+         generates text, i.e., for the "job-state-message", "printer-
+         state-message", and status messages (see Section 3.1.6), the
+         Printer object MUST be able to generate these text strings in
+         any of its supported natural languages.  If the client requests
+         a natural language that is not supported, the Printer object
+         MUST return these generated messages in the Printer's
+         configured natural language as specified by the Printer's
+         "natural-language-configured" attribute" (see Section 4.4.19).
+
+         For other 'text' and 'name' attributes supplied by the client,
+         authentication system, operator, system administrator, or
+         manufacturer (i.e., for "job-originating-user-name", "printer-
+         name" (name), "printer-location" (text), "printer-info" (text),
+         and "printer-make-and-model" (text)), the Printer object is
+         only required to support the configured natural language of the
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 26]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         Printer identified by the Printer object's "natural-language-
+         configured" attribute, though support of additional natural
+         languages for these attributes is permitted.
+
+         For any 'text' or 'name' attribute in the request that is in a
+         different natural language than the value supplied in the
+         "attributes-natural-language" operation attribute, the client
+         MUST use the Natural Language Override mechanism (see sections
+         4.1.1.2 and 4.1.2.2) for each such attribute value supplied.
+         The client MAY use the Natural Language Override mechanism
+         redundantly, i.e., use it even when the value is in the same
+         natural language as the value supplied in the "attributes-
+         natural-language" operation attribute of the request.
+
+         The IPP object MUST accept any natural language and any Natural
+         Language Override, whether the IPP object supports that natural
+         language or not (and independent of the value of the "ipp-
+         attribute-fidelity" Operation attribute).  That is the IPP
+         object accepts all client supplied values no matter what the
+         values are in the Printer object's "generated-natural-
+         language-supported" attribute.  That attribute, "generated-
+         natural-language-supported", only applies to generated
+         messages, not client supplied messages.  The IPP object MUST
+         remember that natural language for all client-supplied
+         attributes, and when returning those attributes in response to
+         a query, the IPP object MUST indicate that natural language.
+
+         Each value whose attribute syntax type is 'text' or 'name' (see
+         sections 4.1.1 and 4.1.2) has an Associated Natural-Language.
+         This document does not specify how this association is stored
+         in a Printer or Job object.  When such a value is encoded in a
+         request or response, the natural language is either implicit or
+         explicit:
+
+         - In the implicit case, the value contains only the text/name
+           value, and the language is specified by the "attributes-
+           natural-language" operation attribute in the request or
+           response (see sections 4.1.1.1 textWithoutLanguage and
+           4.1.2.1 nameWithoutLanguage).
+
+         - In the explicit case (also known as the Natural-Language
+           Override case), the value contains both the language and the
+           text/name value (see sections 4.1.1.2 textWithLanguage and
+           4.1.2.2 nameWithLanguage).
+
+         For example, the "job-name" attribute MAY be supplied by the
+         client in a create request.  The text value for this attribute
+         will be in the natural language identified by the "attribute-
+
+
+
+Hastings, et al.            Standards Track                    [Page 27]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         natural-language" attribute, or if different, as identified by
+         the Natural Language Override mechanism.  If supplied, the IPP
+         object will use the value of the "job-name" attribute to
+         populate the Job object's "job-name" attribute.  Whenever any
+         client queries the Job object's "job-name" attribute, the IPP
+         object returns the attribute as stored and uses the Natural
+         Language Override mechanism to specify the natural language, if
+         it is different from that reported in the "attributes-natural-
+         language" operation attribute of the response.  The IPP object
+         MAY use the Natural Language Override mechanism redundantly,
+         i.e., use it even when the value is in the same natural
+         language as the value supplied in the "attributes-natural-
+         language" operation attribute of the response.
+
+         An IPP object MUST NOT reject a request based on a supplied
+         natural language in an "attributes-natural-language" Operation
+         attribute or in any attribute that uses the Natural Language
+         Override.
+
+   Clients SHOULD NOT supply 'text' or 'name' attributes that use an
+   illegal combination of natural language and charset.  For example,
+   suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and
+   'iso-8859-7'.  Suppose also, that it supports natural languages 'en'
+   (English), 'fr' (French), and 'el' (Greek).  Although the Printer
+   object supports the charset 'iso-8859-1' and natural language 'el',
+   it probably does not support the combination of Greek text strings
+   using the 'iso-8859-1' charset.  The Printer object handles this
+   apparent incompatibility differently depending on the context in
+   which it occurs:
+
+      - In a create request: If the client supplies a text or name
+        attribute (for example, the "job-name" operation attribute) that
+        uses an apparently incompatible combination, it is a client
+        choice that does not affect the Printer object or its correct
+        operation.  Therefore, the Printer object simply accepts the
+        client supplied value, stores it with the Job object, and
+        responds back with the same combination whenever the client (or
+        any client) queries for that attribute.
+      - In a query-type operation, like Get-Printer-Attributes: If the
+        client requests an apparently incompatible combination, the
+        Printer object responds (as described in section 3.1.4.2) using
+        the Printer's configured natural language rather than the
+        natural language requested by the client.
+
+   In either case, the Printer object does not reject the request
+   because of the apparent incompatibility.  The potential incompatible
+   combination of charset and natural language can occur either at the
+   global operation level or at the Natural Language Override
+
+
+
+Hastings, et al.            Standards Track                    [Page 28]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   attribute-by-attribute level.  In addition, since the response always
+   includes explicit charset and natural language information, there is
+   never any question or ambiguity in how the client interprets the
+   response.
+
+3.1.4.2 Response Operation Attributes
+
+   The Printer object MUST supply and the client MUST support the
+   following REQUIRED operation attributes in every IPP/1.1 operation
+   response:
+
+      "attributes-charset" (charset):
+         This operation attribute identifies the charset used by any
+         'text' and 'name' attributes that the Printer object is
+         returning in this response.  The value in this response MUST be
+         the same value as the "attributes-charset" operation attribute
+         supplied by the client in the request.  If this is not possible
+         (i.e., the charset requested is not supported), the request
+         would have been rejected.  See "attributes-charset" described
+         in Section 3.1.4.1 above.
+
+         If the Printer object supports more than just the 'utf-8'
+         charset, the Printer object MUST be able to code convert
+         between each of the charsets supported on a highest fidelity
+         possible basis in order to return the 'text' and 'name'
+         attributes in the charset requested by the client.  However,
+         some information loss MAY occur during the charset conversion
+         depending on the charsets involved.  For example, the Printer
+         object may convert from a UTF-8 'a' to a US-ASCII 'a' (with no
+         loss of information), from an ISO Latin 1 CAPITAL LETTER A WITH
+         ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a
+         UTF-8 Japanese Kanji character to some ISO Latin 1 error
+         character indication such as '?', decimal code equivalent, or
+         to the absence of a character, depending on implementation.
+
+         Whether an implementation that supports more than one charset
+         stores the data in the charset supplied by the client or code
+         converts to one of the other supported charsets, depends on
+         implementation.  The strategy should try to minimize loss of
+         information during code conversion.  On each response, such an
+         implementation converts from its internal charset to that
+         requested.
+
+      "attributes-natural-language" (naturalLanguage):
+         This operation attribute identifies the natural language used
+         by any 'text' and 'name' attributes that the IPP object is
+         returning in this response.  Unlike the "attributes-charset"
+         operation attribute, the IPP object NEED NOT return the same
+
+
+
+Hastings, et al.            Standards Track                    [Page 29]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         value as that supplied by the client in the request.  The IPP
+         object MAY return the natural language of the Job object or the
+         Printer's configured natural language as identified by the
+         Printer object's "natural-language-configured" attribute,
+         rather than the natural language supplied by the client.  For
+         any 'text' or 'name' attribute or status message in the
+         response that is in a different natural language than the value
+         returned in the "attributes-natural-language" operation
+         attribute, the IPP object MUST use the Natural Language
+         Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on each
+         attribute value returned.  The IPP object MAY use the Natural
+         Language Override mechanism redundantly, i.e., use it even when
+         the value is in the same natural language as the value supplied
+         in the "attributes-natural-language" operation attribute of the
+         response.
+
+3.1.5 Operation Targets
+
+   All IPP operations are directed at IPP objects.  For Printer
+   operations, the operation is always directed at a Printer object
+   using one of its URIs (i.e., one of the values in the Printer
+   object's "printer-uri-supported" attribute).  Even if the Printer
+   object supports more than one URI, the client supplies only one URI
+   as the target of the operation.  The client identifies the target
+   object by supplying the correct URI in the "printer-uri (uri)"
+   operation attribute.
+
+   For Job operations, the operation is directed at either:
+
+      - The Job object itself using the Job object's URI.  In this case,
+        the client identifies the target object by supplying the correct
+        URI in the "job-uri (uri)" operation attribute.
+      - The Printer object that created the Job object using both the
+        Printer objects URI and the Job object's Job ID.  Since the
+        Printer object that created the Job object generated the Job ID,
+        it MUST be able to correctly associate the client supplied Job
+        ID with the correct Job object.  The client supplies the Printer
+        object's URI in the "printer-uri (uri)" operation attribute and
+        the Job object's Job ID in the "job-id (integer(1:MAX))"
+        operation attribute.
+
+   If the operation is directed at the Job object directly using the Job
+   object's URI, the client MUST NOT include the redundant "job-id"
+   operation attribute.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 30]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The operation target attributes are REQUIRED operation attributes
+   that MUST be included in every operation request.  Like the charset
+   and natural language attributes (see section 3.1.4), the operation
+   target attributes are specially ordered operation attributes.  In all
+   cases, the operation target attributes immediately follow the
+   "attributes-charset" and "attributes-natural-language" attributes
+   within the operation attribute group, however the specific ordering
+   rules are:
+
+      - In the case where there is only one operation target attribute
+        (i.e., either only the "printer-uri" attribute or only the
+        "job-uri" attribute), that attribute MUST be the third attribute
+        in the operation attributes group.
+      - In the case where Job operations use two operation target
+        attributes (i.e., the "printer-uri" and "job-id" attributes),
+        the "printer-uri" attribute MUST be the third attribute and the
+        "job-id" attribute MUST be the fourth attribute.
+
+   In all cases, the target URIs contained within the body of IPP
+   operation requests and responses must be in absolute format rather
+   than relative format (a relative URL identifies a resource with the
+   scope of the HTTP server, but does not include scheme, host or port).
+
+   The following rules apply to the use of port numbers in URIs that
+   identify IPP objects:
+
+      1. If the URI scheme allows the port number to be explicitly
+         included in the URI string, and a port number is specified
+         within the URI, then that port number MUST be used by the
+         client to contact the IPP object.
+
+      2. If the URI scheme allows the port number to be explicitly
+         included in the URI string, and a port number is not specified
+         within the URI, then default port number implied by that URI
+         scheme MUST be used by the client to contact the IPP object.
+
+      3. If the URI scheme does not allow an explicit port number to be
+         specified within the URI, then the default port number implied
+         by that URI MUST be used by the client to contact the IPP
+         object.
+
+   Note: The IPP "Encoding and Transport document [RFC2910] shows a
+   mapping of IPP onto HTTP/1.1 [RFC2616] and defines a new default port
+   number for using IPP over HTTP/1.1.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 31]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.1.6 Operation Response Status Codes and Status Messages
+
+   Every operation response includes a REQUIRED "status-code" parameter
+   and an OPTIONAL "status-message" operation attribute, and an OPTIONAL
+   "detailed-status-message" operation attribute.  The Print-URI and
+   Send-URI response MAY include an OPTIONAL "document-access-error"
+   operation attribute.
+
+3.1.6.1 "status-code" (type2 enum)
+
+   The REQUIRED "status-code" parameter provides information on the
+   processing of a request.
+
+   The status code is intended for use by automata.  A client
+   implementation of IPP SHOULD convert status code values into any
+   localized message that has semantic meaning to the end user.
+
+   The "status-code" value is a numeric value that has semantic meaning.
+   The "status-code" syntax is similar to a "type2 enum" (see section
+   4.1 on "Attribute Syntaxes") except that values can range only from
+   0x0000 to 0x7FFF.  Section 13 describes the status codes, assigns the
+   numeric values, and suggests a corresponding status message for each
+   status code for use by the client when the user's natural language is
+   English.
+
+   If the Printer performs an operation with no errors and it encounters
+   no problems, it MUST return the status code 'successful-ok' in the
+   response.  See section 13.
+
+   If the client supplies unsupported values for the following
+   parameters or Operation attributes, the Printer object MUST reject
+   the operation, NEED NOT return the unsupported attribute value in the
+   Unsupported Attributes group, and MUST return the indicated status
+   code:
+
+        Parameter/Attribute                 Status code
+
+        version-number      server-error-version-not-supported
+        operation-id        server-error-operation-not-supported
+        attributes-charset  client-error-charset-not-supported
+        compression         client-error-compression-not-supported
+        document-format     client-error-document-format-not-supported
+        document-uri        client-error-uri-scheme-not-supported,
+                             client-error-document-access-error
+
+   If the client supplies unsupported values for other attributes, or
+   unsupported attributes, the Printer returns the status code defined
+   in section 3.1.7 on Unsupported Attributes.
+
+
+
+Hastings, et al.            Standards Track                    [Page 32]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.1.6.2 "status-message" (text(255))
+
+   The OPTIONAL "status-message" operation attribute provides a short
+   textual description of the status of the operation.  The "status-
+   message" attribute's syntax is "text(255)", so the maximum length is
+   255 octets (see section 4.1.1).  The status message is intended for
+   the human end user.  If a response does include a "status-message"
+   attribute, an IPP client NEED NOT examine or display the messages,
+   however it SHOULD do so in some implementation specific manner.  The
+   "status-message" is especially useful for a later version of a
+   Printer object to return as supplemental information for the human
+   user to accompany a status code that an earlier version of a client
+   might not understand.
+
+   If the Printer object supports the "status-message" operation
+   attribute, the Printer object MUST be able to generate this message
+   in any of the natural languages identified by the Printer object's
+   "generated-natural-language-supported" attribute (see the
+   "attributes-natural-language" operation attribute specified in
+   section 3.1.4.1.  Section 13 suggests the text for the status message
+   returned by the Printer for use with the English natural language.
+
+   As described in section 3.1.4.1 for any returned 'text' attribute, if
+   there is a choice for generating this message, the Printer object
+   uses the natural language indicated by the value of the "attributes-
+   natural-language" in the client request if supported, otherwise the
+   Printer object uses the value in the Printer object's own "natural-
+   language-configured" attribute.
+
+   If the Printer object supports the "status-message" operation
+   attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a
+   status message for the following error status codes (see section 13):
+   'client-error-bad-request', 'client-error-charset-not-supported',
+   'server-error-internal-error', 'server-error-operation-not-
+   supported', and 'server-error-version-not-supported'.  In this case,
+   it MUST set the value of the "attributes-charset" operation attribute
+   to 'utf-8' in the error response.
+
+3.1.6.3 "detailed-status-message" (text(MAX))
+
+   The OPTIONAL "detailed-status-message" operation attribute provides
+   additional more detailed technical and implementation-specific
+   information about the operation.  The "detailed-status-message"
+   attribute's syntax is "text(MAX)", so the maximum length is 1023
+   octets (see section 4.1.1).    If the Printer objects supports the
+   "detailed-status-message" operation attribute, the Printer NEED NOT
+   localize the message, since it is intended for use by the system
+   administrator or other experienced technical persons.  Localization
+
+
+
+Hastings, et al.            Standards Track                    [Page 33]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   might obscure the technical meaning of such messages.  Clients MUST
+   NOT attempt to parse the value of this attribute.  See the
+   "document-access-error" operation attribute (section 3.1.6.4) for
+   additional errors that a program can process.
+
+3.1.6.4 "document-access-error" (text(MAX))
+
+   This OPTIONAL operation attribute provides additional information
+   about any document access errors encountered by the Printer before it
+   returned a response to the Print-URI (section 3.2.2) or Send-URI
+   (section 3.3.1) operation.  For errors in the protocol identified by
+   the URI scheme in the "document-uri" operation attribute, such as
+   'http:' or 'ftp:', the error code is returned in parentheses,
+   followed by the URI.  For example:
+
+      (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf
+
+   Most Internet protocols use decimal error codes (unlike IPP), so the
+   ASCII error code representation is in decimal.
+
+3.1.7 Unsupported Attributes
+
+   The Unsupported Attributes group contains attributes that are not
+   supported by the operation. This group is primarily for the job
+   creation operations, but all operations can return this group.
+
+   A Printer object MUST include an Unsupported Attributes group in a
+   response if the status code is one of the following:  'successful-
+   ok-ignored-or-substituted-attributes', 'successful-ok-conflicting-
+   attributes', 'client-error-attributes-or-values-not-supported' or
+   'client-error-conflicting-attributes'.
+
+   If the status code is one of the four specified in the preceding
+   paragraph, the Unsupported Attributes group MUST contain all of those
+   attributes and only those attributes that are:
+
+      a. an Operation or Job Template attribute supplied in the request,
+         and
+
+      b. unsupported by the printer. See below for details on the three
+         categories "unsupported" attributes.
+
+   If the status code is one of those in the table in section 3.1.6.1,
+   the Unsupported Attributes group NEED NOT contain the unsupported
+   parameter or attribute indicated in that table.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 34]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   If the Printer object is not returning any Unsupported Attributes in
+   the response, the Printer object SHOULD omit Group 2 rather than
+   sending an empty group.  However, a client MUST be able to accept an
+   empty group.
+
+   Unsupported attributes fall into three categories:
+
+      1. The Printer object does not support the supplied attribute (no
+         matter what the attribute syntax or value).
+
+      2. The Printer object does support the attribute, but does not
+         support some or all of the particular attribute syntaxes or
+         values supplied by the client (i.e., the Printer object does
+         not have those attribute syntaxes or values in its
+         corresponding "xxx-supported" attribute).
+
+      3. The Printer object does support the attributes and values
+         supplied, but the particular values are in conflict with one
+         another, because they violate a constraint, such as not being
+         able to staple transparencies.
+
+   In the case of an unsupported attribute name, the Printer object
+   returns the client-supplied attribute with a substituted value of
+   'unsupported'.  This value's syntax type is "out-of-band" and its
+   encoding is defined by special rules for "out-of-band" values in the
+   "Encoding and Transport" document [RFC2910].   Its value indicates no
+   support for the attribute itself (see the beginning of section 4.1).
+
+   In the case of a supported attribute with one or more unsupported
+   attribute syntaxes or values, the Printer object simply returns the
+   client-supplied attribute with the unsupported attribute syntaxes or
+   values as supplied by the client.  This indicates support for the
+   attribute, but no support for that particular attribute syntax or
+   value.  If the client supplies a multi-valued attribute with more
+   than one value and the Printer object supports the attribute but only
+   supports a subset of the client-supplied attribute syntaxes or
+   values, the Printer object
+
+   MUST return only those attribute syntaxes or values that are
+   unsupported.
+
+   In the case of two (or more) supported attribute values that are in
+   conflict with one another (although each is supported independently,
+   the values conflict when requested together within the same job), the
+   Printer object MUST return all the values that it ignores or
+   substitutes to resolve the conflict, but not any of the values that
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 35]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   it is still using.  The choice for exactly how to resolve the
+   conflict is implementation dependent.  See sections 3.2.1.2 and 15.
+   See The Implementer's Guide [IPP-IIG] for an example.
+
+3.1.8 Versions
+
+   Each operation request and response carries with it a "version-
+   number" parameter.  Each value of the "version-number" is in the form
+   "X.Y" where X is the major version number and Y is the minor version
+   number.  By including a version number in the client request, it
+   allows the client  to identify which version of IPP it is interested
+   in using, i.e., the version whose conformance requirements the client
+   may be depending upon the Printer to meet.
+
+   If the IPP object does not support that major version number supplied
+   by the client, i.e., the major version field of the "version-number"
+   parameter does not match any of the values of the Printer's "ipp-
+   versions-supported" (see section 4.4.14), the object MUST respond
+   with a status code of 'server-error-version-not-supported' along with
+   the closest version number that is supported (see section 13.1.5.4).
+   If the major version number is supported, but the minor version
+   number is not, the IPP object SHOULD accept and attempt to perform
+   the request (or reject the request if the operation is not
+   supported), else it rejects the request and returns the 'server-
+   error-version-not-supported' status code.  In all cases, the IPP
+   object MUST return the "version-number" that it supports that is
+   closest to the version number supplied by the client in the request.
+
+   There is no version negotiation per se.  However, if after receiving
+   a 'server-error-version-not-supported' status code from an IPP
+   object, a client SHOULD try again with a different version number. A
+   client MAY also determine the versions supported either from a
+   directory that conforms to Appendix E (see section 16) or by querying
+   the Printer object's "ipp-versions-supported" attribute (see section
+   4.4.14) to determine which versions are supported.
+
+   An IPP object implementation MUST support version '1.1', i.e., meet
+   the conformance requirements for IPP/1.1 as specified in this
+   document and [RFC2910].  It is recommended that IPP object
+   implementations accept any request with the major version '1' (or
+   reject the request if the operation is not supported).
+
+   There is only one notion of "version number" that covers both IPP
+   Model and IPP Protocol changes. Thus the version number MUST change
+   when introducing a new version of the Model and Semantics document
+   (this document) or a new version of the "Encoding and Transport"
+   document [RFC2910].
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 36]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Changes to the major version number of the Model and Semantics
+   document indicate structural or syntactic changes that make it
+   impossible for older version of IPP clients and Printer objects to
+   correctly parse and correctly process the new or changed attributes,
+   operations and responses.  If the major version number changes, the
+   minor version numbers is set to zero.  As an example, adding the
+   REQUIRED "ipp-attribute-fidelity" attribute to version '1.1' (if it
+   had not been part of version '1.0'), would have required a change to
+   the major version number, since an IPP/1.0 Printer would not have
+   processed a request with the correct semantics that contained the
+   "ipp-attribute-fidelity" attribute that it did not know about.  Items
+   that might affect the changing of the major version number include
+   any changes to the Model and Semantics document (this document) or
+   the "Encoding and Transport" document [RFC2910] itself, such as:
+
+      - reordering of ordered attributes or attribute sets
+      - changes to the syntax of existing attributes
+      - adding REQUIRED (for an IPP object to support) operation
+        attribute groups
+      - adding values to existing REQUIRED operation attributes
+      - adding REQUIRED operations
+
+   Changes to the minor version number indicate the addition of new
+   features, attributes and attribute values that may not be understood
+   by all IPP objects, but which can be ignored if not understood.
+   Items that might affect the changing of the minor version number
+   include any changes to the model objects and attributes but not the
+   encoding and transport rules [RFC2910] (except adding attribute
+   syntaxes).  Examples of such changes are:
+
+      - grouping all extensions not included in a previous version into
+        a new version
+      - adding new attribute values
+      - adding new object attributes
+      - adding OPTIONAL (for an IPP object to support) operation
+        attributes (i.e., those attributes that an IPP object can ignore
+        without confusing clients)
+      - adding OPTIONAL (for an IPP object to support) operation
+        attribute groups (i.e., those attributes that an IPP object can
+        ignore without confusing clients)
+      - adding new attribute syntaxes
+      - adding OPTIONAL operations
+      - changing Job Description attributes or Printer Description
+        attributes from OPTIONAL to REQUIRED or vice versa.
+      - adding OPTIONAL attribute syntaxes to an existing attribute.
+
+   The encoding of the "version-number" MUST NOT change over any version
+   number (either major or minor).  This rule guarantees that all future
+
+
+
+Hastings, et al.            Standards Track                    [Page 37]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   versions will be backwards compatible with all previous versions (at
+   least for checking  the "version-number").  In addition, any protocol
+   elements (attributes, error codes, tags, etc.) that are not carried
+   forward from one version to the next are deprecated so that they can
+   never be reused with new semantics.
+
+   Implementations that support a certain  version NEED NOT support ALL
+   previous versions.  As each new  version is defined (through the
+   release of a new IPP specification document), that version will
+   specify which previous  versions MUST and which versions SHOULD be
+   supported in compliant implementations.
+
+3.1.9 Job Creation Operations
+
+   In order to "submit a print job" and create a new Job object, a
+   client issues a create request.  A create request is any one of
+   following three operation requests:
+
+      - The Print-Job Request: A client that wants to submit a print job
+        with only a single document uses the Print-Job operation.  The
+        operation allows for the client to "push" the document data to
+        the Printer object by including the document data in the request
+        itself.
+
+      - The Print-URI Request: A client that wants to submit a print job
+        with only a single document (where the Printer object "pulls"
+        the document data instead of the client "pushing" the data to
+        the Printer object) uses the Print-URI operation.   In this
+        case, the client includes in the request only a URI reference to
+        the document data (not the document data itself).
+
+      - The Create-Job Request: A client that wants to submit a print
+        job with multiple documents uses the Create-Job operation.  This
+        operation is followed by an arbitrary number (one or more) of
+        Send-Document and/or Send-URI operations (each creating another
+        document for the newly create Job object).  The Send-Document
+        operation includes the document data in the request (the client
+        "pushes" the document data to the printer), and the Send-URI
+        operation includes only a URI reference to the document data in
+        the request (the Printer "pulls" the document data from the
+        referenced location).  The last Send-Document or Send-URI
+        request for a given Job object includes a "last-document"
+        operation attribute set to 'true' indicating that this is the
+        last request.
+
+   Throughout this model document, the term "create request" is used to
+   refer to any of these three operation requests.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 38]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   A Create-Job operation followed by only one Send-Document operation
+   is semantically equivalent to a Print-Job operation, however, for
+   performance reasons, the client SHOULD use the Print-Job operation
+   for all single document jobs.  Also, Print-Job is a REQUIRED
+   operation (all implementations MUST support it) whereas Create-Job is
+   an OPTIONAL operation, hence some implementations might not support
+   it.
+
+   Job submission time is the point in time when a client issues a
+   create request.  The initial state of every Job object is the
+   'pending', 'pending-held', or 'processing' state (see section 4.3.7).
+   When the Printer object begins processing the print job, the Job
+   object's state moves to 'processing'.  This is known as job
+   processing time.  There are validation checks that must be done at
+   job submission time and others that must be performed at job
+   processing time.
+
+   At job submission time and at the time a Validate-Job operation is
+   received, the Printer MUST do the following:
+
+      1. Process the client supplied attributes and either accept or
+         reject the request
+      2. Validate the syntax of and support for the scheme of any client
+         supplied URI
+
+   At job submission time the Printer object MUST validate whether or
+   not the supplied attributes, attribute syntaxes, and values are
+   supported by matching them with the Printer object's corresponding
+   "xxx-supported" attributes.  See section 3.1.7 for details.  [IPP-
+   IIG] presents suggested steps for an IPP object to either accept or
+   reject any request and additional steps for processing create
+   requests.
+
+   At job submission time the Printer object NEED NOT perform the
+   validation checks reserved for job processing time such as:
+
+      1. Validating the document data
+      2. Validating the actual contents of any client supplied URI
+         (resolve the reference and follow the link to the document
+         data)
+
+   At job submission time, these additional job processing time
+   validation checks are essentially useless, since they require
+   actually parsing and interpreting the document data, are not
+   guaranteed to be 100% accurate, and MUST be done, yet again, at job
+   processing time.  Also, in the case of a URI, checking for
+   availability at job submission time does not guarantee availability
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 39]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   at job processing time.  In addition, at job processing time, the
+   Printer object might discover any of the following conditions that
+   were not detectable at job submission time:
+
+      - runtime errors in the document data,
+      - nested document data that is in an unsupported format,
+      - the URI reference is no longer valid (i.e., the server hosting
+        the document might be down), or
+      - any other job processing error
+
+   At job submission time, a Printer object, especially a non-spooling
+   Printer, MAY accept jobs that it does not have enough space for.  In
+   such a situation, a Printer object MAY stop reading data from a
+   client for an indefinite period of time.  A client MUST be prepared
+   for a write operation to block for an indefinite period of time (see
+   section 5.1 on client conformance).
+
+   When a Printer object has too little space for starting a new job, it
+   MAY reject a new create request. In this case, a Printer object MUST
+   return a response (in reply to the rejected request) with a status-
+   code of 'server-error-busy' (see section 14.1.5.8) and it MAY close
+   the connection before receiving all bytes of the operation.  A
+   Printer SHOULD indicate that it is temporarily unable to accept jobs
+   by setting the 'spool-space-full' value in its "printer-state-
+   reasons" attribute and removing the value when it can accept another
+   job (see section 4.4.12).
+
+   When receiving a 'server-error-busy' status-code in an operation
+   response, a client MUST be prepared for the Printer object to close
+   the connection before the client has sent all of the data (especially
+   for the Print-Job operation). A client MUST be prepared to keep
+   submitting a create request until the IPP Printer object accepts the
+   create request.
+
+   At job processing time, since the Printer object has already
+   responded with a successful status code in the response to the create
+   request, if the Printer object detects an error, the Printer object
+   is unable to inform the end user of the error with an operation
+   status code.   In this case, the Printer, depending on the error, can
+   set the job object's "job-state", "job-state-reasons", or "job-
+   state-message" attributes to the appropriate value(s) so that later
+   queries can report the correct job status.
+
+   Note: Asynchronous notification of events is outside the scope of
+   this IPP/1.1 document.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 40]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.2 Printer Operations
+
+   All Printer operations are directed at Printer objects.  A client
+   MUST always supply the "printer-uri" operation attribute in order to
+   identify the correct target of the operation.
+
+3.2.1 Print-Job Operation
+
+   This REQUIRED operation allows a client to submit a print job with
+   only one document and supply the document data (rather than just a
+   reference to the data).  See Section 15 for the suggested steps for
+   processing create operations and their Operation and Job Template
+   attributes.
+
+3.2.1.1 Print-Job Request
+
+   The following groups of attributes are supplied as part of the
+   Print-Job Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.1.  The Printer object
+         MUST copy these values to the corresponding Job Description
+         attributes described in sections 4.3.19 and 4.3.20.
+
+      Target:
+         The "printer-uri" (uri) operation attribute which is the target
+         for this operation as described in section 3.1.5.
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client as described in section 8.3.
+
+      "job-name" (name(MAX)):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  It contains the client
+         supplied Job name.  If this attribute is supplied by the
+         client, its value is used for the "job-name" attribute of the
+         newly created Job object.  The client MAY automatically include
+         any information that will help the end-user distinguish amongst
+         his/her jobs, such as the name of the application program along
+         with information from the document, such as the document name,
+         document subject, or source file name.  If this attribute is
+         not supplied by the client, the Printer generates a name to use
+         in the "job-name" attribute of the newly created Job object
+         (see Section 4.3.5).
+
+
+
+Hastings, et al.            Standards Track                    [Page 41]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      "ipp-attribute-fidelity" (boolean):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  The value 'true' indicates
+         that total fidelity to client supplied Job Template attributes
+         and values is required, else the Printer object MUST reject the
+         Print-Job request.  The value 'false' indicates that a
+         reasonable attempt to print the Job object is acceptable and
+         the Printer object MUST accept the Print-Job request. If not
+         supplied, the Printer object assumes the value is 'false'.  All
+         Printer objects MUST support both types of job processing.  See
+         section 15 for a full description of "ipp-attribute-fidelity"
+         and its relationship to other attributes, especially the
+         Printer object's "pdl-override-supported" attribute.
+
+      "document-name" (name(MAX)):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.   It contains the client
+         supplied document name.  The document name MAY be different
+         than the Job name.  Typically, the client software
+         automatically supplies the document name on behalf of the end
+         user by using a file name or an application generated name.  If
+         this attribute is supplied, its value can be used in a manner
+         defined by each implementation.  Examples include: printed
+         along with the Job (job start sheet, page adornments, etc.),
+         used by accounting or resource tracking management tools, or
+         even stored along with the document as a document level
+         attribute.  IPP/1.1 does not support the concept of document
+         level attributes.
+
+      "compression" (type3 keyword):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute and the "compression-
+         supported" attribute (see section 4.4.32).  The client supplied
+         "compression" operation attribute identifies the compression
+         algorithm used on the document data. The following cases exist:
+
+         a) If the client omits this attribute, the Printer object MUST
+            assume that the data is not compressed   (i.e. the Printer
+            follows the rules below as if the client supplied the
+            "compression" attribute with a value of 'none').
+         b) If the client supplies this attribute, but the value is not
+            supported by the Printer object, i.e., the value is not one
+            of the values of the Printer object's "compression-
+            supported" attribute, the Printer object MUST reject the
+            request, and return the 'client-error-compression-not-
+            supported' status code. See section 3.1.7 for returning
+            unsupported attributes and values.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 42]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         c) If the client supplies the attribute and the Printer object
+            supports the attribute value, the Printer object uses the
+            corresponding decompression algorithm on the document data.
+         d) If the decompression algorithm fails before the Printer
+            returns an operation response, the Printer object MUST
+            reject the request and return the 'client-error-
+            compression-error' status code.
+         e) If the decompression algorithm fails after the Printer
+            returns an operation response, the Printer object MUST abort
+            the job and add the 'compression-error' value to the job's
+            "job-state-reasons" attribute.
+         f) If the decompression algorithm succeeds, the document data
+            MUST then have the format specified by the job's "document-
+            format" attribute, if supplied (see "document-format"
+            operation attribute definition below).
+
+      "document-format" (mimeMediaType):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  The value of this
+         attribute identifies the format of the supplied document data.
+         The following cases exist:
+
+         a) If the client does not supply this attribute, the Printer
+            object assumes that the document data is in the format
+            defined by the Printer object's "document-format-default"
+            attribute. (i.e. the Printer follows the rules below as if
+            the client supplied the "document-format" attribute with a
+            value equal to the printer's default value).
+         b) If the client supplies this attribute, but the value is not
+            supported by the Printer object, i.e., the value is not one
+            of the values of the Printer object's "document-format-
+            supported" attribute, the Printer object MUST reject the
+            request and return the 'client-error-document-format-not-
+            supported' status code.
+         c) If the client supplies this attribute and its value is
+            'application/octet-stream' (i.e. to be auto-sensed, see
+            Section 4.1.9.1), and the format is not one of the
+            document-formats that the Printer can auto-sense, and this
+            check occurs before the Printer returns an operation
+            response, then the Printer MUST reject the request and
+            return the  'client-error-document-format-not-supported'
+            status code.
+         d) If the client supplies this attribute, and the value is
+            supported by the Printer object, the Printer is capable of
+            interpreting the document data.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 43]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         e) If interpreting of the document data fails before the
+            Printer returns an operation response, the Printer object
+            MUST reject the request and return the 'client-error-
+            document-format-error' status code.
+         f) If interpreting of the document data fails after the Printer
+            returns an operation response, the Printer object MUST abort
+            the job and add the 'document-format-error' value to the
+            job's "job-state-reasons" attribute.
+
+      "document-natural-language" (naturalLanguage):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object OPTIONALLY supports this attribute. This attribute
+         specifies the natural language of the document for those
+         document-formats that require a specification of the natural
+         language in order to image the document unambiguously. There
+         are no particular values required for the Printer object to
+         support.
+
+      "job-k-octets" (integer(0:MAX)):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object OPTIONALLY supports this attribute and the "job-k-
+         octets-supported" attribute (see section 4.4.33).  The client
+         supplied "job-k-octets" operation attribute identifies the
+         total size of the document(s) in K octets being submitted (see
+         section 4.3.17.1 for the complete semantics).  If the client
+         supplies the attribute and the Printer object supports the
+         attribute, the value of the attribute is used to populate the
+         Job object's "job-k-octets" Job Description attribute.
+
+         For this attribute and the following two attributes ("job-
+         impressions", and "job-media-sheets"), if the client supplies
+         the attribute, but the Printer object does not support the
+         attribute, the Printer object ignores the client-supplied
+         value.  If the client supplies the attribute and the Printer
+         supports the attribute, and the value is within the range of
+         the corresponding Printer object's "xxx-supported" attribute,
+         the Printer object MUST use the value to populate the Job
+         object's "xxx" attribute.  If the client supplies the attribute
+         and the Printer supports the attribute, but the value is
+         outside the range of the corresponding Printer object's "xxx-
+         supported" attribute, the Printer object MUST copy the
+         attribute and its value to the Unsupported Attributes response
+         group, reject the request, and return the 'client-error-
+         attributes-or-values-not-supported' status code.  If the client
+         does not supply the attribute, the Printer object MAY choose to
+         populate the corresponding Job object attribute depending on
+         whether the Printer object supports the attribute and is able
+         to calculate or discern the correct value.
+
+
+
+Hastings, et al.            Standards Track                    [Page 44]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      "job-impressions" (integer(0:MAX)):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object OPTIONALLY supports this attribute and the "job-
+         impressions-supported" attribute (see section 4.4.34).  The
+         client supplied "job-impressions" operation attribute
+         identifies the total size in number of impressions of the
+         document(s) being submitted (see section 4.3.17.2 for the
+         complete semantics).
+
+         See last paragraph under "job-k-octets".
+
+      "job-media-sheets" (integer(0:MAX)):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object OPTIONALLY supports this attribute and the "job-media-
+         sheets-supported" attribute (see section 4.4.35).  The client
+         supplied "job-media-sheets" operation attribute identifies the
+         total number of media sheets to be produced for this job (see
+         section 4.3.17.3 for the complete semantics).
+
+         See last paragraph under "job-k-octets".
+
+   Group 2: Job Template Attributes
+
+      The client OPTIONALLY supplies a set of Job Template attributes as
+      defined in section 4.2.  If the client is not supplying any Job
+      Template attributes in the request, the client SHOULD omit Group 2
+      rather than sending an empty group.  However, a Printer object
+      MUST be able to accept an empty group.
+
+   Group 3: Document Content
+
+      The client MUST supply the document data to be processed.
+
+      In addition to the MANDATORY parameters required for every
+      operation request, the simplest Print-Job Request consists of just
+      the "attributes-charset" and "attributes-natural-language"
+      operation attributes; the "printer-uri" target operation
+      attribute; the Document Content and nothing else.  In this simple
+      case, the Printer object:
+
+      - creates a new Job object (the Job object contains a single
+        document),
+      - stores a generated Job name in the "job-name" attribute in the
+        natural language and charset requested (see Section 3.1.4.1) (if
+        those are supported, otherwise using the Printer object's
+        default natural language and charset), and
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 45]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - at job processing time, uses its corresponding default value
+        attributes for the supported Job Template attributes that were
+        not supplied by the client as IPP attribute or embedded
+        instructions in the document data.
+
+3.2.1.2 Print-Job Response
+
+   The Printer object MUST return to the client the following sets of
+   attributes as part of the Print-Job Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+         In addition to the REQUIRED status code returned in every
+         response, the response OPTIONALLY includes a "status-message"
+         (text(255)) and/or a "detailed-status-message" (text(MAX))
+         operation attribute as described in sections 13 and 3.1.6.  If
+         the client supplies unsupported or conflicting Job Template
+         attributes or values, the Printer object MUST reject or accept
+         the Print-Job request depending on the whether the client
+         supplied a 'true' or 'false' value for the "ipp-attribute-
+         fidelity" operation attribute.  See the Implementer's Guide
+         [IPP-IIG] for a complete description of the suggested steps for
+         processing a create request.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See section 3.1.7 for details on returning Unsupported Attributes.
+
+      The value of the "ipp-attribute-fidelity" supplied by the client
+      does not affect what attributes the Printer object returns in this
+      group.  The value of "ipp-attribute-fidelity" only affects whether
+      the Print-Job operation is accepted or rejected.  If the job is
+      accepted, the client may query the job using the Get-Job-
+      Attributes operation requesting the unsupported attributes that
+      were returned in the create response to see which attributes were
+      ignored (not stored on the Job object) and which attributes were
+      stored with other (substituted) values.
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 46]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Group 3: Job Object Attributes
+
+      "job-uri" (uri):
+         The Printer object MUST return the Job object's URI by
+         returning the contents of the REQUIRED "job-uri" Job object
+         attribute.  The client uses the Job object's URI when directing
+         operations at the Job object.  The Printer object always uses
+         its configured security policy when creating the new URI.
+         However, if the Printer object supports more than one URI, the
+         Printer object also uses information about which URI was used
+         in the Print-Job Request to generated the new URI so that the
+         new URI references the correct access channel.  In other words,
+         if the Print-Job Request comes in over a secure channel, the
+         Printer object MUST generate a Job URI that uses the secure
+         channel as well.
+
+      "job-id" (integer(1:MAX)):
+         The Printer object MUST return the Job object's Job ID by
+         returning the REQUIRED  "job-id" Job object attribute.  The
+         client uses this "job-id" attribute in conjunction with the
+         "printer-uri" attribute used in the Print-Job Request when
+         directing Job operations at the Printer object.
+
+      "job-state" (type1 enum):
+         The Printer object MUST return the Job object's REQUIRED "job-
+         state" attribute. The value of this attribute (along with the
+         value of the next attribute:  "job-state-reasons") is taken
+         from a "snapshot" of the new Job object at some meaningful
+         point in time (implementation defined) between when the Printer
+         object receives the Print-Job Request and when the Printer
+         object returns the response.
+
+      "job-state-reasons" (1setOf type2 keyword):
+         The Printer object MUST return the Job object's REQUIRED "job-
+         state-reasons" attribute.
+
+      "job-state-message" (text(MAX)):
+         The Printer object OPTIONALLY returns the Job object's OPTIONAL
+         "job-state-message" attribute.  If the Printer object supports
+         this attribute then it MUST be returned in the response.  If
+         this attribute is not returned in the response, the client can
+         assume that the "job-state-message" attribute is not supported
+         and will not be returned in a subsequent Job object query.
+
+      "number-of-intervening-jobs" (integer(0:MAX)):
+         The Printer object OPTIONALLY returns the Job object's OPTIONAL
+         "number-of-intervening-jobs" attribute.  If the Printer object
+         supports this attribute then it MUST be returned in the
+
+
+
+Hastings, et al.            Standards Track                    [Page 47]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         response.  If this attribute is not returned in the response,
+         the client can assume that the "number-of-intervening-jobs"
+         attribute is not supported and will not be returned in a
+         subsequent Job object query.
+
+         Note: Since any printer state information which affects a job's
+         state is reflected in the "job-state" and "job-state-reasons"
+         attributes, it is sufficient to return only these attributes
+         and no specific printer status attributes.
+
+   Note: In addition to the MANDATORY parameters required for every
+   operation response, the simplest response consists of the just the
+   "attributes-charset" and "attributes-natural-language" operation
+   attributes and the "job-uri", "job-id", and "job-state" Job Object
+   Attributes.  In this simplest case, the status code is 'successful-
+   ok' and there is no "status-message" or "detailed-status-message"
+   operation attribute.
+
+3.2.2 Print-URI Operation
+
+   This OPTIONAL operation is identical to the Print-Job operation
+   (section 3.2.1) except that a client supplies a URI reference to the
+   document data using the "document-uri" (uri) operation attribute (in
+   Group 1) rather than including the document data itself.  Before
+   returning the response, the Printer MUST validate that the Printer
+   supports the retrieval method (e.g., http, ftp, etc.) implied by the
+   URI, and MUST check for valid URI syntax.  If the client-supplied URI
+   scheme is not supported, i.e. the value is not in the Printer
+   object's "referenced-uri-scheme-supported" attribute, the Printer
+   object MUST reject the request and return the 'client-error-uri-
+   scheme-not-supported' status code.
+
+   The IPP Printer MAY validate the accessibility of the document as
+   part of the operation or subsequently.  If the Printer determines an
+   accessibility problem before returning an operation response, it
+   rejects the request and returns the 'client-error-document-access-
+   error' status code.  The Printer MAY also return a specific document
+   access error code using the "document-access-error" operation
+   attribute (see section 3.1.6.4).
+
+   If the Printer determines this document accessibility problem after
+   accepting the request and returning an operation response with one of
+   the successful status codes, the Printer adds the 'document-access-
+   error' value to the job's "job-state-reasons" attribute and MAY
+   populate the job's "job-document-access-errors" Job Description
+   attribute (see section 4.3.11).  See The Implementer's Guide [IPP-
+   IIG] for suggested additional checks.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 48]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   If the Printer object supports this operation, it MUST support the
+   "reference-uri-schemes-supported" Printer attribute (see section
+   4.4.27).
+
+   It is up to the IPP object to interpret the URI and subsequently
+   "pull" the document from the source referenced by the URI string.
+
+3.2.3 Validate-Job Operation
+
+   This REQUIRED operation is similar to the Print-Job operation
+   (section 3.2.1) except that a client supplies no document data and
+   the Printer allocates no resources (i.e., it does not create a new
+   Job object).  This operation is used only to verify capabilities of a
+   printer object against whatever attributes are supplied by the client
+   in the Validate-Job request.  By using the Validate-Job operation a
+   client can validate that an identical Print-Job operation (with the
+   document data) would be accepted. The Validate-Job operation also
+   performs the same security negotiation as the Print-Job operation
+   (see section 8), so that a client can check that the client and
+   Printer object security requirements can be met before performing a
+   Print-Job operation.
+
+   The Validate-Job operation does not accept a "document-uri" attribute
+   in order to allow a client to check that the same Print-URI operation
+   will be accepted, since the client doesn't send the data with the
+   Print-URI operation.  The client SHOULD just issue the Print-URI
+   request.
+
+   The Printer object returns the same status codes, Operation
+   Attributes (Group 1) and Unsupported Attributes (Group 2) as the
+   Print-Job operation.  However, no Job Object Attributes (Group 3) are
+   returned, since no Job object is created.
+
+3.2.4 Create-Job Operation
+
+   This OPTIONAL operation is similar to the Print-Job operation
+   (section 3.2.1) except that in the Create-Job request, a client does
+   not supply document data or any reference to document data.  Also,
+   the client does not supply any of the "document-name", "document-
+   format", "compression", or "document-natural-language" operation
+   attributes.  This operation is followed by one or more Send-Document
+   or Send-URI operations.  In each of those operation requests, the
+   client OPTIONALLY supplies the "document-name", "document-format",
+   and "document-natural-language" attributes for each document in the
+   multi-document Job object.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 49]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   If a Printer object supports the Create-Job operation, it MUST also
+   support the Send-Document operation and also MAY support the Send-URI
+   operation.
+
+   If the Printer object supports this operation, it MUST support the
+   "multiple-operation-time-out" Printer attribute (see section 4.4.31).
+
+   If the Printer object supports this operation, then it MUST support
+   the "multiple-document-jobs-supported" Printer Description attribute
+   (see section 4.4.16) and indicate whether or not it supports
+   multiple-document jobs.
+
+   If the Printer object supports this operation and supports multiple
+   documents in a job, then it MUST support the "multiple-document-
+   handling" Job Template job attribute with at least one value (see
+   section 4.2.4) and the associated "multiple-document-handling-
+   default" and "multiple-document-handling-supported" Job Template
+   Printer attributes (see section 4.2).
+
+   After the Create-Job operation has completed, the value of the "job-
+   state" attribute is similar to the "job-state" after a Print-Job,
+   even though no document-data has arrived.  A Printer MAY set the
+   'job-data-insufficient' value of the job's "job-state-reason"
+   attribute to indicate that processing cannot begin until sufficient
+   data has arrived and set the "job-state" to either 'pending' or
+   'pending-held'.  A non-spooling printer that doesn't implement the
+   'pending' job state may even set the "job-state" to 'processing',
+   even though there is not yet any data to process.  See sections 4.3.7
+   and 4.3.8.
+
+3.2.5 Get-Printer-Attributes Operation
+
+   This REQUIRED operation allows a client to request the values of the
+   attributes of a Printer object.   In the request, the client supplies
+   the set of Printer attribute names and/or attribute group names in
+   which the requester is interested.  In the response, the Printer
+   object returns a corresponding attribute set with the appropriate
+   attribute values filled in.
+
+   For Printer objects, the possible names of attribute groups are:
+
+      - 'job-template': the subset of the Job Template attributes that
+        apply to a Printer object (the last two columns of the table in
+        Section 4.2) that the implementation supports for Printer
+        objects.
+      - 'printer-description': the subset of the attributes specified in
+        Section 4.4 that the implementation supports for Printer
+        objects.
+
+
+
+Hastings, et al.            Standards Track                    [Page 50]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - 'all': the special group 'all' that includes all attributes that
+        the implementation supports for Printer objects.
+
+   Since a client MAY request specific attributes or named groups, there
+   is a potential that there is some overlap.  For example, if a client
+   requests, 'printer-name' and 'all', the client is actually requesting
+   the "printer-name" attribute twice: once by naming it explicitly, and
+   once by inclusion in the 'all' group.  In such cases, the Printer
+   object NEED NOT return each attribute only once in the response even
+   if it is requested multiple times.  The client SHOULD NOT request the
+   same attribute in multiple ways.
+
+   It is NOT REQUIRED that a Printer object support all attributes
+   belonging to a group (since some attributes are OPTIONAL).  However,
+   it is REQUIRED that each Printer object support all group names.
+
+3.2.5.1 Get-Printer-Attributes Request
+
+   The following sets of attributes are part of the Get-Printer-
+   Attributes Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.1.
+
+      Target:
+         The "printer-uri" (uri) operation attribute which is the target
+         for this operation as described in section 3.1.5.
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client as described in section 8.3.
+
+      "requested-attributes" (1setOf keyword):
+         The client OPTIONALLY supplies a set of attribute names and/or
+         attribute group names in whose values the requester is
+         interested.  The Printer object MUST support this attribute.
+         If the client omits this attribute, the Printer MUST respond as
+         if this attribute had been supplied with a value of 'all'.
+
+      "document-format" (mimeMediaType):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  This attribute is useful
+         for a Printer object to determine the set of supported
+         attribute values that relate to the requested document format.
+         The Printer object MUST return the attributes and values that
+
+
+
+Hastings, et al.            Standards Track                    [Page 51]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         it uses to validate a job on a create or Validate-Job operation
+         in which this document format is supplied. The Printer object
+         SHOULD return only (1) those attributes that are supported for
+         the specified format and (2) the attribute values that are
+         supported for the specified document format.  By specifying the
+         document format, the client can get the Printer object to
+         eliminate the attributes and values that are not supported for
+         a specific document format.  For example, a Printer object
+         might have multiple interpreters to support both
+         'application/postscript' (for PostScript) and 'text/plain' (for
+         text) documents.  However, for only one of those interpreters
+         might the Printer object be able to support "number-up" with
+         values of '1', '2', and '4'.  For the other interpreter it
+         might be able to only support "number-up" with a value of '1'.
+         Thus a client can use the Get-Printer-Attributes operation to
+         obtain the attributes and values that will be used to
+         accept/reject a create job operation.
+
+         If the Printer object does not distinguish between different
+         sets of supported values for each different document format
+         when validating jobs in the create and Validate-Job operations,
+         it MUST NOT distinguish between different document formats in
+         the Get-Printer-Attributes operation. If the Printer object
+         does distinguish between different sets of supported values for
+         each different document format specified by the client, this
+         specialization applies only to the following Printer object
+         attributes:
+
+      - Printer attributes that are Job Template attributes ("xxx-
+        default" "xxx-supported", and "xxx-ready" in the Table in
+        Section 4.2),
+      - "pdl-override-supported",
+      - "compression-supported",
+      - "job-k-octets-supported",
+      - "job-impressions-supported",
+      - "job-media-sheets-supported",
+      - "printer-driver-installer",
+      - "color-supported", and
+      - "reference-uri-schemes-supported"
+
+      The values of all other Printer object attributes (including
+      "document-format-supported") remain invariant with respect to the
+      client supplied document format (except for new Printer
+      description attribute as registered according to section 6.2).
+
+      If the client omits this "document-format" operation attribute,
+      the Printer object MUST respond as if the attribute had been
+      supplied with the value of the Printer object's "document-format-
+
+
+
+Hastings, et al.            Standards Track                    [Page 52]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      default" attribute.  It is RECOMMENDED that the client always
+      supply a value for "document-format", since the Printer object's
+      "document-format-default" may be 'application/octet-stream', in
+      which case the returned attributes and values are for the union of
+      the document formats that the Printer can automatically sense.
+      For more details, see the description of the 'mimeMediaType'
+      attribute syntax in section 4.1.9.
+
+      If the client supplies a value for the "document-format" Operation
+      attribute that is not supported by the Printer, i.e., is not among
+      the values of the Printer object's "document-format-supported"
+      attribute, the Printer object MUST reject the operation and return
+      the 'client-error-document-format-not-supported' status code.
+
+3.2.5.2 Get-Printer-Attributes Response
+
+   The Printer object returns the following sets of attributes as part
+   of the Get-Printer-Attributes Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text(255)) and/or a "detailed-status-message" (text(MAX))
+        operation attribute as described in sections 13 and  3.1.6.
+
+      Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See section 3.1.7 for details on returning Unsupported Attributes.
+
+      The response NEED NOT contain the "requested-attributes" operation
+      attribute with any supplied values (attribute keywords) that were
+      requested by the client but are not supported by the IPP object.
+      If the Printer object does return unsupported attributes
+      referenced in the "requested-attributes" operation attribute and
+      that attribute included group names, such as 'all', the
+      unsupported attributes MUST NOT include attributes described in
+      the standard but not supported by the implementation.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 53]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Group 3: Printer Object Attributes
+
+      This is the set of requested attributes and their current values.
+      The Printer object ignores (does not respond with) any requested
+      attribute which is not supported.  The Printer object MAY respond
+      with a subset of the supported attributes and values, depending on
+      the security policy in force.  However, the Printer object MUST
+      respond with the 'unknown' value for any supported attribute
+      (including all REQUIRED attributes) for which the Printer object
+      does not know the value.  Also the Printer object MUST respond
+      with the 'no-value' for any supported attribute (including all
+      REQUIRED attributes) for which the system administrator has not
+      configured a value.  See the description of the "out-of-band"
+      values in the beginning of Section 4.1.
+
+3.2.6 Get-Jobs Operation
+
+   This REQUIRED operation allows a client to retrieve the list of Job
+   objects belonging to the target Printer object.  The client may also
+   supply a list of Job attribute names and/or attribute group names.  A
+   group of Job object attributes will be returned for each Job object
+   that is returned.
+
+   This operation is similar to the Get-Job-Attributes operation, except
+   that this Get-Jobs operation returns attributes from possibly more
+   than one object.
+
+3.2.6.1 Get-Jobs Request
+
+   The client submits the Get-Jobs request to a Printer object.
+
+   The following groups of attributes are part of the Get-Jobs Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.1.
+
+      Target:
+         The "printer-uri" (uri) operation attribute which is the target
+         for this operation as described in section 3.1.5.
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client as described in section 8.3.
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 54]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      "limit" (integer(1:MAX)):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute. It is an integer value that
+         determines the maximum number of jobs that a client will
+         receive from the Printer even if "which-jobs" or "my-jobs"
+         constrain which jobs are returned.  The limit is a "stateless
+         limit" in that if the value supplied by the client is 'N', then
+         only the first 'N' jobs are returned in the Get-Jobs Response.
+         There is no mechanism to allow for the next 'M' jobs after the
+         first 'N' jobs.  If the client does not supply this attribute,
+         the Printer object responds with all applicable jobs.
+
+      "requested-attributes" (1setOf type2 keyword):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  It is a set of Job
+         attribute names and/or attribute groups names in whose values
+         the requester is interested.  This set of attributes is
+         returned for each Job object that is returned.  The allowed
+         attribute group names are the same as those defined in the
+         Get-Job-Attributes operation in section 3.3.4.  If the client
+         does not supply this attribute, the Printer MUST respond as if
+         the client had supplied this attribute with two values: 'job-
+         uri' and 'job-id'.
+
+      "which-jobs" (type2 keyword):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  It indicates which Job
+         objects MUST be returned by the Printer object. The values for
+         this attribute are:
+
+      'completed': This includes any Job object whose state is
+         'completed', 'canceled', or 'aborted'.
+      'not-completed': This includes any Job object whose state is
+         'pending', 'processing', 'processing-stopped', or 'pending-
+         held'.
+
+         A Printer object MUST support both values.  However, if the
+         implementation does not keep jobs in the 'completed',
+         'canceled', and 'aborted' states, then it returns no jobs when
+         the 'completed' value is supplied.
+
+         If a client supplies some other value, the Printer object MUST
+         copy the attribute and the unsupported value to the Unsupported
+         Attributes response group, reject the request, and return the
+         'client-error-attributes-or-values-not-supported' status code.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 55]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         If the client does not supply this attribute, the Printer
+         object MUST respond as if the client had supplied the attribute
+         with a value of 'not-completed'.
+
+      "my-jobs" (boolean):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  It indicates whether jobs
+         from all users or just the jobs submitted by the requesting
+         user of this request MUST be considered as candidate jobs to be
+         returned by the Printer object.  If the client does not supply
+         this attribute, the Printer object MUST respond as if the
+         client had supplied the attribute with a value of 'false',
+         i.e., jobs from all users.  The means for authenticating the
+         requesting user and matching the jobs is described in section
+         8.
+
+3.2.6.2 Get-Jobs Response
+
+   The Printer object returns all of the Job objects up to the number
+   specified by the "limit" attribute that match the criteria as defined
+   by the attribute values supplied by the client in the request.  It is
+   possible that no Job objects are returned since there may literally
+   be no Job objects at the Printer, or there may be no Job objects that
+   match the criteria supplied by the client.  If the client requests
+   any Job attributes at all, there is a set of Job Object Attributes
+   returned for each Job object.
+
+   It is not an error for the Printer to return 0 jobs. If the response
+   returns 0 jobs because there are no jobs matching the criteria, and
+   the request would have returned 1 or more jobs with a status code of
+   'successful-ok' if there had been jobs matching the criteria, then
+   the status code for 0 jobs MUST be 'successful-ok'.
+
+   Group 1: Operation Attributes
+
+      Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text(255)) and/or a "detailed-status-message" (text(MAX))
+        operation attribute as described in sections 13 and 3.1.6.
+
+      Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 56]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Group 2: Unsupported Attributes
+
+      See section 3.1.7 for details on returning Unsupported Attributes.
+
+      The response NEED NOT contain the "requested-attributes" operation
+      attribute with any supplied values (attribute keywords) that were
+      requested by the client but are not supported by the IPP object.
+      If the Printer object does return unsupported attributes
+      referenced in the "requested-attributes" operation attribute and
+      that attribute included group names, such as 'all', the
+      unsupported attributes MUST NOT include attributes described in
+      the standard but not supported by the implementation.
+
+   Groups 3 to N: Job Object Attributes
+
+      The Printer object responds with one set of Job Object Attributes
+      for each returned Job object.  The Printer object ignores (does
+      not respond with) any requested attribute or value which is not
+      supported or which is restricted by the security policy in force,
+      including whether the requesting user is the user that submitted
+      the job (job originating user) or not (see section 8).  However,
+      the Printer object MUST respond with the 'unknown' value for any
+      supported attribute (including all REQUIRED attributes) for which
+      the Printer object does not know the value, unless it would
+      violate the security policy.  See the description of the "out-of-
+      band" values in the beginning of Section 4.1.
+
+      Jobs are returned in the following order:
+
+      - If the client requests all 'completed' Jobs (Jobs in the
+        'completed', 'aborted', or 'canceled' states), then the Jobs are
+        returned newest to oldest (with respect to actual completion
+        time)
+      - If the client requests all 'not-completed' Jobs (Jobs in the
+        'pending', 'processing', 'pending-held', and 'processing-
+        stopped' states), then Jobs are returned in relative
+        chronological order of expected time to complete (based on
+        whatever scheduling algorithm is configured for the Printer
+        object).
+
+3.2.7 Pause-Printer Operation
+
+   This OPTIONAL operation allows a client to stop the Printer object
+   from scheduling jobs on all its devices.  Depending on
+   implementation, the Pause-Printer operation MAY also stop the Printer
+   from processing the current job or jobs.  Any job that is currently
+   being printed is either stopped as soon as the implementation permits
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 57]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   or is completed, depending on implementation.  The Printer object
+   MUST still accept create operations to create new jobs, but MUST
+   prevent any jobs from entering the 'processing' state.
+
+   If the Pause-Printer operation is supported, then the Resume-Printer
+   operation MUST be supported, and vice-versa.
+
+   The IPP Printer stops the current job(s) on its device(s) that were
+   in the 'processing' or 'processing-stopped' states as soon as the
+   implementation permits.  If the implementation will take appreciable
+   time to stop, the IPP Printer adds the 'moving-to-paused' value to
+   the Printer object's "printer-state-reasons" attribute (see section
+   4.4.12).  When the device(s) have all stopped, the IPP Printer
+   transitions the Printer object to the 'stopped' state, removes the
+   'moving-to-paused' value, if present, and adds the 'paused' value to
+   the Printer object's "printer-state-reasons" attribute.
+
+   When the current job(s) complete that were in the 'processing' state,
+   the IPP Printer transitions them to the 'completed' state.  When the
+   current job(s) stop in mid processing that were in the 'processing'
+   state, the IPP Printer transitions them to the 'processing-stopped'
+   state and adds the 'printer-stopped' value to the job's "job-state-
+   reasons" attribute.
+
+   For any jobs that are 'pending' or 'pending-held', the 'printer-
+   stopped' value of the jobs' "job-state-reasons" attribute also
+   applies.  However, the IPP Printer NEED NOT update those jobs' "job-
+   state-reasons" attributes and only need return the 'printer-stopped'
+   value when those jobs are queried (so-called "lazy evaluation").
+
+   Whether the Pause-Printer operation affects jobs that were submitted
+   to the device from other sources than the IPP Printer object in the
+   same way that the Pause-Printer operation affects jobs that were
+   submitted to the IPP Printer object using IPP, depends on
+   implementation, i.e., on whether the IPP protocol is being used as a
+   universal management protocol or just to manage IPP jobs,
+   respectively.
+
+   The IPP Printer MUST accept the request in any state and transition
+   the Printer to the indicated new "printer-state" before returning as
+   follows:
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 58]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+     Current        New      "printer   IPP Printer's response status
+    "printer-    "printer-   -state-          code and action:
+     state"       state"    reasons"
+
+  'idle'       'stopped'    'paused'  'successful-ok'
+  'processing' 'processing' 'moving-  OPTION 1: 'successful-ok';
+                              to-       Later, when all output has
+                              paused'   stopped, the "printer-state"
+                                        becomes 'stopped', and the
+                                        'paused' value replaces the
+                                        'moving-to-paused' value in the
+                                        "printer-state-reasons"
+                                        attribute
+  'processing' 'stopped'    'paused'  OPTION 2: 'successful-ok';
+                                        all device output stopped
+                                        immediately
+  'stopped'    'stopped'    'paused'  'successful-ok'
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must be an operator or administrator of the Printer
+   object (see Sections 1 and 8.5).   Otherwise, the IPP Printer MUST
+   reject the operation and return:  'client-error-forbidden', 'client-
+   error-not-authenticated', or 'client-error-not-authorized' as
+   appropriate.
+
+3.2.7.1 Pause-Printer Request
+
+   The following groups of attributes are part of the Pause-Printer
+   Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.
+
+      Target:
+        The "printer-uri" (uri) operation attribute which is the target
+        for this operation as described in section 3.1.5.
+
+      Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 59]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.2.7.2 Pause-Printer Response
+
+   The following groups of attributes are part of the Pause-Printer
+   Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+        In addition to the REQUIRED status code returned in every
+        response, the response OPTIONALLY includes a "status-message"
+        (text(255)) and/or a "detailed-status-message" (text(MAX))
+        operation attribute as described in sections 13 and  3.1.6.
+
+      Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See section 3.1.7 for details on returning Unsupported Attributes.
+
+3.2.8 Resume-Printer Operation
+
+   This operation allows a client to resume the Printer object
+   scheduling jobs on all its devices.  The Printer object MUST remove
+   the 'paused' and 'moving-to-paused' values from the Printer object's
+   "printer-state-reasons" attribute, if present.  If there are no other
+   reasons to keep a device paused (such as media-jam), the IPP Printer
+   is free to transition itself to the 'processing' or 'idle' states,
+   depending on whether there are jobs to be processed or not,
+   respectively, and the device(s) resume processing jobs.
+
+   If the Pause-Printer operation is supported, then the Resume-Printer
+   operation MUST be supported, and vice-versa.
+
+   The IPP Printer removes the 'printer-stopped' value from any job's
+   "job-state-reasons" attributes contained in that Printer.
+
+   The IPP Printer MUST accept the request in any state, transition the
+   Printer object to the indicated new state as follows:
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 60]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+     Current    New "printer-  IPP Printer's response status code and
+    "printer-      state"                     action:
+      state"
+
+   'idle'       'idle'         'successful-ok'
+   'processing' 'processing'   'successful-ok'
+
+   'stopped'    'processing'   'successful-ok';
+                               when there are jobs to be processed
+   'stopped'    'idle'         'successful-ok';
+                               when there are no jobs to be processed.
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must be an operator or administrator of the Printer
+   object (see Sections 1 and 8.5).  Otherwise, the IPP Printer MUST
+   reject the operation and return:  'client-error-forbidden', 'client-
+   error-not-authenticated', or 'client-error-not-authorized' as
+   appropriate.
+
+   The Resume-Printer Request and Resume-Printer Response have the same
+   attribute groups and attributes as the Pause-Printer operation (see
+   sections 3.2.7.1 and 3.2.7.2).
+
+3.2.9 Purge-Jobs Operation
+
+   This OPTIONAL operation allows a client to remove all jobs from an
+   IPP Printer object, regardless of their job states, including jobs in
+   the Printer object's Job History (see Section 4.3.7.2).  After a
+   Purge-Jobs operation has been performed, a Printer object MUST return
+   no jobs in subsequent Get-Job-Attributes and Get-Jobs responses
+   (until new jobs are submitted).
+
+   Whether the Purge-Jobs (and Get-Jobs) operation affects jobs that
+   were submitted to the device from other sources than the IPP Printer
+   object in the same way that the Purge-Jobs operation affects jobs
+   that were submitted to the IPP Printer object using IPP, depends on
+   implementation, i.e., on whether the IPP protocol is being used as a
+   universal management protocol or just to manage IPP jobs,
+   respectively.
+
+   Note:  if an operator wants to cancel all jobs without clearing out
+   the Job History, the operator uses the Cancel-Job operation on each
+   job instead of using the Purge-Jobs operation.
+
+   The Printer object MUST accept this operation in any state and
+   transition the Printer object to the 'idle' state.
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 61]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must be an operator or administrator of the Printer
+   object (see Sections 1 and 8.5).  Otherwise, the IPP object MUST
+   reject the operation and return: client-error-forbidden, client-
+   error-not-authenticated, and client-error-not-authorized as
+   appropriate.
+
+   The Purge-Jobs Request and Purge-Jobs Response have the same
+   attribute groups and attributes as the Pause-Printer operation (see
+   sections 3.2.7.1 and 3.2.7.2).
+
+3.3 Job Operations
+
+   All Job operations are directed at Job objects.  A client MUST always
+   supply some means of identifying the Job object in order to identify
+   the correct target of the operation.  That job identification MAY
+   either be a single Job URI or a combination of a Printer URI with a
+   Job ID.  The IPP object implementation MUST support both forms of
+   identification for every job.
+
+3.3.1 Send-Document Operation
+
+   This OPTIONAL operation allows a client to create a multi-document
+   Job object that is initially "empty" (contains no documents).  In the
+   Create-Job response, the Printer object returns the Job object's URI
+   (the "job-uri" attribute) and the Job object's 32-bit identifier (the
+   "job-id" attribute).  For each new document that the client desires
+   to add, the client uses a Send-Document operation.  Each Send-
+   Document Request contains the entire stream of document data for one
+   document.
+
+   If the Printer supports this operation but does not support multiple
+   documents per job, the Printer MUST reject subsequent Send-Document
+   operations supplied with data and return the 'server-error-multiple-
+   document-jobs-not-supported'.  However, the Printer MUST accept the
+   first document with a 'true' or 'false' value for the "last-document"
+   operation attribute (see below), so that clients MAY always submit
+   one document jobs with a 'false' value for "last-document" in the
+   first Send-Document and a 'true' for "last-document" in the second
+   Send-Document (with no data).
+
+   Since the Create-Job and the send operations (Send-Document or Send-
+   URI operations) that follow could occur over an arbitrarily long
+   period of time for a particular job, a client MUST send another send
+   operation within an IPP Printer defined minimum time interval after
+   the receipt of the previous request for the job.  If a Printer object
+   supports the Create-Job and Send-Document operations, the Printer
+   object MUST support the "multiple-operation-time-out" attribute (see
+
+
+
+Hastings, et al.            Standards Track                    [Page 62]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   section 4.4.31).  This attribute indicates the minimum number of
+   seconds the Printer object will wait for the next send operation
+   before taking some recovery action.
+
+   An IPP object MUST recover from an errant client that does not supply
+   a send operation, sometime after the minimum time interval specified
+   by the Printer object's "multiple-operation-time-out" attribute.
+   Such recovery MAY include any of the following or other recovery
+   actions:
+
+      1. Assume that the Job is an invalid job, start the process of
+         changing the job state to 'aborted', add the 'aborted-by-
+         system' value to the job's "job-state-reasons" attribute (see
+         section 4.3.8), and clean up all resources associated with the
+         Job.  In this case, if another send operation is finally
+         received, the Printer responds with an "client-error-not-
+         possible" or "client-error-not-found" depending on whether or
+         not the Job object is still around when the send operation
+         finally arrives.
+      2. Assume that the last send operation received was in fact the
+         last document (as if the "last-document" flag had been set to
+         'true'), close the Job object, and proceed to process it (i.e.,
+         move the Job's state to 'pending').
+      3. Assume that the last send operation received was in fact the
+         last document, close the Job, but move it to the 'pending-held'
+         and add the 'submission-interrupted' value to the job's "job-
+         state-reasons" attribute (see section 4.3.8).  This action
+         allows the user or an operator to determine whether to continue
+         processing the Job by moving it back to the 'pending' state
+         using the Release-Job operation (see section 3.3.6) or to
+         cancel the job using the Cancel-Job operation (see section
+         3.3.3).
+
+   Each implementation is free to decide the "best" action to take
+   depending on local policy, whether any documents have been added,
+   whether the implementation spools jobs or not,  and/or any other
+   piece of information available to it.  If the choice is to abort the
+   Job object, it is possible that the Job object may already have been
+   processed to the point that some media sheet pages have been printed.
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must either be the job owner (as determined in the
+   Create-Job operation) or an operator or administrator of the Printer
+   object (see Sections 1 and 8.5).  Otherwise, the IPP object MUST
+   reject the operation and return: 'client-error-forbidden', 'client-
+   error-not-authenticated', or 'client-error-not-authorized' as
+   appropriate.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 63]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.3.1.1 Send-Document Request
+
+   The following attribute sets are part of the Send-Document Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.
+
+      Target:
+        Either (1) the "printer-uri" (uri) plus "job-id"
+        (integer(1:MAX))or (2) the "job-uri" (uri) operation
+        attribute(s) which define the target for this operation as
+        described in section 3.1.5.
+
+      Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+      "document-name" (name(MAX)):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object MUST support this attribute.  It contains the client
+        supplied document name.  The document name MAY be different than
+        the Job name.  It might be helpful, but NEED NOT be unique
+        across multiple documents in the same Job.  Typically, the
+        client software automatically supplies the document name on
+        behalf of the end user by using a file name or an application
+        generated name.  See the description of the "document-name"
+        operation attribute in the Print-Job Request (section 3.2.1.1)
+        for more information about this attribute.
+
+      "compression" (type3 keyword):
+        See the description of "compression" for the Print-Job operation
+        in Section 3.2.1.1.
+
+      "document-format" (mimeMediaType):
+        See the description of "document-format" for the Print-Job
+        operation in Section 3.2.1.1.
+
+      "document-natural-language" (naturalLanguage):
+        The client OPTIONALLY supplies this attribute.  The Printer
+        object OPTIONALLY supports this attribute.  This attribute
+        specifies the natural language of the document for those
+        document-formats that require a specification of the natural
+        language in order to image the document unambiguously.  There
+        are no particular values required for the Printer object to
+        support.
+
+
+
+Hastings, et al.            Standards Track                    [Page 64]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      "last-document" (boolean):
+        The client MUST supply this attribute.  The Printer object MUST
+        support this attribute. It is a boolean flag that is set to
+        'true' if this is the last document for the Job, 'false'
+        otherwise.
+
+   Group 2: Document Content
+
+      The client MUST supply the document data if the "last-document"
+      flag is set to 'false'.  However, since a client might not know
+      that the previous document sent with a Send-Document (or Send-URI)
+      operation was the last document (i.e., the "last-document"
+      attribute was set to 'false'), it is legal to send a Send-Document
+      request with no document data where the "last-document" flag is
+      set to 'true'.  Such a request MUST NOT increment the value of the
+      Job object's "number-of-documents" attribute, since no real
+      document was added to the job.  It is not an error for a client to
+      submit a job with no actual document data, i.e., only a single
+      Create-Job and Send-Document request with a "last-document"
+      operation attribute set to 'true' with no document data.
+
+3.3.1.2 Send-Document Response
+
+   The following sets of attributes are part of the Send-Document
+   Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+         In addition to the REQUIRED status code returned in every
+         response, the response OPTIONALLY includes a "status-message"
+         (text(255)) and/or a "detailed-status-message" (text(MAX))
+         operation attribute as described in sections 13 and 3.1.6.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See section 3.1.7 for details on returning Unsupported Attributes.
+
+   Group 3: Job Object Attributes
+
+      This is the same set of attributes as described in the Print-Job
+      response (see section 3.2.1.2).
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 65]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.3.2 Send-URI Operation
+
+   This OPTIONAL operation is identical to the Send-Document operation
+   (see section 3.3.1) except that a client MUST supply a URI reference
+   ("document-uri" operation attribute) rather than the document data
+   itself.  If a Printer object supports this operation, clients can use
+   both Send-URI or Send-Document operations to add new documents to an
+   existing multi-document Job object.  However, if a client needs to
+   indicate that the previous Send-URI or Send-Document was the last
+   document,  the client MUST use the Send-Document operation with no
+   document data and the "last-document" flag set to 'true' (rather than
+   using a Send-URI operation with no "document-uri" operation
+   attribute).
+
+   If a Printer object supports this operation, it MUST also support the
+   Print-URI operation (see section 3.2.2).
+
+   The Printer object MUST validate the syntax and URI scheme of the
+   supplied URI before returning a response, just as in the Print-URI
+   operation.  The IPP Printer MAY validate the accessibility of the
+   document as part of the operation or subsequently (see section
+   3.2.2).
+
+3.3.3 Cancel-Job Operation
+
+   This REQUIRED operation allows a client to cancel a Print Job from
+   the time the job is created up to the time it is completed, canceled,
+   or aborted.  Since a Job might already be printing by the time a
+   Cancel-Job is received, some media sheet pages might be printed
+   before the job is actually terminated.
+
+   The IPP object MUST accept or reject the request based on the job's
+   current state and transition the job to the indicated new state as
+   follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 66]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+       Current "job-    New "job-     IPP object's response status
+           state"         state"             code and action:
+
+      'pending'       'canceled'     'successful-ok'
+      'pending-held'  'canceled'     'successful-ok'
+      'processing'    'canceled'     'successful-ok'
+      'processing'    'processing'   'successful-ok'  See Rule 1
+      'processing'    'processing'   'client-error-not-possible'
+                                     See Rule 2
+      'processing-    'canceled'     'successful-ok'
+      stopped'
+      'processing-    'processing-   'successful-ok'  See Rule 1
+      stopped'        stopped'
+      'processing-    'processing-   'client-error-not-possible'
+      stopped'        stopped'       See Rule 2
+      'completed'     'completed'    'client-error-not-possible'
+      'canceled'      'canceled'     'client-error-not-possible'
+      'aborted'       'aborted'      'client-error-not-possible'
+
+   Rule 1:  If the implementation requires some measurable time to
+   cancel the job in the 'processing' or 'processing-stopped' job
+   states, the IPP object MUST add the 'processing-to-stop-point' value
+   to the job's "job-state-reasons" attribute and then transition the
+   job to the 'canceled' state when the processing ceases (see section
+   4.3.8).
+
+   Rule 2:  If the Job object already has the 'processing-to-stop-point'
+   value in its "job-state-reasons" attribute, then the Printer object
+   MUST reject a Cancel-Job operation.
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must either be the job owner or an operator or
+   administrator of the Printer object (see Sections 1 and 8.5).
+   Otherwise, the IPP object MUST reject the operation and return:
+    'client-error-forbidden', 'client-error-not-authenticated', or
+   'client-error-not-authorized' as appropriate.
+
+3.3.3.1 Cancel-Job Request
+
+   The following groups of attributes are part of the Cancel-Job
+   Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.1.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 67]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      Target:
+         Either (1) the "printer-uri" (uri) plus "job-id"
+         (integer(1:MAX))or (2) the "job-uri" (uri) operation
+         attribute(s) which define the target for this operation as
+         described in section 3.1.5.
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client as described in section 8.3.
+
+      "message" (text(127)):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object OPTIONALLY supports this attribute. It is a message to
+         the operator.  This "message" attribute is not the same as the
+         "job-message-from-operator" attribute.  That attribute is used
+         to report a message from the operator to the end user that
+         queries that attribute.  This "message" operation attribute is
+         used to send a message from the client to the operator along
+         with the operation request.  It is an implementation decision
+         of how or where to display this message to the operator (if at
+         all).
+
+3.3.3.2 Cancel-Job Response
+
+   The following sets of attributes are part of the Cancel-Job Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+         In addition to the REQUIRED status code returned in every
+         response, the response OPTIONALLY includes a "status-message"
+         (text(255)) and/or a "detailed-status-message" (text(MAX))
+         operation attribute as described in sections 13 and 3.1.6.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See section 3.1.7 for details on returning Unsupported Attributes.
+
+   Once a successful response has been sent, the implementation
+   guarantees that the Job will eventually end up in the 'canceled'
+   state. Between the time of the Cancel-Job operation is accepted and
+   when the job enters the 'canceled' job-state (see section 4.3.7), the
+   "job-state-reasons" attribute SHOULD contain the 'processing-to-
+   stop-point'
+
+
+
+Hastings, et al.            Standards Track                    [Page 68]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   value which indicates to later queries that although the Job might
+   still be 'processing', it will eventually end up in the
+   'canceled' state, not the 'completed' state.
+
+3.3.4 Get-Job-Attributes Operation
+
+   This REQUIRED operation allows a client to request the values of
+   attributes of a Job object and it is almost identical to the Get-
+   Printer-Attributes operation (see section 3.2.5).  The only
+   differences are that the operation is directed at a Job object rather
+   than a Printer object, there is no "document-format" operation
+   attribute used when querying a Job object, and the returned attribute
+   group is a set of Job object attributes rather than a set of Printer
+   object attributes.
+
+   For Jobs, the possible names of attribute groups are:
+
+      - 'job-template': the subset of the Job Template attributes that
+        apply to a Job object (the first column of the table in Section
+        4.2) that the implementation supports for Job objects.
+      - 'job-description': the subset of the Job Description attributes
+        specified in Section 4.3 that the implementation supports for
+        Job objects.
+      - 'all': the special group 'all' that includes all attributes that
+        the implementation supports for Job objects.
+
+   Since a client MAY request specific attributes or named groups, there
+   is a potential that there is some overlap.  For example, if a client
+   requests, 'job-name' and 'job-description', the client is actually
+   requesting the "job-name" attribute once by naming it explicitly, and
+   once by inclusion in the 'job-description' group.  In such cases, the
+   Printer object NEED NOT return the attribute only once in the
+   response even if it is requested multiple times.  The client SHOULD
+   NOT request the same attribute in multiple ways.
+
+   It is NOT REQUIRED that a Job object support all attributes belonging
+   to a group (since some attributes are OPTIONAL).  However it is
+   REQUIRED that each Job object support all these group names.
+
+3.3.4.1 Get-Job-Attributes Request
+
+   The following groups of attributes are part of the Get-Job-Attributes
+   Request when the request is directed at a Job object:
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 69]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+        The "attributes-charset" and "attributes-natural-language"
+        attributes as described in section 3.1.4.1.
+
+      Target:
+        Either (1) the "printer-uri" (uri) plus "job-id"
+        (integer(1:MAX)) or (2) the "job-uri" (uri) operation
+        attribute(s) which define the target for this operation as
+        described in section 3.1.5.
+
+      Requesting User Name:
+        The "requesting-user-name" (name(MAX)) attribute SHOULD be
+        supplied by the client as described in section 8.3.
+
+      "requested-attributes" (1setOf keyword):
+        The client OPTIONALLY supplies this attribute.  The IPP object
+        MUST support this attribute.   It is a set of attribute names
+        and/or attribute group names in whose values the requester is
+        interested.  If the client omits this attribute, the IPP object
+        MUST respond as if this attribute had been supplied with a value
+        of 'all'.
+
+3.3.4.2 Get-Job-Attributes Response
+
+   The Printer object returns the following sets of attributes as part
+   of the Get-Job-Attributes Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+         In addition to the REQUIRED status code returned in every
+         response, the response OPTIONALLY includes a "status-message"
+         (text(255)) and/or a "detailed-status-message" (text(MAX))
+         operation attribute as described in sections 13 and 3.1.6.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in section 3.1.4.2.  The "attributes-
+         natural-language" MAY be the natural language of the Job
+         object, rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+      See section 3.1.7 for details on returning Unsupported Attributes.
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 70]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      The response NEED NOT contain the "requested-attributes" operation
+      attribute with any supplied values (attribute keywords) that were
+      requested by the client but are not supported by the IPP object.
+      If the Printer object does return unsupported attributes
+      referenced in the "requested-attributes" operation attribute and
+      that attribute included group names, such as 'all', the
+      unsupported attributes MUST NOT include attributes described in
+      the standard but not supported by the implementation.
+
+   Group 3: Job Object Attributes
+
+      This is the set of requested attributes and their current values.
+      The IPP object ignores (does not respond with) any requested
+      attribute or value which is not supported or which is restricted
+      by the security policy in force, including whether the requesting
+      user is the user that submitted the job (job originating user) or
+      not (see section 8).  However, the IPP object MUST respond with
+      the 'unknown' value for any supported attribute (including all
+      REQUIRED attributes) for which the IPP object does not know the
+      value, unless it would violate the security policy.  See the
+      description of the "out-of-band" values in the beginning of
+      Section 4.1.
+
+3.3.5 Hold-Job Operation
+
+   This OPTIONAL operation allows a client to hold a pending job in the
+   queue so that it is not eligible for scheduling.  If the Hold-Job
+   operation is supported, then the Release-Job operation MUST be
+   supported, and vice-versa.  The OPTIONAL "job-hold-until" operation
+   attribute allows a client to specify whether to hold the job
+   indefinitely or until a specified time period, if supported.
+
+   The IPP object MUST accept or reject the request based on the job's
+   current state and transition the job to the indicated new state as
+   follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 71]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+        Current "job-     New "job-state"   IPP object's response status
+            state"                                 code and action:
+
+      'pending'         'pending-held'     'successful-ok'  See Rule 1
+      'pending'         'pending'          'successful-ok'  See Rule 2
+      'pending-held'    'pending-held'     'successful-ok'  See Rule 1
+      'pending-held'    'pending'          'successful-ok'  See Rule 2
+      'processing'      'processing'       'client-error-not-possible'
+      'processing-      'processing-       'client-error-not-possible'
+      stopped'          stopped'
+      'completed'       'completed'        'client-error-not-possible'
+      'canceled'        'canceled'         'client-error-not-possible'
+      'aborted'         'aborted'          'client-error-not-possible'
+
+   Rule 1:  If the implementation supports multiple reasons for a job to
+   be in the 'pending-held' state, the IPP object MUST add the 'job-
+   hold-until-specified' value to the job's "job-state-reasons"
+   attribute.
+
+   Rule 2:  If the IPP object supports the "job-hold-until" operation
+   attribute, but the specified time period has already started (or is
+   the 'no-hold' value) and there are no other reasons to hold the job,
+   the IPP object MUST make the job be a candidate for processing
+   immediately (see Section 4.2.2) by putting the job in the 'pending'
+   state.
+
+   Note:  In order to keep the Hold-Job operation simple, such a request
+   is rejected when the job is in the 'processing' or 'processing-
+   stopped' states.  If an operation is needed to hold jobs while in
+   these states, it will be added as an additional operation, rather
+   than overloading the Hold-Job operation.  Then it is clear to clients
+   by querying the Printer object's "operations-supported" (see Section
+   4.4.15) and the Job object's "job-state" (see Section 4.3.7)
+   attributes which operations are possible.
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must either be the job owner or an operator or
+   administrator of the Printer object (see Sections 1 and 8.5).
+   Otherwise, the IPP object MUST reject the operation and return:
+   'client-error-forbidden', 'client-error-not-authenticated', or
+   'client-error-not-authorized' as appropriate.
+
+3.3.5.1 Hold-Job Request
+
+   The groups and operation attributes are the same as for a Cancel-Job
+   request (see section 3.3.3.1), with the addition of the following
+   Group 1 Operation attribute:
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 72]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      "job-hold-until" (type3 keyword | name(MAX)):
+         The client OPTIONALLY supplies this Operation attribute.  The
+         IPP object MUST support this operation attribute in a Hold-Job
+         request, if it supports the "job-hold-until" Job template
+         attribute in create operations.  See section 4.2.2.  The IPP
+         object SHOULD support the "job-hold-until" Job Template
+         attribute for use in job create operations with at least the
+         'indefinite' value, if it supports the Hold-Job operation.
+         Otherwise, a client cannot create a job and hold it immediately
+         (without picking some supported time period in the future).
+
+         If supplied and supported as specified in the Printer's "job-
+         hold-until-supported" attribute, the IPP object copies the
+         supplied operation attribute to the Job object, replacing the
+         job's previous "job-hold-until" attribute, if present, and
+         makes the job a candidate for scheduling during the supplied
+         named time period.
+
+         If supplied, but either the "job-hold-until" Operation
+         attribute itself or the value supplied is not supported, the
+         IPP object accepts the request, returns the unsupported
+         attribute or value in the Unsupported Attributes Group
+         according to section 3.1.7, returns the 'successful-ok-
+         ignored-or-substituted-attributes, and holds the job
+         indefinitely until a client performs a subsequent Release-Job
+         operation.
+
+         If the client (1) supplies a value that specifies a time period
+         that has already started or the 'no-hold' value (meaning don't
+         hold the job) and (2) the IPP object supports the "job-hold-
+         until" operation attribute and there are no other reasons to
+         hold the job, the IPP object MUST accept the operation and make
+         the job be a candidate for processing immediately (see Section
+         4.2.2).
+
+         If the client does not supply a "job-hold-until" Operation
+         attribute in the request, the IPP object MUST populate the job
+         object with a "job-hold-until" attribute with the 'indefinite'
+         value (if IPP object supports the "job-hold-until" attribute)
+         and hold the job indefinitely, until a client performs a
+         Release-Job operation.
+
+3.3.5.2 Hold-Job Response
+
+   The groups and attributes are the same as for a Cancel-Job response
+   (see section 3.3.3.2).
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 73]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.3.6 Release-Job Operation
+
+   This OPTIONAL operation allows a client to release a previously held
+   job so that it is again eligible for scheduling.  If the Hold-Job
+   operation is supported, then the Release-Job operation MUST be
+   supported, and vice-versa.
+
+   This operation removes the "job-hold-until" job attribute, if
+   present, from the job object that had been supplied in the create or
+   most recent Hold-Job or Restart-Job operation and removes its effect
+   on the job.  The IPP object MUST remove the 'job-hold-until-
+   specified' value from the job's "job-state-reasons" attribute, if
+   present.  See section 4.3.8.
+
+   The IPP object MUST accept or reject the request based on the job's
+   current state and transition the job to the indicated new state as
+   follows:
+
+        Current "job-   New "job-state"    IPP object's response status
+           state"                                code and action:
+
+      'pending'        'pending'        'successful-ok'
+                                         No effect on the job.
+      'pending-held'   'pending-held'   'successful-ok'  See Rule 1
+      'pending-held'   'pending'        'successful-ok'
+      'processing'     'processing'     'successful-ok'
+                                         No effect on the job.
+      'processing-     'processing-     'successful-ok'
+       stopped'         stopped'         No effect on the job.
+      'completed'      'completed'      'client-error-not-possible'
+      'canceled'       'canceled'       'client-error-not-possible'
+      'aborted'        'aborted'        'client-error-not-possible'
+
+   Rule 1:  If there are other reasons to keep the job in the 'pending-
+   held' state, such as 'resources-are-not-ready', the job remains in
+   the 'pending-held' state.  Thus the 'pending-held' state is not just
+   for jobs that have the 'job-hold-until' applied to them, but are for
+   any reason to keep the job from being a candidate for scheduling and
+   processing, such as 'resources-are-not-ready'.  See the "job-hold-
+   until" attribute (section 4.2.2).
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must either be the job owner or an operator or
+   administrator of the Printer object (see Sections 1 and 8.5).
+   Otherwise, the IPP object MUST reject the operation and return:
+   'client-error-forbidden', 'client-error-not-authenticated', or
+   'client-error-not-authorized' as appropriate.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 74]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The Release-Job Request and Release-Job Response have the same
+   attribute groups and attributes as the Cancel-Job operation (see
+   section 3.3.3.1 and 3.3.3.2).
+
+3.3.7 Restart-Job Operation
+
+   This OPTIONAL operation allows a client to restart a job that is
+   retained in the queue after processing has completed (see section
+   4.3.7.2).
+
+   The job is moved to the 'pending' or 'pending-held' job state and
+   restarts at the beginning on the same IPP Printer object with the
+   same attribute values.  If any of the documents in the job were
+   passed by reference (Print-URI or Send-URI), the Printer MUST re-
+   fetch the data, since the semantics of Restart-Job are to repeat all
+   Job processing.  The Job Description attributes that accumulate job
+   progress, such as "job-impressions-completed", "job-media-sheets-
+   completed", and "job-k-octets-processed", MUST be reset to 0 so that
+   they give an accurate record of the job from its restart point.  The
+   job object MUST continue to use the same "job-uri" and "job-id"
+   attribute values.
+
+   Note:  If in the future an operation is needed that does not reset
+   the job progress attributes, then a new operation will be defined
+   which makes a copy of the job, assigns a new "job-uri" and "job-id"
+   to the copy and resets the job progress attributes in the new copy
+   only.
+
+   The IPP object MUST accept or reject the request based on the job's
+   current state, transition the job to the indicated new state as
+   follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 75]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+        Current "job-   New "job-state"    IPP object's response status
+           state"                                code and action:
+
+      'pending'        'pending'        'client-error-not-possible'
+      'pending-held'   'pending-held'   'client-error-not-possible'
+      'processing'     'processing'     'client-error-not-possible'
+      'processing-     'processing-     'client-error-not-possible'
+      stopped'         stopped'
+      'completed'      'pending' or     'successful-ok' - job is started
+                        'pending-held'   over.
+      'completed'      'completed'      'client-error-not-possible' -
+                                         see Rule 1
+      'canceled'       'pending' or     'successful-ok' - job is started
+                        'pending-held'   over.
+      'canceled'       'canceled'       'client-error-not-possible' -
+                                         see Rule 1
+      'aborted'        'pending' or     'successful-ok' - job is started
+                        'pending-held'   over.
+      'aborted'        'aborted'        'client-error-not-possible' -
+                                         see Rule 1
+
+   Rule 1:  If the Job Retention Period has expired for the job in this
+   state, then the IPP object rejects the operation.  See section
+   4.3.7.2.
+
+   Note:  In order to prevent a user from inadvertently restarting a job
+   in the middle, the Restart-Job request is rejected when the job is in
+   the 'processing' or 'processing-stopped' states.  If in the future an
+   operation is needed to hold or restart jobs while in these states, it
+   will be added as an additional operation, rather than overloading the
+   Restart-Job operation, so that it is clear that the user intended
+   that the current job not be completed.
+
+   Access Rights: The authenticated user (see section 8.3) performing
+   this operation must either be the job owner or an operator or
+   administrator of the Printer object (see Sections 1 and 8.5).
+   Otherwise, the IPP object MUST reject the operation and return:
+   'client-error-forbidden', 'client-error-not-authenticated', or
+   'client-error-not-authorized' as appropriate.
+
+3.3.7.1 Restart-Job Request
+
+   The groups and attributes are the same as for a Cancel-Job request
+   (see section 3.3.3.1), with the addition of the following Group 1
+   Operation attribute:
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 76]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      "job-hold-until" (type3 keyword | name(MAX)):
+         The client OPTIONALLY supplies this attribute.  The IPP object
+         MUST support this Operation attribute in a Restart-Job request,
+         if it supports the "job-hold-until" Job Template attribute in
+         create operations.  See section 4.2.2.  Otherwise, the IPP
+         object NEED NOT support the "job-hold-until" Operation
+         attribute in a Restart-Job request.
+
+         If supplied and supported as specified in the Printer's "job-
+         hold-until-supported" attribute, the IPP object copies the
+         supplied Operation attribute to the Job object, replacing the
+         job's previous "job-hold-until" attribute, if present, and
+         makes the job a candidate for scheduling during the supplied
+         named time period.  See section 4.2.2.
+
+         If supplied, but the value is not supported, the IPP object
+         accepts the request, returns the unsupported attribute or value
+         in the Unsupported Attributes Group according to section 3.1.7,
+         returns the 'successful-ok-ignored-or-substituted-attributes'
+         status code, and holds the job indefinitely until a client
+         performs a subsequent Release-Job operation.
+
+         If supplied, but the "job-hold-until" Operation attribute
+         itself is not supported, the IPP object accepts the request,
+         returns the unsupported attribute with the out-of-band
+         'unsupported' value in the Unsupported Attributes Group
+         according to section 3.1.7, returns the 'successful-ok-
+         ignored-or-substituted-attributes' status code, and restarts
+         the job, i.e., ignores the "job-hold-until" attribute.
+
+         If the client (1) supplies a value that specifies a time period
+         that has already started or the 'no-hold' value (meaning don't
+         hold the job) and (2) the IPP object supports the "job-hold-
+         until" operation attribute and there are no other reasons to
+         hold the job, the IPP object makes the job a candidate for
+         processing immediately (see Section 4.2.2).
+
+         If the client does not supply a "job-hold-until" operation
+         attribute in the request, the IPP object removes the "job-
+         hold-until" attribute, if present, from the job.  If there are
+         no other reasons to hold the job, the Restart-Job operation
+         makes the job a candidate for processing immediately (see
+         Section 4.2.2).
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 77]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+3.3.7.2 Restart-Job Response
+
+   The groups and attributes are the same as for a Cancel-Job response
+   (see section 3.3.3.2).
+
+   Note:  In the future an OPTIONAL Modify-Job or Set-Job-Attributes
+   operation may be specified that allows the client to modify other
+   attributes before releasing the restarted job.
+
+4. Object Attributes
+
+   This section describes the attributes with their corresponding
+   attribute syntaxes and values that are part of the IPP model.  The
+   sections below show the objects and their associated attributes which
+   are included within the scope of this protocol.  Many of these
+   attributes are derived from other relevant documents:
+
+      - Document Printing Application (DPA) [ISO10175]
+      - RFC 1759 Printer MIB [RFC1759]
+
+   Each attribute is uniquely identified in this document using a
+   "keyword" (see section 12.2.1) which is the name of the attribute.
+   The keyword is included in the section header describing that
+   attribute.
+
+   Note:  Not only are keywords used to identify attributes, but one of
+   the attribute syntaxes described below is "keyword" so that some
+   attributes have keyword values.  Therefore, these attributes are
+   defined as having an attribute syntax that is a set of keywords.
+
+4.1 Attribute Syntaxes
+
+   This section defines the basic attribute syntax types that all
+   clients and IPP objects MUST be able to accept in responses and
+   accept in requests, respectively.  Each attribute description in
+   sections 3 and 4 includes the name of attribute syntax(es) in the
+   heading (in parentheses).  A conforming implementation of an
+   attribute MUST include the semantics of the attribute syntax(es) so
+   identified.  Section 6.3 describes how the protocol can be extended
+   with new attribute syntaxes.
+
+   The attribute syntaxes are specified in the following sub-sections,
+   where the sub-section heading is the keyword name of the attribute
+   syntax inside the single quotes.  In operation requests and responses
+   each attribute value MUST be represented as one of the attribute
+   syntaxes specified in the sub-section heading for the attribute.  In
+   addition, the value of an attribute in a response (but not in a
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 78]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   request) MAY be one of the "out-of-band" values whose special
+   encoding rules are defined in the "Encoding and Transport" document
+   [RFC2910].   Standard "out-of-band" values are:
+
+      'unknown': The attribute is supported by the IPP object, but the
+         value is unknown to the IPP object for some reason.
+      'unsupported': The attribute is unsupported by the IPP object.
+         This value MUST be returned only as the value of an attribute
+         in the Unsupported Attributes Group.
+      'no-value': The attribute is supported by the Printer object, but
+         the administrator has not yet configured a value.
+
+   All attributes in a request MUST have one or more values as defined
+   in Sections 4.2 to 4.4.  Thus clients MUST NOT supply attributes with
+   "out-of-band" values for operations defined in this document.  All
+   attributes in a response MUST have one or more values as defined in
+   Sections 4.2 to 4.4 or a single "out-of-band" value.
+
+   Most attributes are defined to have a single attribute syntax.
+   However, a few attributes (e.g., "job-sheet", "media", "job-hold-
+   until") are defined to have several attribute syntaxes, depending on
+   the value.  These multiple attribute syntaxes are separated by the
+   "|" character in the sub-section heading to indicate the choice.
+   Since each value MUST be tagged as to its attribute syntax in the
+   protocol, a single-valued attribute instance may have any one of its
+   attribute syntaxes and a multi-valued attribute instance may have a
+   mixture of its defined attribute syntaxes.
+
+4.1.1 'text'
+
+   A text attribute is an attribute whose value is a sequence of zero or
+   more characters encoded in a maximum of 1023 ('MAX') octets.  MAX is
+   the maximum length for each value of any text attribute.  However, if
+   an attribute will always contain values whose maximum length is much
+   less than MAX, the definition of that attribute will include a
+   qualifier that defines the maximum length for values of that
+   attribute.  For example:  the "printer-location" attribute is
+   specified as "printer-location (text(127))".  In this case, text
+   values for "printer-location" MUST NOT exceed 127 octets; if supplied
+   with a longer text string via some external interface (other than the
+   protocol), implementations are free to truncate to this shorter
+   length limitation.
+
+   In this document, all text attributes are defined using the 'text'
+   syntax.  However, 'text' is used only for brevity; the formal
+   interpretation of 'text' is: 'textWithoutLanguage |
+   textWithLanguage'.  That is, for any attribute defined in this
+   document using the 'text' attribute syntax, all IPP objects and
+
+
+
+Hastings, et al.            Standards Track                    [Page 79]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   clients MUST support both the 'textWithoutLanguage' and
+   'textWithLanguage' attribute syntaxes.  However, in actual usage and
+   protocol execution, objects and clients accept and return only one of
+   the two syntax per attribute.  The syntax 'text' never appears "on-
+   the-wire".
+
+   Both 'textWithoutLanguage' and 'textWithLanguage' are needed to
+   support the real world needs of interoperability between sites and
+   systems that use different natural languages as the basis for human
+   communication.  Generally, one natural language applies to all text
+   attributes in a given request or response. The language is indicated
+   by the "attributes-natural-language" operation attribute defined in
+   section 3.1.4 or "attributes-natural-language" job attribute defined
+   in section 4.3.20, and there is no need to identify the natural
+   language for each text string on a value-by-value basis.  In these
+   cases, the attribute syntax 'textWithoutLanguage' is used for text
+   attributes.  In other cases, the client needs to supply or the
+   Printer object needs to return a text value in a natural language
+   that is different from the rest of the text values in the request or
+   response.  In these cases, the client or Printer object uses the
+   attribute syntax 'textWithLanguage' for text attributes (this is the
+   Natural Language Override mechanism described in section 3.1.4).
+
+   The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes
+   are described in more detail in the following sections.
+
+4.1.1.1 'textWithoutLanguage'
+
+   The 'textWithoutLanguage' syntax indicates a value that is sequence
+   of zero or more characters encoded in a maximum of 1023 (MAX) octets.
+   Text strings are encoded using the rules of some charset.  The
+   Printer object MUST support the UTF-8 charset [RFC2279] and MAY
+   support additional charsets to represent 'text' values, provided that
+   the charsets are registered with IANA [IANA-CS].  See Section 4.1.7
+   for the definition of the 'charset' attribute syntax, including
+   restricted semantics and examples of charsets.
+
+4.1.1.2 'textWithLanguage'
+
+   The 'textWithLanguage' attribute syntax is a compound attribute
+   syntax consisting of two parts: a 'textWithoutLanguage' part encoded
+   in a maximum of 1023 (MAX) octets plus an additional
+   'naturalLanguage' (see section 4.1.8) part that overrides the natural
+   language in force.  The 'naturalLanguage' part explicitly identifies
+   the natural language that applies to the text part of that value and
+   that value alone.  For any give text attribute, the
+   'textWithoutLanguage' part is limited to the maximum length defined
+   for that 'text' attribute, and the 'naturalLanguage' part is always
+
+
+
+Hastings, et al.            Standards Track                    [Page 80]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   limited to 63 (additional) octets.  Using the 'textWithLanguage'
+   attribute syntax rather than the normal 'textWithoutLanguage' syntax
+   is the so-called Natural Language Override mechanism and MUST be
+   supported by all IPP objects and clients.
+
+   If the attribute is multi-valued (1setOf text), then the
+   'textWithLanguage' attribute syntax MUST be used to explicitly
+   specify each attribute value whose natural language needs to be
+   overridden.  Other values in a multi-valued 'text' attribute in a
+   request or a response revert to the natural language of the operation
+   attribute.
+
+   In a create request, the Printer object MUST accept and store with
+   the Job object any natural language in the "attributes-natural-
+   language" operation attribute, whether the Printer object supports
+   that natural language or not.  Furthermore, the Printer object MUST
+   accept and store any 'textWithLanguage' attribute value, whether the
+   Printer object supports that natural language or not.  These
+   requirements are independent of the value of the "ipp-attribute-
+   fidelity" operation attribute that the client MAY supply.
+
+   Example:  If the client supplies the "attributes-natural-language"
+   operation attribute with the value: 'en' indicating English, but the
+   value of the "job-name" attribute is in French, the client MUST use
+   the 'textWithLanguage' attribute syntax with the following two
+   values:
+
+      'fr': Natural Language Override indicating French
+      'Rapport Mensuel': the job name in French
+
+   See the "Encoding and Transport" document [RFC2910] section 3.9 for
+   the encoding of the two parts and Appendix A for a detailed example
+   of the 'textWithLanguage' attribute syntax.
+
+4.1.2 'name'
+
+   This syntax type is used for user-friendly strings, such as a Printer
+   name, that, for humans, are more meaningful than identifiers.  Names
+   are never translated from one natural language to another.  The
+   'name' attribute syntax is essentially the same as 'text', including
+   the REQUIRED support of UTF-8 except that the sequence of characters
+   is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
+
+   Also like 'text', 'name' is really an abbreviated notation for either
+   'nameWithoutLanguage' or 'nameWithLanguage'.  That is, all IPP
+   objects and clients MUST support both the 'nameWithoutLanguage' and
+   'nameWithLanguage' attribute syntaxes.  However, in actual usage and
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 81]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   protocol execution, objects and clients accept and return only one of
+   the two syntax per attribute.  The syntax 'name' never appears "on-
+   the-wire".
+
+   Only the 'text' and 'name' attribute syntaxes permit the Natural
+   Language Override mechanism.
+
+   Some attributes are defined as 'type3 keyword | name'.  These
+   attributes support values that are either type3 keywords or names.
+   This dual-syntax mechanism enables a site administrator to extend
+   these attributes to legally include values that are locally defined
+   by the site administrator.  Such names are not registered with IANA.
+
+4.1.2.1 'nameWithoutLanguage'
+
+   The 'nameWithoutLanguage' syntax indicates a value that is sequence
+   of zero or more characters encoded in a maximum of 255 (MAX) octets.
+
+4.1.2.2 'nameWithLanguage'
+
+   The 'nameWithLanguage' attribute syntax is a compound attribute
+   syntax consisting of two parts: a 'nameWithoutLanguage' part encoded
+   in a maximum of 1023 (MAX) octets plus an additional
+   'naturalLanguage' (see section 4.1.8) part that overrides the natural
+   language in force.  The 'naturalLanguage' part explicitly identifies
+   the natural language that applies to that name value and that name
+   value alone.  For any give text attribute, the 'textWithoutLanguage'
+   part is limited to the maximum length defined for that 'text'
+   attribute, and the 'naturalLanguage' part is always limited to 63
+   (additional) octets.  Using the 'textWithLanguage' attribute syntax
+   rather than the normal 'textWithoutLanguage' syntax is the so-called
+   Natural Language Override mechanism and MUST be supported by all IPP
+   objects and clients.
+
+   The 'nameWithLanguage' attribute syntax behaves the same as the
+   'textWithLanguage' syntax.  Using the 'textWithLanguage' attribute
+   syntax rather than the normal 'textWithoutLanguage' syntax is the
+   so-called Natural Language Override mechanism and MUST be supported
+   by all IPP objects and clients.  If a name is in a language that is
+   different than the rest of the object or operation, then this
+   'nameWithLanguage' syntax is used rather than the generic
+   'nameWithoutLanguage' syntax.
+
+   If the attribute is multi-valued (1setOf text), then the
+   'nameWithLanguage' attribute syntax MUST be used to explicitly
+   specify each attribute value whose natural language needs to be
+   overridden.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 82]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Other values in a multi-valued 'name' attribute in a request or a
+   response revert to the natural language of the operation attribute.
+
+   In a create request, the Printer object MUST accept and store with
+   the Job object any natural language in the "attributes-natural-
+   language" operation attribute, whether the Printer object supports
+   that natural language or not.  Furthermore, the Printer object MUST
+   accept and store any 'nameWithLanguage' attribute value, whether the
+   Printer object supports that natural language or not.  These
+   requirements are independent of the value of the "ipp-attribute-
+   fidelity" operation attribute that the client MAY supply.
+
+   Example:  If the client supplies the "attributes-natural-language"
+   operation attribute with the value:  'en' indicating English, but the
+   "printer-name" attribute is in German, the client MUST use the
+   'nameWithLanguage' attribute syntax as follows:
+
+      'de':  Natural Language Override indicating German
+      'Farbdrucker':  the Printer name in German
+
+   See the "Encoding and Transport" document [RFC2910] section 3.9 for
+   the encoding of the two parts and Appendix A for a detailed example
+   of the 'nameWithLanguage' attribute syntax.
+
+4.1.2.3 Matching 'name' attribute values
+
+   For purposes of matching two 'name' attribute values for equality,
+   such as in job validation (where a client-supplied value for
+   attribute "xxx" is checked to see if the value is among the values of
+   the Printer object's corresponding "xxx-supported" attribute), the
+   following match rules apply:
+
+      1. 'keyword' values never match 'name' values.
+
+      2. 'name' (nameWithoutLanguage and nameWithLanguage) values match
+         if (1) the name parts match and (2) the Associated Natural-
+         Language parts (see section 3.1.4.1) match.  The matching rules
+         are:
+
+         a. the name parts match if the two names are identical
+            character by character, except it is RECOMMENDED that case
+            be ignored.  For example: 'Ajax-letter-head-white' MUST
+            match 'Ajax-letter-head-white' and SHOULD match 'ajax-
+            letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 83]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         b. the Associated Natural-Language parts match if the shorter
+            of the two meets the syntactic requirements of RFC 1766
+            [RFC1766] and matches byte for byte with the longer.  For
+            example, 'en' matches 'en', 'en-us' and 'en-gb', but matches
+            neither 'fr' nor 'e'.
+
+4.1.3 'keyword'
+
+   The 'keyword' attribute syntax is a sequence of characters, length: 1
+   to 255, containing only the US-ASCII [ASCII] encoded values for
+   lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot
+   ("."), and underscore ("_").  The first character MUST be a lowercase
+   letter.  Furthermore, keywords MUST be in U.S. English.
+
+   This syntax type is used for enumerating semantic identifiers of
+   entities in the abstract protocol, i.e., entities identified in this
+   document.  Keywords are used as attribute names or values of
+   attributes.  Unlike 'text' and 'name' attribute values, 'keyword'
+   values MUST NOT use the Natural Language Override mechanism, since
+   they MUST always be US-ASCII and U.S. English.
+
+   Keywords are for use in the protocol.  A user interface will likely
+   provide a mapping between protocol keywords and displayable user-
+   friendly words and phrases which are localized to the natural
+   language of the user.  While the keywords specified in this document
+   MAY be displayed to users whose natural language is U.S. English,
+   they MAY be mapped to other U.S. English words for U.S. English
+   users, since the user interface is outside the scope of this
+   document.
+
+   In the definition for each attribute of this syntax type, the full
+   set of defined keyword values for that attribute are listed.
+
+   When a keyword is used to represent an attribute (its name), it MUST
+   be unique within the full scope of all IPP objects and attributes.
+   When a keyword is used to represent a value of an attribute, it MUST
+   be unique just within the scope of that attribute.  That is, the same
+   keyword MUST NOT be used for two different values within the same
+   attribute to mean two different semantic ideas.  However, the same
+   keyword MAY be used across two or more attributes, representing
+   different semantic ideas for each attribute.  Section 6.1 describes
+   how the protocol can be extended with new keyword values.  Examples
+   of attribute name keywords:
+
+      "job-name"
+      "attributes-charset"
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 84]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Note:  This document uses "type1", "type2", and "type3" prefixes to
+   the "keyword" basic syntax to indicate different levels of review for
+   extensions (see section 6.1).
+
+4.1.4 'enum'
+
+   The 'enum' attribute syntax is an enumerated integer value that is in
+   the range from 1 to 2**31 - 1 (MAX).   Each value has an associated
+   'keyword' name.  In the definition for each attribute of this syntax
+   type, the full set of possible values for that attribute are listed.
+   This syntax type is used for attributes for which there are enum
+   values assigned by other standards, such as SNMP MIBs.  A number of
+   attribute enum values in this document are also used for
+   corresponding attributes in other standards [RFC1759].  This syntax
+   type is not used for attributes to which the administrator may assign
+   values.  Section 6.1 describes how the protocol can be extended with
+   new enum values.
+
+   Enum values are for use in the protocol.  A user interface will
+   provide a mapping between protocol enum values and displayable user-
+   friendly words and phrases which are localized to the natural
+   language of the user.  While the enum symbols specified in this
+   document MAY be displayed to users whose natural language is U.S.
+   English, they MAY be mapped to other U.S. English words for U.S.
+   English users, since the user interface is outside the scope of this
+   document.
+
+   Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP
+   "out-of-band" value 'unknown'.  See the description of the "out-of-
+   band" values at the beginning of Section 4.1.  Therefore, attributes
+   of type 'enum' start at '3'.
+
+   Note:  This document uses "type1", "type2", and "type3" prefixes to
+   the "enum" basic syntax to indicate different levels of review for
+   extensions (see section 6.1).
+
+4.1.5 'uri'
+
+   The 'uri' attribute syntax is any valid Uniform Resource Identifier
+   or URI [RFC2396].  Most often, URIs are simply Uniform Resource
+   Locators or URLs.  The maximum length of URIs used as values of IPP
+   attributes is 1023 octets.  Although most other IPP attribute syntax
+   types allow for only lower-cased values, this attribute syntax type
+   conforms to the case-sensitive and case-insensitive rules specified
+   in [RFC2396].  See also [IPP-IIG] for a discussion of case in URIs.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 85]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.1.6 'uriScheme'
+
+   The 'uriScheme' attribute syntax is a sequence of characters
+   representing a URI scheme according to RFC 2396 [RFC2396].  Though
+   RFC 2396 requires that the values be case-insensitive, IPP requires
+   all lower case values in IPP attributes to simplify comparing by IPP
+   clients and Printer objects.
+
+   Standard values for this syntax type are the following keywords:
+
+      'ipp':  for IPP schemed URIs (e.g., "ipp:...")
+      'http':  for HTTP schemed URIs (e.g., "http:...")
+      'https':  for use with HTTPS schemed URIs (e.g., "https:...") (not
+         on IETF standards track)
+      'ftp': for FTP schemed URIs (e.g., "ftp:...")
+      'mailto': for SMTP schemed URIs (e.g., "mailto:...")
+      'file': for file schemed URIs (e.g., "file:...")
+
+   A Printer object MAY support any URI 'scheme' that has been
+   registered with IANA [IANA-MT]. The maximum length of URI 'scheme'
+   values used to represent IPP attribute values is 63 octets.
+
+4.1.7 'charset'
+
+   The 'charset' attribute syntax is a standard identifier for a
+   charset.  A charset is a coded character set and encoding scheme.
+   Charsets are used for labeling certain document contents and 'text'
+   and 'name' attribute values.  The syntax and semantics of this
+   attribute syntax are specified in RFC 2046 [RFC2046] and contained in
+   the IANA character-set Registry [IANA-CS] according to the IANA
+   procedures [RFC2278].  Though RFC 2046 requires that the values be
+   case-insensitive US-ASCII [ASCII], IPP requires all lower case values
+   in IPP attributes to simplify comparing by IPP clients and Printer
+   objects.  When a character-set in the IANA registry has more than one
+   name (alias), the name labeled as "(preferred MIME name)", if
+   present, MUST be used.
+
+   The maximum length of 'charset' values used to represent IPP
+   attribute values is 63 octets.
+
+   Some examples are:
+
+      'utf-8':  ISO 10646 Universal Multiple-Octet Coded Character Set
+         (UCS) represented as the UTF-8 [RFC2279] transfer encoding
+         scheme in which US-ASCII is a subset charset.
+      'us-ascii':  7-bit American Standard Code for Information
+         Interchange (ASCII), ANSI X3.4-1986 [ASCII].  That standard
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 86]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the
+         control characters from conformant usage in MIME and IPP.
+      'iso-8859-1':  8-bit One-Byte Coded Character Set, Latin Alphabet
+         Nr 1 [ISO8859-1].  That standard defines a coded character set
+         that is used by Latin languages in the Western Hemisphere and
+         Western Europe.  US-ASCII is a subset charset.
+
+   Some attribute descriptions MAY place additional requirements on
+   charset values that may be used, such as REQUIRED values that MUST be
+   supported or additional restrictions, such as requiring that the
+   charset have US- ASCII as a subset charset.
+
+4.1.8 'naturalLanguage'
+
+   The 'naturalLanguage' attribute syntax is a standard identifier for a
+   natural language and optionally a country.  The values for this
+   syntax type are defined by RFC 1766 [RFC1766].  Though RFC 1766
+   requires that the values be case-insensitive US-ASCII [ASCII], IPP
+   requires all lower case to simplify comparing by IPP clients and
+   Printer objects.  Examples include:
+
+      'en':  for English
+      'en-us': for US English
+      'fr': for French
+      'de':  for German
+
+   The maximum length of 'naturalLanguage' values used to represent IPP
+   attribute values is 63 octets.
+
+4.1.9 'mimeMediaType'
+
+   The 'mimeMediaType' attribute syntax is the Internet Media Type
+   (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and
+   registered according to the procedures of RFC 2048 [RFC2048] for
+   identifying a document format.  The value MAY include a charset, or
+   other, parameter, depending on the specification of the Media Type in
+   the IANA Registry [IANA-MT].  Although most other IPP syntax types
+   allow for only lower-cased values, this syntax type allows for
+   mixed-case values which are case-insensitive.
+
+   Examples are:
+      'text/html': An HTML document
+      'text/plain': A plain text document in US-ASCII (RFC 2046
+         indicates that in the absence of the charset parameter MUST
+         mean US-ASCII rather than simply unspecified) [RFC2046].
+      'text/plain; charset=US-ASCII':  A plain text document in US-ASCII
+         [52, 56].
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 87]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      'text/plain; charset=ISO-8859-1':  A plain text document in ISO
+         8859-1 (Latin 1) [ISO8859-1].
+      'text/plain; charset=utf-8':  A plain text document in ISO 10646
+         represented as UTF-8 [RFC2279]
+      'application/postscript':  A PostScript document [RFC2046]
+      'application/vnd.hp-PCL':  A PCL document [IANA-MT] (charset
+         escape sequence embedded in the document data)
+      'application/pdf':  Portable Document Format - see IANA MIME Media
+         Type registry
+      'application/octet-stream': Auto-sense - see section 4.1.9.1
+
+   The maximum length of a 'mimeMediaType' value to represent IPP
+   attribute values is 255 octets.
+
+4.1.9.1 Application/octet-stream -- Auto-Sensing the document format
+
+   One special type is 'application/octet-stream'.  If the Printer
+   object supports this value, the Printer object MUST be capable of
+   auto-sensing the format of the document data using an
+   implementation-dependent method that examines some number of octets
+   of the document data, either as part of the create operation and/or
+   at document processing time.  During auto-sensing, a Printer may
+   determine that the document-data has a format that the Printer
+   doesn't recognize.  If the Printer determines this problem before
+   returning an operation response, it rejects the request and returns
+   the 'client-error-document-format-not-supported' status code.  If the
+   Printer determines this problem after accepting the request and
+   returning an operation response with one of the successful status
+   codes, the Printer adds the 'unsupported-document-format' value to
+   the job's "job-state-reasons" attribute.
+
+   If the Printer object's default value attribute "document-format-
+   default" is set to 'application/octet-stream', the Printer object not
+   only supports auto-sensing of the document format, but will depend on
+   the result of applying its auto-sensing when the client does not
+   supply the "document-format" attribute.  If the client supplies a
+   document format value, the Printer MUST rely on the supplied
+   attribute, rather than trust its auto-sensing algorithm.  To
+   summarize:
+
+      1. If the client does not supply a document format value, the
+         Printer MUST rely on its default value setting (which may be
+         'application/octet-stream' indicating an auto-sensing
+         mechanism).
+      2. If the client supplies a value other than 'application/octet-
+         stream', the client is supplying valid information about the
+         format of the document data and the Printer object MUST trust
+         the client supplied value more than the outcome of applying an
+
+
+
+Hastings, et al.            Standards Track                    [Page 88]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         automatic format detection mechanism.  For example, the client
+         may be requesting the printing of a PostScript file as a
+         'text/plain' document.  The Printer object MUST print a text
+         representation of the PostScript commands rather than interpret
+         the stream of PostScript commands and print the result.
+      3. If the client supplies a value of 'application/octet-stream',
+         the client is indicating that the Printer object MUST use its
+         auto-sensing mechanism on the client supplied document data
+         whether auto-sensing is the Printer object's default or not.
+
+   Note:  Since the auto-sensing algorithm is probabilistic, if the
+   client requests both auto-sensing ("document-format" set to
+   'application/octet-stream') and true fidelity ("ipp-attribute-
+   fidelity" set to 'true'), the Printer object might not be able to
+   guarantee exactly what the end user intended (the auto-sensing
+   algorithm might mistake one document format for another), but it is
+   able to guarantee that its auto-sensing mechanism be used.
+
+   When a Printer performs auto-sensing of a document in a submitted
+   job, it is RECOMMENDED that the Printer indicate to the user that
+   such auto-sensing has occurred and which document-format was auto-
+   sensed by printing that information on the job's job-start-sheet.
+
+4.1.10 'octetString'
+
+   The 'octetString' attribute syntax is a sequence of octets encoded in
+   a maximum of 1023 octets which is indicated in sub-section headers
+   using the notation: octetString(MAX).  This syntax type is used for
+   opaque data.
+
+4.1.11 'boolean'
+
+   The 'boolean' attribute syntax has only two values:  'true' and
+   'false'.
+
+4.1.12 'integer'
+
+   The 'integer' attribute syntax is an integer value that is in the
+   range from -2**31 (MIN) to 2**31 - 1 (MAX).  Each individual
+   attribute may specify the range constraint explicitly in sub-section
+   headers if the range is different from the full range of possible
+   integer values.  For example:  job-priority (integer(1:100)) for the
+   "job-priority" attribute.  However, the enforcement of that
+   additional constraint is up to the IPP objects, not the protocol.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 89]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.1.13 'rangeOfInteger'
+
+   The 'rangeOfInteger' attribute syntax is an ordered pair of integers
+   that defines an inclusive range of integer values.  The first integer
+   specifies the lower bound and the second specifies the upper bound.
+   If a range constraint is specified in the header description for an
+   attribute in this document whose attribute syntax is 'rangeOfInteger'
+   (i.e., 'X:Y' indicating X as a minimum value and Y as a maximum
+   value), then the constraint applies to both integers.
+
+4.1.14 'dateTime'
+
+   The 'dateTime' attribute syntax is a standard, fixed length, 11 octet
+   representation of the "DateAndTime" syntax as defined in RFC 2579
+   [RFC2579].  RFC 2579 also identifies an 8 octet representation of a
+   "DateAndTime" value, but IPP objects MUST use the 11 octet
+   representation.  A user interface will provide a mapping between
+   protocol dateTime values and displayable user-friendly words or
+   presentation values and phrases which are localized to the natural
+   language and date format of the user, including time zone.
+
+4.1.15 'resolution'
+
+   The 'resolution' attribute syntax specifies a two-dimensional
+   resolution in the indicated units.  It consists of 3 values: a cross
+   feed direction resolution (positive integer value), a feed direction
+   resolution (positive integer value), and a units value.  The
+   semantics of these three components are taken from the Printer MIB
+   [RFC1759] suggested values.  That is, the cross feed direction
+   component resolution component is the same as the
+   prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed
+   direction component resolution component is the same as the
+   prtMarkerAddressabilityFeedDir in the Printer MIB, and the units
+   component is the same as the prtMarkerAddressabilityUnit object in
+   the Printer MIB (namely, '3' indicates dots per inch and '4'
+   indicates dots per centimeter).  All three values MUST be present
+   even if the first two values are the same.  Example:  '300', '600',
+   '3' indicates a 300 dpi cross-feed direction resolution, a 600 dpi
+   feed direction resolution, since a '3' indicates dots per inch (dpi).
+
+4.1.16 '1setOf  X'
+
+   The '1setOf  X' attribute syntax is 1 or more values of attribute
+   syntax type X.  This syntax type is used for multi-valued attributes.
+   The syntax type is called '1setOf' rather than just 'setOf' as a
+   reminder that the set of values MUST NOT be empty (i.e., a set of
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 90]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   size 0).  Sets are normally unordered.  However each attribute
+   description of this type may specify that the values MUST be in a
+   certain order for that attribute.
+
+4.2 Job Template Attributes
+
+   Job Template attributes describe job processing behavior.  Support
+   for Job Template attributes by a Printer object is OPTIONAL (see
+   section 12.2.3 for a description of support for OPTIONAL attributes).
+   Also, clients OPTIONALLY supply Job Template attributes in create
+   requests.
+
+   Job Template attributes conform to the following rules.  For each Job
+   Template attribute called "xxx":
+
+      1. If the Printer object supports "xxx" then it MUST support both
+         a "xxx-default" attribute (unless there is a "No" in the table
+         below) and a "xxx-supported" attribute.  If the Printer object
+         doesn't support "xxx", then it MUST support neither an "xxx-
+         default" attribute nor an "xxx-supported" attribute, and it
+         MUST treat an attribute "xxx" supplied by a client as
+         unsupported.  An attribute "xxx" may be supported for some
+         document formats and not supported for other document formats.
+         For example, it is expected that a Printer object would only
+         support "orientation-requested" for some document formats (such
+         as 'text/plain' or 'text/html') but not others (such as
+         'application/postscript').
+
+      2. "xxx" is OPTIONALLY supplied by the client in a create request.
+         If "xxx" is supplied, the client is indicating a desired job
+         processing behavior for this Job.  When "xxx" is not supplied,
+         the client is indicating that the Printer object apply its
+         default job processing behavior at job processing time if the
+         document content does not contain an embedded instruction
+         indicating an xxx-related behavior.
+
+         Since an administrator MAY change the default value attribute
+         after a Job object has been submitted but before it has been
+         processed, the default value used by the Printer object at job
+         processing time may be different that the default value in
+         effect at job submission time.
+
+      3. The "xxx-supported" attribute is a Printer object attribute
+         that describes which job processing behaviors are supported by
+         that Printer object.  A client can query the Printer object to
+         find out what xxx-related behaviors are supported by inspecting
+         the returned values of the "xxx-supported" attribute.
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 91]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         Note: The "xxx" in each "xxx-supported" attribute name is
+         singular, even though an "xxx-supported" attribute usually has
+         more than one value, such as "job-sheet-supported", unless the
+         "xxx" Job Template attribute is plural, such as "finishings" or
+         "sides".  In such cases the "xxx-supported" attribute names
+         are: "finishings- supported" and "sides-supported".
+
+      4. The "xxx-default" default value attribute describes what will
+         be done at job processing time when no other job processing
+         information is supplied by the client (either explicitly as an
+         IPP attribute in the create request or implicitly as an
+         embedded instruction within the document data).
+
+   If an application wishes to present an end user with a list of
+   supported values from which to choose, the application SHOULD query
+   the Printer object for its supported value attributes.  The
+   application SHOULD also query the default value attributes.  If the
+   application then limits selectable values to only those value that
+   are supported, the application can guarantee that the values supplied
+   by the client in the create request all fall within the set of
+   supported values at the Printer.  When querying the Printer, the
+   client MAY enumerate each attribute by name in the Get-Printer-
+   Attributes Request, or the client MAY just name the "job-template"
+   group in order to get the complete set of supported attributes (both
+   supported and default attributes).
+
+   The "finishings" attribute is an example of a Job Template attribute.
+   It can take on a set of values such as 'staple', 'punch', and/or
+   'cover'.  A client can query the Printer object for the "finishings-
+   supported" attribute and the "finishings-default" attribute.  The
+   supported attribute contains a set of supported values.  The default
+   value attribute contains the finishing value(s) that will be used for
+   a new Job if the client does not supply a "finishings" attribute in
+   the create request and the document data does not contain any
+   corresponding finishing instructions.  If the client does supply the
+   "finishings" attribute in the create request, the IPP object
+   validates the value or values to make sure that they are a subset of
+   the supported values identified in the Printer object's "finishings-
+   supported" attribute.  See section 3.1.7.
+
+   The table below summarizes the names and relationships for all Job
+   Template attributes. The first column of the table (labeled "Job
+   Attribute") shows the name and syntax for each Job Template attribute
+   in the Job object. These are the attributes that can optionally be
+   supplied by the client in a create request.   The last two columns
+   (labeled "Printer: Default Value Attribute" and "Printer: Supported
+   Values Attribute") show the name and syntax for each Job Template
+   attribute in the Printer object (the default value attribute and the
+
+
+
+Hastings, et al.            Standards Track                    [Page 92]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   supported values attribute).  A "No" in the table means the Printer
+   MUST NOT support the attribute (that is, the attribute is simply not
+   applicable).  For brevity in the table, the 'text' and 'name' entries
+   do not show the maximum length for each attribute.
+
+     +===================+======================+======================+
+     | Job Attribute     |Printer: Default Value|  Printer: Supported  |
+     |                   |   Attribute          |   Values Attribute   |
+     +===================+======================+======================+
+     | job-priority      | job-priority-default |job-priority-supported|
+     | (integer 1:100)   | (integer 1:100)      |(integer 1:100)       |
+     +-------------------+----------------------+----------------------+
+     | job-hold-until    | job-hold-until-      |job-hold-until-       |
+     | (type3 keyword |  |  default             | supported            |
+     |    name)          |  (type3 keyword |    |(1setOf (             |
+     |                   |    name)             |type3 keyword | name))|
+     +-------------------+----------------------+----------------------+
+     | job-sheets        | job-sheets-default   |job-sheets-supported  |
+     | (type3 keyword |  | (type3 keyword |     |(1setOf (             |
+     |    name)          |    name)             |type3 keyword | name))|
+     +-------------------+----------------------+----------------------+
+     |multiple-document- |multiple-document-    |multiple-document-    |
+     | handling          | handling-default     |handling-supported    |
+     | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
+     +-------------------+----------------------+----------------------+
+     | copies            | copies-default       | copies-supported     |
+     | (integer (1:MAX)) | (integer (1:MAX))    | (rangeOfInteger      |
+     |                   |                      |       (1:MAX))       |
+     +-------------------+----------------------+----------------------+
+     | finishings        | finishings-default   | finishings-supported |
+     |(1setOf type2 enum)|(1setOf type2 enum)   |(1setOf type2 enum)   |
+     +-------------------+----------------------+----------------------+
+     | page-ranges       | No                   | page-ranges-         |
+     | (1setOf           |                      | supported (boolean)  |
+     |   rangeOfInteger  |                      |                      |
+     |        (1:MAX))   |                      |                      |
+     +-------------------+----------------------+----------------------+
+     | sides             | sides-default        | sides-supported      |
+     | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
+     +-------------------+----------------------+----------------------+
+     | number-up         | number-up-default    | number-up-supported  |
+     | (integer (1:MAX)) | (integer (1:MAX))    |(1setOf (integer      |
+     |                   |                      | (1:MAX) |            |
+     |                   |                      |  rangeOfInteger      |
+     |                   |                      |   (1:MAX)))          |
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 93]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+     +-------------------+----------------------+----------------------+
+     | orientation-      |orientation-requested-|orientation-requested-|
+     |  requested        |  default             |  supported           |
+     |   (type2 enum)    |  (type2 enum)        |  (1setOf type2 enum) |
+     +-------------------+----------------------+----------------------+
+     | media             | media-default        | media-supported      |
+     | (type3 keyword |  | (type3 keyword |     |(1setOf (             |
+     |    name)          |    name)             |type3 keyword | name))|
+     |                   |                      |                      |
+     |                   |                      | media-ready          |
+     |                   |                      |(1setOf (             |
+     |                   |                      |type3 keyword | name))|
+     +-------------------+----------------------+----------------------+
+     | printer-resolution| printer-resolution-  | printer-resolution-  |
+     | (resolution)      |  default             | supported            |
+     |                   | (resolution)         |(1setOf resolution)   |
+     +-------------------+----------------------+----------------------+
+     | print-quality     | print-quality-default| print-quality-       |
+     | (type2 enum)      | (type2 enum)         | supported            |
+     |                   |                      |(1setOf type2 enum)   |
+     +-------------------+----------------------+----------------------+
+
+4.2.1 job-priority (integer(1:100))
+
+   This attribute specifies a priority for scheduling the Job. A higher
+   value specifies a higher priority. The value 1 indicates the lowest
+   possible priority. The value 100 indicates the highest possible
+   priority.  Among those jobs that are ready to print, a Printer MUST
+   print all jobs with a priority value of n before printing those with
+   a priority value of n-1 for all n.
+
+   If the Printer object supports this attribute, it MUST always support
+   the full range from 1 to 100.  No administrative restrictions are
+   permitted.  This way an end-user can always make full use of the
+   entire range with any Printer object.  If privileged jobs are
+   implemented outside IPP/1.1, they MUST have priorities higher than
+   100, rather than restricting the range available to end-users.
+
+   If the client does not supply this attribute and this attribute is
+   supported by the Printer object, the Printer object MUST use the
+   value of the Printer object's "job-priority-default" at job
+   submission time (unlike most Job Template attributes that are used if
+   necessary at job processing time).
+
+   The syntax for the "job-priority-supported" is also integer(1:100).
+   This single integer value indicates the number of priority levels
+   supported.  The Printer object MUST take the value supplied by the
+   client and map it to the closest integer in a sequence of n integers
+
+
+
+Hastings, et al.            Standards Track                    [Page 94]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   values that are evenly distributed over the range from 1 to 100 using
+   the formula:
+
+      roundToNearestInt((100x+50)/n)
+
+   where n is the value of "job-priority-supported" and x ranges from 0
+   through n-1.
+
+   For example, if n=1 the sequence of values is 50;  if n=2, the
+   sequence of values is:  25 and 75;  if n = 3, the sequence of values
+   is:  17, 50 and 83;  if n = 10, the sequence of values is: 5, 15, 25,
+   35, 45, 55, 65, 75, 85, and 95;  if n = 100, the sequence of values
+   is:  1, 2, 3, ... 100.
+
+   If the value of the Printer object's "job-priority-supported" is 10
+   and the client supplies values in the range 1 to 10, the Printer
+   object maps them to 5, in the range 11 to 20, the Printer object maps
+   them to 15, etc.
+
+4.2.2 job-hold-until (type3 keyword | name (MAX))
+
+   This attribute specifies the named time period during which the Job
+   MUST become a candidate for printing.
+
+   Standard keyword values for named time periods are:
+
+      'no-hold': immediately, if there are not other reasons to hold the
+         job
+      'indefinite':  - the job is held indefinitely, until a client
+         performs a Release-Job (section 3.3.6)
+      'day-time': during the day
+      'evening': evening
+      'night': night
+      'weekend': weekend
+      'second-shift': second-shift (after close of business)
+      'third-shift': third-shift (after midnight)
+
+   An administrator MUST associate allowable print times with a named
+   time period (by means outside the scope of this IPP/1.1 document).
+   An administrator is encouraged to pick names that suggest the type of
+   time period. An administrator MAY define additional values using the
+   'name' or 'keyword' attribute syntax, depending on implementation.
+
+   If the value of this attribute specifies a time period that is in the
+   future, the Printer SHOULD add the 'job-hold-until-specified' value
+   to the job's "job-state-reasons" attribute, MUST move the job to the
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 95]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   'pending-held' state, and MUST NOT schedule the job for printing
+   until the specified time-period arrives.
+
+   When the specified time period arrives, the Printer MUST remove the
+   'job-hold-until-specified' value from the job's "job-state-reason"
+   attribute, if present.  If there are no other job state reasons that
+   keep the job in the 'pending-held' state, the Printer MUST consider
+   the job as a candidate for processing by moving the job to the
+   'pending' state.
+
+   If this job attribute value is the named value 'no-hold', or the
+   specified time period has already started, the job MUST be a
+   candidate for processing immediately.
+
+   If the client does not supply this attribute and this attribute is
+   supported by the Printer object, the Printer object MUST use the
+   value of the Printer object's "job-hold-until-default" at job
+   submission time (unlike most Job Template attributes that are used if
+   necessary at job processing time).
+
+4.2.3 job-sheets (type3 keyword | name(MAX))
+
+   This attribute determines which job start/end sheet(s), if any, MUST
+   be printed with a job.
+
+   Standard keyword values are:
+
+      'none': no job sheet is printed
+      'standard': one or more site specific standard job sheets are
+         printed, e.g. a single start sheet or both start and end sheet is
+         printed
+
+   An administrator MAY define additional values using the 'name' or
+   'keyword' attribute syntax, depending on implementation.
+
+   The effect of this attribute on jobs with multiple documents MAY be
+   affected by the "multiple-document-handling" job attribute (section
+   4.2.4), depending on the job sheet semantics.
+
+4.2.4 multiple-document-handling (type2 keyword)
+
+   This attribute is relevant only if a job consists of two or more
+   documents. This attribute MUST be supported with at least one value
+   if the Printer supports multiple documents per job (see sections
+   3.2.4 and 3.3.1).  The attribute controls finishing operations and
+   the placement of one or more print-stream pages into impressions and
+   onto media sheets.  When the value of the "copies" attribute exceeds
+   1, it also controls the order in which the copies that result from
+
+
+
+Hastings, et al.            Standards Track                    [Page 96]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   processing the documents are produced. For the purposes of this
+   explanations, if "a" represents an instance of document data, then
+   the result of processing the data in document "a" is a sequence of
+   media sheets represented by "a(*)".
+
+   Standard keyword values are:
+
+      'single-document': If a Job object has multiple documents, say,
+         the document data is called a and b, then the result of
+         processing all the document data (a and then b) MUST be treated
+         as a single sequence of media sheets for finishing operations;
+         that is, finishing would be performed on the concatenation of
+         the sequences a(*),b(*).  The Printer object MUST NOT force the
+         data in each document instance to be formatted onto a new
+         print-stream page, nor to start a new impression on a new media
+         sheet. If more than one copy is made, the ordering of the sets
+         of media sheets resulting from processing the document data
+         MUST be a(*), b(*), a(*), b(*), start on a new media sheet.
+      'separate-documents-uncollated-copies': If a Job object has
+         multiple documents, say, the document data is called a and b,
+         then the result of processing the data in each document
+         instance MUST be treated as a single sequence of media sheets
+         for finishing operations; that is, the sets a(*) and b(*) would
+         each be finished separately. The Printer object MUST force each
+         copy of the result of processing the data in a single document
+         to start on a new media sheet. If more than one copy is made,
+         the ordering of the sets of media sheets resulting from
+         processing the document data MUST be a(*), a(*), ..., b(*),
+         b(*) ... .
+      'separate-documents-collated-copies': If a Job object has multiple
+         documents, say, the document data is called a and b, then the
+         result of processing the data in each document instance MUST be
+         treated as a single sequence of media sheets for finishing
+         operations; that is, the sets a(*) and b(*) would each be
+         finished separately. The Printer object MUST force each copy of
+         the result of processing the data in a single document to start
+         on a new media sheet.  If more than one copy is made, the
+         ordering of the sets of media sheets resulting from processing
+         the document data MUST be a(*), b(*), a(*), b(*), ... .
+      'single-document-new-sheet':  Same as 'single-document', except
+         that the Printer object MUST ensure that the first impression
+         of each document instance in the job is placed on a new media
+         sheet.  This value allows multiple documents to be stapled
+         together with a single staple where each document starts on a
+         new sheet.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 97]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The 'single-document' value is the same as 'separate-documents-
+   collated-copies' with respect to ordering of print-stream pages, but
+   not media sheet generation, since 'single-document' will put the
+   first page of the next document on the back side of a sheet if an odd
+   number of pages have been produced so far for the job, while
+   'separate-documents-collated- copies' always forces the next document
+   or document copy on to a new sheet.  In addition, if the "finishings"
+   attribute specifies 'staple', then with 'single-document', documents
+   a and b are stapled together as a single document with no regard to
+   new sheets, with 'single-document-new-sheet', documents a and b are
+   stapled together as a single document, but document b starts on a new
+   sheet, but with 'separate-documents-uncollated-copies' and
+   'separate-documents-collated-copies', documents a and b are stapled
+   separately.
+
+   Note: None of these values provide means to produce uncollated sheets
+   within a document, i.e., where multiple copies of sheet n are
+   produced before sheet n+1 of the same document.
+
+   The relationship of this attribute and the other attributes that
+   control document processing is described in section 15.3.
+
+4.2.5 copies (integer(1:MAX))
+
+   This attribute specifies the number of copies to be printed.
+
+   On many devices the supported number of collated copies will be
+   limited by the number of physical output bins on the device, and may
+   be different from the number of uncollated copies which can be
+   supported.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.6 finishings (1setOf type2 enum)
+
+   This attribute identifies the finishing operations that the Printer
+   uses for each copy of each printed document in the Job. For Jobs with
+   multiple documents, the "multiple-document-handling" attribute
+   determines what constitutes a "copy" for purposes of finishing.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 98]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Standard enum values are:
+
+   Value  Symbolic Name and Description
+
+   '3'    'none':  Perform no finishing
+   '4'    'staple':  Bind the document(s) with one or more staples. The
+             exact number and placement of the staples is site-
+             defined.
+   '5'    'punch':  This value indicates that holes are required in the
+             finished document. The exact number and placement of the
+             holes is site-defined  The punch specification MAY be
+             satisfied (in a site- and implementation-specific manner)
+             either by drilling/punching, or by substituting pre-
+             drilled media.
+   '6'    'cover':  This value is specified when it is desired to select
+             a non-printed (or pre-printed) cover for the document.
+             This does not supplant the specification of a printed
+             cover (on cover stock medium) by the document itself.
+   '7'    'bind':  This value indicates that a binding is to be applied
+             to the document; the type and placement of the binding is
+             site-defined.
+   '8'    'saddle-stitch':  Bind the document(s) with one or more
+             staples (wire stitches) along the middle fold.  The exact
+             number and placement of the staples and the middle fold
+             is implementation and/or site-defined.
+   '9'    'edge-stitch':  Bind the document(s) with one or more staples
+             (wire stitches) along one edge.  The exact number and
+             placement of the staples is implementation and/or site-
+             defined.
+   '10'-'19'   reserved for future generic finishing enum values.
+
+   The following values are more specific; they indicate a corner or an
+   edge as if the document were a portrait document (see below):
+
+   '20'   'staple-top-left':  Bind the document(s) with one or more
+             staples in the top left corner.
+   '21'   'staple-bottom-left':  Bind the document(s) with one or more
+             staples in the bottom left corner.
+   '22'   'staple-top-right':  Bind the document(s) with one or more
+             staples in the top right corner.
+   '23'   'staple-bottom-right':  Bind the document(s) with one or more
+             staples in the bottom right corner.
+   '24'   'edge-stitch-left':  Bind the document(s) with one or more
+             staples (wire stitches) along the left edge.  The exact
+             number and placement of the staples is implementation
+             and/or site-defined.
+
+
+
+
+
+Hastings, et al.            Standards Track                    [Page 99]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   '25'   'edge-stitch-top':  Bind the document(s) with one or more
+             staples (wire stitches) along the top edge.  The exact
+             number and placement of the staples is implementation
+             and/or site-defined.
+   '26'   'edge-stitch-right':  Bind the document(s) with one or more
+             staples (wire stitches) along the right edge.  The exact
+             number and placement of the staples is implementation
+             and/or site-defined.
+   '27'   'edge-stitch-bottom':  Bind the document(s) with one or more
+             staples (wire stitches) along the bottom edge.  The exact
+             number and placement of the staples is implementation
+             and/or site-defined.
+   '28'   'staple-dual-left':  Bind the document(s) with two staples
+             (wire stitches) along the left edge assuming a portrait
+             document (see above).
+   '29'   'staple-dual-top':  Bind the document(s) with two staples
+             (wire stitches) along the top edge assuming a portrait
+             document (see above).
+   '30'   'staple-dual-right':  Bind the document(s) with two staples
+             (wire stitches) along the right edge assuming a portrait
+             document (see above).
+   '31'   'staple-dual-bottom':  Bind the document(s) with two staples
+             (wire stitches) along the bottom edge assuming a portrait
+             document (see above).
+
+   The 'staple-xxx' values are specified with respect to the document as
+   if the document were a portrait document.  If the document is
+   actually a landscape or a reverse-landscape document, the client
+   supplies the appropriate transformed value.  For example, to position
+   a staple in the upper left hand corner of a landscape document when
+   held for reading, the client supplies the 'staple-bottom-left' value
+   (since landscape is defined as a +90 degree rotation of the image
+   with respect to the media from portrait, i.e., anti-clockwise).  On
+   the other hand, to position a staple in the upper left hand corner of
+   a reverse-landscape document when held for reading, the client
+   supplies the 'staple-top-right' value (since reverse-landscape is
+   defined as a -90 degree rotation of the image with respect to the
+   media from portrait, i.e., clockwise).
+
+   The angle (vertical, horizontal, angled) of each staple with respect
+   to the document depends on the implementation which may in turn
+   depend on the value of the attribute.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+
+
+Hastings, et al.            Standards Track                   [Page 100]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   If the client supplies a value of 'none' along with any other
+   combination of values, it is the same as if only that other
+   combination of values had been supplied (that is the 'none' value has
+   no effect).
+
+4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX))
+
+   This attribute identifies the range(s) of print-stream pages that the
+   Printer object uses for each copy of each document which are to be
+   printed.  Nothing is printed for any pages identified that do not
+   exist in the document(s).  Ranges MUST be in ascending order, for
+   example: 1-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling
+   Printer object can process the job in a single pass.  If the ranges
+   are not ascending or are overlapping, the IPP object MUST reject the
+   request and return the 'client-error-bad-request' status code.  The
+   attribute is associated with print-stream pages not application-
+   numbered pages (for example, the page numbers found in the headers
+   and or footers for certain word processing applications).
+
+   For Jobs with multiple documents, the "multiple-document-handling"
+   attribute determines what constitutes a "copy" for purposes of the
+   specified page range(s).  When "multiple-document-handling" is
+   'single-document', the Printer object MUST apply each supplied page
+   range once to the concatenation of the print-stream pages.  For
+   example, if there are 8 documents of 10 pages each, the page-range
+   '41:60' prints the pages in the 5th and 6th documents as a single
+   document and none of the pages of the other documents are printed.
+   When "multiple-document- handling" is 'separate-documents-
+   uncollated-copies' or 'separate-documents-collated-copies', the
+   Printer object MUST apply each supplied page range repeatedly to each
+   document copy.  For the same job, the page-range '1:3, 10:10' would
+   print the first 3 pages and the 10th page of each of the 8 documents
+   in the Job, as 8 separate documents.
+
+   In most cases, the exact pages to be printed will be generated by a
+   device driver and this attribute would not be required.  However,
+   when printing an archived document which has already been formatted,
+   the end user may elect to print just a subset of the pages contained
+   in the document.  In this case, if page-range = n.m is specified, the
+   first page to be printed will be page n. All subsequent pages of the
+   document will be printed through and including page m.
+
+   "page-ranges-supported" is a boolean value indicating whether or not
+   the printer is capable of supporting the printing of page ranges.
+   This capability may differ from one PDL to another. There is no
+   "page-ranges-default" attribute.  If the "page-ranges" attribute is
+   not supplied by the client, all pages of the document will be
+   printed.
+
+
+
+Hastings, et al.            Standards Track                   [Page 101]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.8 sides (type2 keyword)
+
+   This attribute specifies how print-stream pages are to be imposed
+   upon the sides of an instance of a selected medium, i.e., an
+   impression.
+
+   The standard keyword values are:
+
+      'one-sided': imposes each consecutive print-stream page upon the
+         same side of consecutive media sheets.
+      'two-sided-long-edge': imposes each consecutive pair of print-
+         stream pages upon front and back sides of consecutive media
+         sheets, such that the orientation of each pair of print-stream
+         pages on the medium would be correct for the reader as if for
+         binding on the long edge.  This imposition is sometimes called
+         'duplex' or 'head-to-head'.
+      'two-sided-short-edge': imposes each consecutive pair of print-
+         stream pages upon front and back sides of consecutive media
+         sheets, such that the orientation of each pair of print-stream
+         pages on the medium would be correct for the reader as if for
+         binding on the short edge.  This imposition is sometimes called
+         'tumble' or 'head-to-toe'.
+      'two-sided-long-edge', 'two-sided-short-edge',
+         'tumble', and 'duplex' all work the same for portrait or
+         landscape.  However
+         'head-to-toe' is
+      'tumble' in portrait but 'duplex' in landscape.  'head-to-head'
+         also switches between 'duplex' and 'tumble' when using portrait
+         and landscape modes.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.9 number-up (integer(1:MAX))
+
+   This attribute specifies the number of print-stream pages to impose
+   upon a single side of an instance of a selected medium.  For example,
+   if the value is:
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 102]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Value  Description
+
+   '1'    the Printer MUST place one print-stream page on a single side
+             of an instance of the selected medium (MAY add some sort
+             of translation, scaling, or rotation).
+   '2'    the Printer MUST place two print-stream pages on a single side
+             of an instance of the selected medium (MAY add some sort
+             of translation, scaling, or rotation).
+   '4'    the Printer MUST place four print-stream pages on a single
+             side of an instance of the selected medium (MAY add some
+             sort of translation, scaling, or rotation).
+
+   This attribute primarily controls the translation, scaling and
+   rotation of print-stream pages.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.10 orientation-requested (type2 enum)
+
+   This attribute indicates the desired orientation for printed print-
+   stream pages; it does not describe the orientation of the client-
+   supplied print-stream pages.
+
+   For some document formats (such as 'application/postscript'), the
+   desired orientation of the print-stream pages is specified within the
+   document data.  This information is generated by a device driver
+   prior to the submission of the print job.  Other document formats
+   (such as 'text/plain') do not include the notion of desired
+   orientation within the document data.  In the latter case it is
+   possible for the Printer object to bind the desired orientation to
+   the document data after it has been submitted.  It is expected that a
+   Printer object would only support "orientations-requested" for some
+   document formats (e.g., 'text/plain' or 'text/html') but not others
+   (e.g., 'application/postscript').  This is no different than any
+   other Job Template attribute since section 4.2, item 1, points out
+   that a Printer object may support or not support any Job Template
+   attribute based on the document format supplied by the client.
+   However, a special mention is made here since it is very likely that
+   a Printer object will support "orientation-requested" for only a
+   subset of the supported document formats.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 103]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Standard enum values are:
+
+   Value  Symbolic Name and Description
+
+   '3'    'portrait':  The content will be imaged across the short edge
+             of the medium.
+   '4'    'landscape':  The content will be imaged across the long edge
+             of the medium.  Landscape is defined to be a rotation of
+             the print-stream page to be imaged by +90 degrees with
+             respect to the medium (i.e. anti-clockwise) from the
+             portrait orientation.  Note:  The +90 direction was
+             chosen because simple finishing on the long edge is the
+             same edge whether portrait or landscape
+   '5'    'reverse-landscape':  The content will be imaged across the
+             long edge of the medium.  Reverse-landscape is defined to
+             be a rotation of the print-stream page to be imaged by -
+             90 degrees with respect to the medium (i.e. clockwise)
+             from the portrait orientation.  Note: The 'reverse-
+             landscape' value was added because some applications
+             rotate landscape -90 degrees from portrait, rather than
+             +90 degrees.
+   '6'    'reverse-portrait':  The content will be imaged across the
+             short edge of the medium.  Reverse-portrait is defined to
+             be a rotation of the print-stream page to be imaged by
+             180 degrees with respect to the medium from the portrait
+             orientation.  Note: The 'reverse-portrait' value was
+             added for use with the "finishings" attribute in cases
+             where the opposite edge is desired for finishing a
+             portrait document on simple finishing devices that have
+             only one finishing position.  Thus a 'text'/plain'
+             portrait document can be stapled "on the right" by a
+             simple finishing device as is common use with some middle
+             eastern languages such as Hebrew.
+
+   Note: The effect of this attribute on jobs with multiple documents is
+   controlled by the "multiple-document-handling" job attribute (section
+   4.2.4) and the relationship of this attribute and the other
+   attributes that control document processing is described in section
+   15.3.
+
+4.2.11 media (type3 keyword | name(MAX))
+
+   This attribute identifies the medium that the Printer uses for all
+   impressions of the Job.
+
+   The values for "media" include medium-names, medium-sizes, input-
+   trays and electronic forms so that one attribute specifies the media.
+   If a Printer object supports a medium name as a value of this
+
+
+
+Hastings, et al.            Standards Track                   [Page 104]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   attribute, such a medium name implicitly selects an input-tray that
+   contains the specified medium.  If a Printer object supports a medium
+   size as a value of this attribute, such a medium size implicitly
+   selects a medium name that in turn implicitly selects an input-tray
+   that contains the medium with the specified size.  If a Printer
+   object supports an input-tray as the value of this attribute, such an
+   input-tray implicitly selects the medium that is in that input-tray
+   at the time the job prints.  This case includes manual-feed input-
+   trays.  If a Printer object supports an electronic form as the value
+   of this attribute, such an electronic form implicitly selects a
+   medium-name that in turn implicitly selects an input-tray that
+   contains the medium specified by the electronic form.  The electronic
+   form also implicitly selects an image that the Printer MUST merge
+   with the document data as its prints each page.
+
+   Standard keyword values are taken from ISO DPA [ISO10175], the
+   Printer MIB [RFC1759], and ASME-Y14.1M [ASME-Y14.1M] and are listed
+   in section 14.  An administrator MAY define additional values using
+   the 'name' or 'keyword' attribute syntax, depending on
+   implementation.
+
+   There is also an additional Printer attribute named "media-ready"
+   which differs from "media-supported" in that legal values only
+   include the subset of "media-supported" values that are physically
+   loaded and ready for printing with no operator intervention required.
+   If an IPP object supports "media-supported", it NEED NOT support
+   "media-ready".
+
+   The relationship of this attribute and the other attributes that
+   control document processing is described in section 15.3.
+
+4.2.12 printer-resolution (resolution)
+
+   This attribute identifies the resolution that Printer uses for the
+   Job.
+
+4.2.13 print-quality (type2 enum)
+
+   This attribute specifies the print quality that the Printer uses for
+   the Job.
+
+   The standard enum values are:
+
+   Value  Symbolic Name and Description
+
+   '3'    'draft': lowest quality available on the printer
+   '4'    'normal': normal or intermediate quality on the printer
+   '5'    'high': highest quality available on the printer
+
+
+
+Hastings, et al.            Standards Track                   [Page 105]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.3 Job Description Attributes
+
+   The attributes in this section form the attribute group called "job-
+   description".  The following table summarizes these attributes.  The
+   third column indicates whether the attribute is a REQUIRED attribute
+   that MUST be supported by Printer objects.  If it is not indicated as
+   REQUIRED, then it is OPTIONAL.  The maximum size in octets for 'text'
+   and 'name' attributes is indicated in parenthesizes.
+
+   +----------------------------+----------------------+--------------+
+   |      Attribute             |     Syntax           |   REQUIRED?  |
+   +----------------------------+----------------------+--------------+
+   | job-uri                    | uri                  |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-id                     | integer(1:MAX)       |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-printer-uri            | uri                  |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-more-info              | uri                  |              |
+   +----------------------------+----------------------+--------------+
+   | job-name                   | name (MAX)           |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-originating-user-name  | name (MAX)           |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-state                  | type1 enum           |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-state-reasons          | 1setOf type2 keyword |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-state-message          | text (MAX)           |              |
+   +----------------------------+----------------------+--------------+
+   | job-detailed-status-       | 1setOf text (MAX)    |              |
+   |       messages             |                      |              |
+   +----------------------------+----------------------+--------------+
+   | job-document-access-errors | 1setOf text (MAX)    |              |
+   +----------------------------+----------------------+--------------+
+   | number-of-documents        | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | output-device-assigned     | name (127)           |              |
+   +----------------------------+----------------------+--------------+
+   | time-at-creation           | integer (MIN:MAX)    |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | time-at-processing         | integer (MIN:MAX)    |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | time-at-completed          | integer (MIN:MAX)    |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | job-printer-up-time        | integer (1:MAX)      |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | date-time-at-creation      | dateTime             |              |
+
+
+
+Hastings, et al.            Standards Track                   [Page 106]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   +----------------------------+----------------------+--------------+
+   | date-time-at-processing    | dateTime             |              |
+   +----------------------------+----------------------+--------------+
+   | date-time-at-completed     | dateTime             |              |
+   +----------------------------+----------------------+--------------+
+   | number-of-intervening-jobs | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | job-message-from-operator  | text (127)           |              |
+   +----------------------------+----------------------+--------------+
+   | job-k-octets               | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | job-impressions            | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | job-media-sheets           | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | job-k-octets-processed     | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | job-impressions-completed  | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | job-media-sheets-completed | integer (0:MAX)      |              |
+   +----------------------------+----------------------+--------------+
+   | attributes-charset         | charset              |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+   | attributes-natural-language| naturalLanguage      |  REQUIRED    |
+   +----------------------------+----------------------+--------------+
+
+4.3.1 job-uri (uri)
+
+   This REQUIRED attribute contains the URI for the job.  The Printer
+   object, on receipt of a new job, generates a URI which identifies the
+   new Job.  The Printer object returns the value of the "job-uri"
+   attribute as part of the response to a create request.  The precise
+   format of a Job URI is implementation dependent.  If the Printer
+   object supports more than one URI and there is some relationship
+   between the newly formed Job URI and the Printer object's URI, the
+   Printer object uses the Printer URI supplied by the client in the
+   create request.  For example, if the create request comes in over a
+   secure channel, the new Job URI MUST use the same secure channel.
+   This can be guaranteed because the Printer object is responsible for
+   generating the Job URI and the Printer object is aware of its
+   security configuration and policy as well as the Printer URI used in
+   the create request.
+
+   For a description of this attribute and its relationship to "job-id"
+   and "job-printer-uri" attribute, see the discussion in section 2.4 on
+   "Object Identity".
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 107]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.3.2 job-id (integer(1:MAX))
+
+   This REQUIRED attribute contains the ID of the job.  The Printer, on
+   receipt of a new job, generates an ID which identifies the new Job on
+   that Printer.  The Printer returns the value of the "job-id"
+   attribute as part of the response to a create request.  The 0 value
+   is not included to allow for compatibility with SNMP index values
+   which also cannot be 0.
+
+   For a description of this attribute and its relationship to "job-uri"
+   and "job-printer-uri" attribute, see the discussion in section 2.4 on
+   "Object Identity".
+
+4.3.3 job-printer-uri (uri)
+
+   This REQUIRED attribute identifies the Printer object that created
+   this Job object.  When a Printer object creates a Job object, it
+   populates this attribute with the Printer object URI that was used in
+   the create request.  This attribute permits a client to identify the
+   Printer object that created this Job object when only the Job
+   object's URI is available to the client.  The client queries the
+   creating Printer object to determine which languages, charsets,
+   operations, are supported for this Job.
+
+   For a description of this attribute and its relationship to "job-uri"
+   and "job-id" attribute, see the discussion in section 2.4 on "Object
+   Identity".
+
+4.3.4 job-more-info (uri)
+
+   Similar to "printer-more-info", this attribute contains the URI
+   referencing some resource with more information about this Job
+   object, perhaps an HTML page containing information about the Job.
+
+4.3.5 job-name (name(MAX))
+
+   This REQUIRED attribute is the name of the job.  It is a name that is
+   more user friendly than the "job-uri" attribute value.  It does not
+   need to be unique between Jobs.  The Job's "job-name" attribute is
+   set to the value supplied by the client in the "job-name" operation
+   attribute in the create request (see Section 3.2.1.1).   If, however,
+   the "job-name" operation attribute is not supplied by the client in
+   the create request, the Printer object, on creation of the Job, MUST
+   generate a name.  The printer SHOULD generate the value of the Job's
+   "job-name" attribute from the first of the following sources that
+   produces a value: 1) the "document-name" operation attribute of the
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 108]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   first (or only) document, 2) the "document-URI" attribute of the
+   first (or only) document, or 3) any other piece of Job specific
+   and/or Document Content information.
+
+4.3.6 job-originating-user-name (name(MAX))
+
+   This REQUIRED attribute contains the name of the end user that
+   submitted the print job.  The Printer object sets this attribute to
+   the most authenticated printable name that it can obtain from the
+   authentication service over which the IPP operation was received.
+   Only if such is not available, does the Printer object use the value
+   supplied by the client in the "requesting-user-name" operation
+   attribute of the create operation (see Sections 4.4.2, 4.4.3, and 8).
+
+   Note:  The Printer object needs to keep an internal originating user
+   id of some form, typically as a credential of a principal, with the
+   Job object.  Since such an internal attribute is implementation-
+   dependent and not of interest to clients, it is not specified as a
+   Job Description attribute.  This originating user id is used for
+   authorization checks (if any) on all subsequent operations.
+
+4.3.7 job-state (type1 enum)
+
+   This REQUIRED attribute identifies the current state of the job.
+   Even though the IPP protocol defines seven values for job states
+   (plus the out-of-band 'unknown' value - see Section 4.1),
+   implementations only need to support those states which are
+   appropriate for the particular implementation.  In other words, a
+   Printer supports only those job states implemented by the output
+   device and available to the Printer object implementation.
+
+   Standard enum values are:
+
+   Values Symbolic Name and Description
+
+   '3'  'pending':  The job is a candidate to start processing, but is
+           not yet processing.
+
+   '4'  'pending-held':  The job is not a candidate for processing for
+           any number of reasons but will return to the 'pending'
+           state as soon as the reasons are no longer present.  The
+           job's "job-state-reason" attribute MUST indicate why the
+           job is no longer a candidate for processing.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 109]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   '5'  'processing':  One or more of:
+
+           1.  the job is using, or is attempting to use, one or
+           more purely software processes that are analyzing,
+           creating, or interpreting a PDL, etc.,
+           2.  the job is using, or is attempting to use, one or
+           more hardware devices that are interpreting a PDL, making
+           marks on a medium, and/or performing finishing, such as
+           stapling, etc.,
+           3. the Printer object has made the job ready for
+           printing, but the output device is not yet printing it,
+           either because the job hasn't reached the output device
+           or because the job is queued in the output device or some
+           other spooler, awaiting the output device to print it.
+
+           When the job is in the 'processing' state, the entire job
+           state includes the detailed status represented in the
+           Printer object's "printer-state", "printer-state-
+           reasons", and "printer-state-message" attributes.
+
+           Implementations MAY, though they NEED NOT,  include
+           additional values in the job's "job-state-reasons"
+           attribute to indicate the progress of the job, such as
+           adding the 'job-printing' value to indicate when the
+           output device is actually making marks on paper and/or
+           the 'processing-to-stop-point' value to indicate that the
+           IPP object is in the process of canceling or aborting the
+           job.  Most implementations won't bother with this nuance.
+
+   '6'  'processing-stopped':  The job has stopped while processing
+           for any number of reasons and will return to the
+           'processing' state as soon as the reasons are no longer
+           present.
+
+           The job's "job-state-reason" attribute MAY indicate why
+           the job has stopped processing.  For example, if the
+           output device is stopped, the 'printer-stopped' value MAY
+           be included in the job's "job-state-reasons" attribute.
+
+           Note:  When an output device is stopped, the device
+           usually indicates its condition in human readable form
+           locally at the device.  A client can obtain more complete
+           device status remotely by querying the Printer object's
+           "printer-state", "printer-state-reasons" and "printer-
+           state-message" attributes.
+
+   '7'  'canceled':  The job has been canceled by a Cancel-Job
+           operation and the Printer object has completed canceling
+
+
+
+Hastings, et al.            Standards Track                   [Page 110]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+           the job and all job status attributes have reached their
+           final values for the job.  While the Printer object is
+           canceling the job, the job remains in its current state,
+           but the job's "job-state-reasons" attribute SHOULD
+           contain the 'processing-to-stop-point' value and one of
+           the 'canceled-by-user', 'canceled-by-operator', or
+           'canceled-at-device' value.  When the job moves to the
+           'canceled' state, the  'processing-to-stop-point' value,
+           if present, MUST be removed, but the 'canceled-by-xxx',
+           if present, MUST remain.
+
+   '8'  'aborted':  The job has been aborted by the system, usually
+           while the job was in the 'processing' or 'processing-
+           stopped' state and the Printer has completed aborting the
+           job and all job status attributes have reached their
+           final values for the job.  While the Printer object is
+           aborting the job, the job remains in its current state,
+           but the job's "job-state-reasons" attribute SHOULD
+           contain the 'processing-to-stop-point' and 'aborted-by-
+           system' values.  When the job moves to the 'aborted'
+           state, the  'processing-to-stop-point' value, if present,
+           MUST be removed, but the 'aborted-by-system' value, if
+           present, MUST remain.
+
+   '9'  'completed':  The job has completed successfully or with
+           warnings or errors after processing and all of the job
+           media sheets have been successfully stacked in the
+           appropriate output bin(s) and all job status attributes
+           have reached their final values for the job.  The job's
+           "job-state-reasons" attribute SHOULD contain one of:
+           'completed-successfully', 'completed-with-warnings', or
+           'completed-with-errors' values.
+
+   The final value for this attribute MUST be one of: 'completed',
+   'canceled', or 'aborted' before the Printer removes the job
+   altogether.  The length of time that jobs remain in the 'canceled',
+   'aborted', and 'completed' states depends on implementation.  See
+   section 4.3.7.2.
+
+   The following figure shows the normal job state transitions.
+
+                                                      +----> canceled
+                                                     /
+       +----> pending --------> processing ---------+------> completed
+       |         ^                   ^               \
+   --->+         |                   |                +----> aborted
+       |         v                   v               /
+       +----> pending-held    processing-stopped ---+
+
+
+
+Hastings, et al.            Standards Track                   [Page 111]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Normally a job progresses from left to right.  Other state
+   transitions are unlikely, but are not forbidden.  Not shown are the
+   transitions to the 'canceled' state from the 'pending', 'pending-
+   held', and 'processing-stopped' states.
+
+   Jobs reach one of the three terminal states: 'completed', 'canceled',
+   or 'aborted', after the jobs have completed all activity, including
+   stacking output media, after the jobs have completed all activity,
+   and all job status attributes have reached their final values for the
+   job.
+
+4.3.7.1 Forwarding Servers
+
+   As with all other IPP attributes, if the implementation cannot
+   determine the correct value for this attribute, it SHOULD respond
+   with the out-of-band value 'unknown' (see section 4.1) rather than
+   try to guess at some possibly incorrect value and give the end user
+   the wrong impression about the state of the Job object.  For example,
+   if the implementation is just a gateway into some printing system
+   from which it can normally get status, but temporarily is unable,
+   then the implementation should return the 'unknown' value.  However,
+   if the implementation is a gateway to a printing system that never
+   provides detailed status about the print job, the implementation MAY
+   set the IPP Job object's state  to 'completed', provided that it also
+   sets the 'queued-in-device' value in the job's "job-state-reasons"
+   attribute (see section 4.3.8).
+
+4.3.7.2 Partitioning of Job States
+
+   This section partitions the 7 job states into phases:  Job Not
+   Completed, Job Retention, Job History, and Job Removal.  This section
+   also explains the 'job-restartable' value of the "job-state-reasons"
+   Job Description attribute for use with the Restart-Job operation.
+
+   Job Not Completed:  When a job is in the 'pending', 'pending-held',
+   'processing', or 'processing-stopped' states, the job is not
+   completed.
+
+   Job Retention:  When a job enters one of the three terminal job
+   states:  'completed', 'canceled', or 'aborted', the IPP Printer
+   object MAY "retain" the job in a restartable condition for an
+   implementation-defined time period.  This time period MAY be zero
+   seconds and MAY depend on the terminal job state.  This phase is
+   called Job Retention.  While in the Job Retention phase, the job's
+   document data is retained and a client may restart the job using the
+   Restart-Job operation.  If the IPP object supports the Restart-Job
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 112]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   operation, then it SHOULD indicate that the job is restartable by
+   adding the 'job-restartable' value to the job's "job-state-reasons"
+   attribute (see Section 4.3.8) during the Job Retention phase.
+
+   Job History:  After the Job Retention phase expires for a job, the
+   Printer object deletes the document data for the job and the job
+   becomes part of the Job History.  The Printer object MAY also delete
+   any number of the job attributes.  Since the job is no longer
+   restartable, the Printer object MUST remove the 'job-restartable'
+   value from the job's "job-state-reasons" attribute, if present.
+
+   Job Removal:  After the job has remained in the Job History for an
+   implementation-defined time, such as when the number of jobs exceeds
+   a fixed number or after a fixed time period (which MAY be zero
+   seconds), the IPP Printer removes the job from the system.
+
+   Using the Get-Jobs operation and supplying the 'not-completed' value
+   for the "which-jobs" operation attribute, a client is requesting jobs
+   in the Job Not Completed phase.  Using the Get-Jobs operation and
+   supplying the 'completed' value for the "which-jobs" operation
+   attribute, a client is requesting jobs in the Job Retention and Job
+   History phases.  Using the Get-Job-Attributes operation, a client is
+   requesting a job in any phase except Job Removal.  After Job Removal,
+   the Get-Job-Attributes and Get-Jobs operations no longer are capable
+   of returning any information about a job.
+
+4.3.8 job-state-reasons (1setOf type2 keyword)
+
+   This REQUIRED attribute provides additional information about the
+   job's current state, i.e., information that augments the value of the
+   job's "job-state" attribute.
+
+   These values MAY be used with any job state or states for which the
+   reason makes sense.  Some of these value definitions indicate
+   conformance requirements; the rest are OPTIONAL.  Furthermore, when
+   implemented, the Printer MUST return these values when the reason
+   applies and MUST NOT return them when the reason no longer applies
+   whether the value of the Job's "job-state" attribute changed or not.
+   When the Job does not have any reasons for being in its current
+   state, the value of the Job's "job-state-reasons" attribute MUST be
+   'none'.
+
+   Note: While values cannot be added to the 'job-state' attribute
+   without impacting deployed clients that take actions upon receiving
+   "job-state" values, it is the intent that additional "job-state-
+   reasons" values can be defined and registered without impacting such
+   deployed clients.  In other words, the "job-state-reasons" attribute
+   is intended to be extensible.
+
+
+
+Hastings, et al.            Standards Track                   [Page 113]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The following standard keyword values are defined.  For ease of
+   understanding, the values are presented in the order in which the
+   reasons are likely to occur (if implemented), starting with the
+   'job-incoming' value:
+
+      'none':  There are no reasons for the job's current state.  This
+         state reason is semantically equivalent to "job-state-reasons"
+         without any value and MUST be used when there is no other
+         value, since the 1setOf attribute syntax requires at least one
+         value.
+      'job-incoming':  Either (1) the Printer has accepted the Create-
+         Job operation and is expecting additional Send-Document and/or
+         Send-URI operations, or (2) the Printer is retrieving/accepting
+         document data as a result of a Print-Job, Print-URI, Send-
+         Document or Send-URI operation.
+      'job-data-insufficient':  The Create-Job operation has been
+         accepted by the Printer, but the Printer is expecting
+         additional document data before it can move the job into the
+         'processing' state.  If a Printer starts processing before it
+         has received all data, the Printer removes the 'job-data-
+         insufficient' reason, but the 'job-incoming' remains.  If a
+         Printer starts processing after it has received all data, the
+         Printer removes the 'job-data-insufficient' reason and the
+         'job-incoming' at the same time.
+      'document-access-error':  After accepting a Print-URI or Send-URI
+         request, the Printer could not access one or more documents
+         passed by reference.  This reason is intended to cover any file
+         access problem, including file does not exist and access denied
+         because of an access control problem.  The Printer MAY also
+         indicate the document access error using the "job-document-
+         access-errors" Job Description attribute (see section 4.3.11).
+         Whether the Printer aborts the job and moves the job to the
+         'aborted' job state or prints all documents that are accessible
+         and moves the job to the 'completed' job state and adds the
+         'completed-with-errors' value in the job's "job-state-reasons"
+         attribute depends on implementation and/or site policy.  This
+         value SHOULD be supported if the Print-URI or Send-URI
+         operations are supported.
+      'submission-interrupted':  The job was not completely submitted
+         for some unforeseen reason, such as: (1) the Printer has
+         crashed before the job was closed by the client, (2) the
+         Printer or the document transfer method has crashed in some
+         non-recoverable way before the document data was entirely
+         transferred to the Printer, (3) the client crashed or failed to
+         close the job before the time-out period.  See section 4.4.31.
+      'job-outgoing':  The Printer is transmitting the job to the output
+         device.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 114]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      'job-hold-until-specified':  The value of the job's "job-hold-
+         until" attribute was specified with a time period that is still
+         in the future.  The job MUST NOT be a candidate for processing
+         until this reason is removed and there are no other reasons to
+         hold the job.  This value SHOULD be supported if the "job-
+         hold-until" Job Template attribute is supported.
+      'resources-are-not-ready':  At least one of the resources needed
+         by the job, such as media, fonts, resource objects, etc., is
+         not ready on any of the physical printer's for which the job is
+         a candidate.  This condition MAY be detected when the job is
+         accepted, or subsequently while the job is pending or
+         processing, depending on implementation.  The job may remain in
+         its current state or be moved to the 'pending-held' state,
+         depending on implementation and/or job scheduling policy.
+      'printer-stopped-partly':  The value of the Printer's "printer-
+         state-reasons" attribute contains the value 'stopped-partly'.
+      'printer-stopped':  The value of the Printer's "printer-state"
+         attribute is 'stopped'.
+      'job-interpreting': Job is in the 'processing' state, but more
+         specifically, the Printer is interpreting the document data.
+      'job-queued': Job is in the 'processing' state, but more
+         specifically, the Printer has queued the document data.
+      'job-transforming': Job is in the 'processing' state, but more
+         specifically, the Printer is interpreting document data and
+         producing another electronic representation.
+      'job-queued-for-marker': Job is in any of the 'pending-held',
+         'pending', or 'processing' states, but more specifically, the
+         Printer has completed enough processing of the document to be
+         able to start marking and the job is waiting for the marker.
+         Systems that require human intervention to release jobs using
+         the Release-Job operation, put the job into the 'pending-held'
+         job state.  Systems that automatically select a job to use the
+         marker put the job into the  'pending' job state or keep the
+         job in the 'processing' job state while waiting for the marker,
+         depending on implementation.  All implementations put the job
+         into (or back into) the 'processing' state when marking does
+         begin.
+      'job-printing':  The output device is marking media. This value is
+         useful for Printers which spend a great deal of time processing
+         (1) when no marking is happening and then want to show that
+         marking is now happening or (2) when the job is in the process
+         of being canceled or aborted while the job remains in the
+         'processing' state, but the marking has not yet stopped so that
+         impression or sheet counts are still increasing for the job.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 115]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      'job-canceled-by-user':  The job was canceled by the owner of the
+         job using the Cancel-Job request, i.e., by a user whose
+         authenticated identity is the same as the value of the
+         originating user that created the Job object, or by some other
+         authorized end-user, such as a member of the job owner's
+         security group.  This value SHOULD be supported.
+      'job-canceled-by-operator':  The job was canceled by the operator
+         using the Cancel-Job request, i.e., by a user who has been
+         authenticated as having operator privileges (whether local or
+         remote).  If the security policy is to allow anyone to cancel
+         anyone's job, then this value may be used when the job is
+         canceled by other than the owner of the job.  For such a
+         security policy, in effect, everyone is an operator as far as
+         canceling jobs with IPP is concerned.  This value SHOULD be
+         supported if the implementation permits canceling by other than
+         the owner of the job.
+      'job-canceled-at-device':  The job was canceled by an unidentified
+         local user, i.e., a user at a console at the device.  This
+         value SHOULD be supported if the implementation supports
+         canceling jobs at the console.
+      'aborted-by-system':  The job (1) is in the process of being
+         aborted, (2) has been aborted by the system and placed in the
+         'aborted' state, or (3) has been aborted by the system and
+         placed in the 'pending-held' state, so that a user or operator
+         can manually try the job again.  This value SHOULD be
+         supported.
+      'unsupported-compression': The job was aborted by the system
+         because the Printer determined while attempting to decompress
+         the document-data's that the compression is actually not among
+         those supported by the Printer.  This value MUST be supported,
+         since "compressions is a REQUIRED operation attribute.
+      'compression-error': The job was aborted by the system because the
+         Printer encountered an error in the document-data while
+         decompressing it.  If the Printer posts this reason, the
+         document-data has already passed any tests that would have led
+         to the 'unsupported-compression' job-state-reason.
+      'unsupported-document-format': The job was aborted by the system
+         because the document-data's document-format is not among those
+         supported by the Printer.  If the client specifies the
+         document-format as 'application/octet-stream', the printer MAY
+         abort the job and post this reason even though the format is a
+         member of the "document-format-supported" printer attribute,
+         but not among the auto-sensed document-formats.  This value
+         MUST be supported, since "document-format" is a REQUIRED
+         operation attribute.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 116]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      'document-format-error': The job was aborted by the system because
+         the Printer encountered an error in the document-data while
+         processing it.  If the Printer posts this reason, the
+         document-data has already passed any tests that would have led
+         to the 'unsupported-document-format' job-state-reason.
+      'processing-to-stop-point':  The requester has issued a Cancel-Job
+         operation or the Printer object has aborted the job, but is
+         still performing some actions on the job until a specified stop
+         point occurs or job termination/cleanup is completed.
+
+         If the implementation requires some measurable time to cancel
+         the job in the 'processing' or 'processing-stopped' job states,
+         the IPP object MUST use this value to indicate that the Printer
+         object is still performing some actions on the job while the
+         job remains in the 'processing' or 'processing-stopped' state.
+         After all the job's job description attributes have stopped
+         incrementing, the Printer object moves the job from the
+         'processing' state to the 'canceled' or
+         'aborted' job states.
+
+      'service-off-line':  The Printer is off-line and accepting no
+         jobs.  All 'pending' jobs are put into the 'pending-held'
+         state.  This situation could be true if the service's or
+         document transform's input is impaired or broken.
+      'job-completed-successfully':  The job completed successfully.
+         This value SHOULD be supported.
+      'job-completed-with-warnings':  The job completed with warnings.
+         This value SHOULD be supported if the implementation detects
+         warnings.
+      'job-completed-with-errors':  The job completed with errors (and
+         possibly warnings too).  This value SHOULD be supported if the
+         implementation detects errors.
+      'job-restartable' - This job is retained (see section 4.3.7.2) and
+         is currently able to be restarted using the Restart-Job
+         operation (see section 3.3.7).  If 'job-restartable' is a value
+         of the job's 'job-state-reasons' attribute, then the IPP object
+         MUST accept a Restart-Job operation for that job.  This value
+         SHOULD be supported if the Restart-Job operation is supported.
+      'queued-in-device': The job has been forwarded to a device or
+         print system that is unable to send back status.  The Printer
+         sets the job's "job-state " attribute to 'completed'  and adds
+         the 'queued-in-device' value to the job's "job-state-reasons"
+         attribute to indicate that the Printer has no additional
+         information about the job and never will have any better
+         information.  See section 4.3.7.1.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 117]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.3.9 job-state-message (text(MAX))
+
+   This attribute specifies information about the "job-state" and "job-
+   state-reasons" attributes in human readable text.  If the Printer
+   object supports this attribute, the Printer object MUST be able to
+   generate this message in any of the natural languages identified by
+   the Printer's "generated-natural-language-supported" attribute (see
+   the "attributes-natural-language" operation attribute specified in
+   Section 3.1.4.1).
+
+   The value SHOULD NOT contain additional information not contained in
+   the values of the "job-state" and "job-states-reasons" attributes,
+   such as interpreter error information.  Otherwise, application
+   programs might attempt to parse the (localized text).  For such
+   additional information such as interpreter errors for application
+   program consumption or specific document access errors, new
+   attributes with keyword values, needs to be developed and registered.
+
+4.3.10 job-detailed-status-messages (1setOf text(MAX))
+
+   This attribute specifies additional detailed and technical
+   information about the job.  The Printer NEED NOT localize the
+   message(s), since they are intended for use by the system
+   administrator or other experienced technical persons.  Localization
+   might obscure the technical meaning of such messages.  Clients MUST
+   NOT attempt to parse the value of this attribute.  See "job-
+   document-access-errors" (section 4.3.11) for additional errors that a
+   program can process.
+
+4.3.11 job-document-access-errors (1setOf text(MAX))
+
+   This attribute provides additional information about each document
+   access error for this job encountered by the Printer after it
+   returned a response to the Print-URI or Send-URI operation and
+   subsequently attempted to access document(s) supplied in the Print-
+   URI or Send-URI operation.  For errors in the protocol that is
+   identified by the URI scheme in the "document-uri" operation
+   attribute, such as 'http:' or 'ftp:', the error code is returned in
+   parentheses, followed by the URI.  For example:
+
+      (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf
+
+   Most Internet protocols use decimal error codes (unlike IPP), so the
+   ASCII error code representation is in decimal.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 118]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.3.12 number-of-documents (integer(0:MAX))
+
+   This attribute indicates the number of documents in the job, i.e.,
+   the number of Send-Document, Send-URI, Print-Job, or Print-URI
+   operations that the Printer has accepted for this job, regardless of
+   whether the document data has reached the Printer object or not.
+
+   Implementations supporting the OPTIONAL Create-Job/Send-
+   Document/Send-URI operations SHOULD support this attribute so that
+   clients can query the number of documents in each job.
+
+4.3.13 output-device-assigned (name(127))
+
+   This attribute identifies the output device to which the Printer
+   object has assigned this job.  If an output device implements an
+   embedded Printer object, the Printer object NEED NOT set this
+   attribute.  If a print server implements a Printer object, the value
+   MAY be empty (zero- length string) or not returned until the Printer
+   object assigns an output device to the job.  This attribute is
+   particularly useful when a single Printer object supports multiple
+   devices (so called "fan-out" - see section 2.1).
+
+4.3.14 Event Time Job Description Attributes
+
+   This section defines the Job Description attributes that indicate the
+   time at which certain events occur for a job.  If the job event has
+   not yet occurred, then the IPP object MUST return the 'no-value'
+   out-of-band value (see the beginning of Section 4.1).  The "time-at-
+   xxx(integer)" attributes represent time as an 'integer' representing
+   the number of seconds since the device was powered up (informally
+   called "time ticks").  The "date-time-at-xxx(dateTime)" attributes
+   represent time as 'dateTime' representing date and time (including an
+   offset from UTC).
+
+   In order to populate these attributes, the Printer object copies the
+   value(s) of the following Printer Description attributes at the time
+   the event occurs:
+
+      1. the value in the Printer's "printer-up-time" attribute for the
+         "time-at-xxx(integer)" attributes
+
+      2. the value in the Printer's "printer-current-time" attribute for
+         the "date-time-at-xxx(dateTime)" attributes.
+
+   If the Printer resets its "printer-up-time" attribute to 1 on power-
+   up (see section 4.4.29) and has persistent jobs, then it MUST change
+   all of jobs' "time-at-xxx(integer)" (time tick) job attributes whose
+   events have occurred either to:
+
+
+
+Hastings, et al.            Standards Track                   [Page 119]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      1. 0 to indicate that the event happened before the most recent
+         power up OR
+
+      2. the negative of the number of seconds before the most recent
+         power-up that the event took place, though the negative number
+         NEED NOT reflect the exact number of seconds.
+
+   If a client queries a "time-at-xxx(integer)" time tick Job attribute
+   and finds the value to be 0 or negative, the client MUST assume that
+   the event occurred in some life other than the Printer's current
+   life.
+
+   Note: A Printer does not change the values of any "date-time-at-
+   xxx(dateTime)" job attributes on power-up.
+
+4.3.14.1 time-at-creation (integer(MIN:MAX))
+
+   This REQUIRED attribute indicates the time at which the Job object
+   was created.
+
+4.3.14.2 time-at-processing (integer(MIN:MAX))
+
+   This REQUIRED attribute indicates the time at which the Job object
+   first began processing after the create operation or the most recent
+   Restart-Job operation.  The out-of-band 'no-value' value is returned
+   if the job has not yet been in the 'processing' state (see the
+   beginning of Section 4.1).
+
+4.3.14.3 time-at-completed (integer(MIN:MAX))
+
+   This REQUIRED attribute indicates the time at which the Job object
+   completed (or was canceled or aborted).  The out-of-band 'no-value'
+   value is returned if the job has not yet completed, been canceled, or
+   aborted (see the beginning of Section 4.1).
+
+4.3.14.4 job-printer-up-time (integer(1:MAX))
+
+   This REQUIRED Job Description attribute indicates the amount of time
+   (in seconds) that the Printer implementation has been up and running.
+   This attribute is an alias for the "printer-up-time" Printer
+   Description attribute (see Section 4.4.29).
+
+   A client MAY request this attribute in a Get-Job-Attributes or Get-
+   Jobs request and use the value returned in combination with other
+   requested Event Time Job Description Attributes in order to display
+   time attributes to a user.  The difference between this attribute and
+   the 'integer' value of a "time-at-xxx" attribute is the number of
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 120]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   seconds ago that the "time-at-xxx" event occurred.  A client can
+   compute the wall-clock time at which the "time-at-xxx" event occurred
+   by subtracting this difference from the client's wall-clock time.
+
+4.3.14.5 date-time-at-creation (dateTime)
+
+   This attribute indicates the date and time at which the Job object
+   was created.
+
+4.3.14.6 date-time-at-processing (dateTime)
+
+   This attribute indicates the date and time at which the Job object
+   first began processing after the create operation or the most recent
+   Restart-Job operation.
+
+4.3.14.7 date-time-at-completed (dateTime)
+
+   This attribute indicates the date and time at which the Job object
+   completed (or was canceled or aborted).
+
+4.3.15 number-of-intervening-jobs (integer(0:MAX))
+
+   This attribute indicates the number of jobs that are "ahead" of this
+   job in the relative chronological order of expected time to complete
+   (i.e., the current scheduled order). For efficiency, it is only
+   necessary to calculate this value when an operation is performed that
+   requests this attribute.
+
+4.3.16 job-message-from-operator (text(127))
+
+   This attribute provides a message from an operator, system
+   administrator or "intelligent" process to indicate to the end user
+   the reasons for modification or other management action taken on a
+   job.
+
+4.3.17 Job Size Attributes
+
+   This sub-section defines job attributes that describe the size of the
+   job.  These attributes are not intended to be counters; they are
+   intended to be useful routing and scheduling information if known.
+   For these attributes, the Printer object may try to compute the value
+   if it is not supplied in the create request.  Even if the client does
+   supply a value for these three attributes in the create request, the
+   Printer object MAY choose to change the value if the Printer object
+   is able to compute a value which is more accurate than the client
+   supplied value.  The Printer object may be able to determine the
+   correct value for these attributes either right at job submission
+   time or at any later point in time.
+
+
+
+Hastings, et al.            Standards Track                   [Page 121]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.3.17.1 job-k-octets (integer(0:MAX))
+
+   This attribute specifies the total size of the document(s) in K
+   octets, i.e., in units of 1024 octets requested to be processed in
+   the job.  The value MUST be rounded up, so that a job between 1 and
+   1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2,
+   etc.
+
+   This value MUST NOT include the multiplicative factors contributed by
+   the number of copies specified by the "copies" attribute, independent
+   of whether the device can process multiple copies without making
+   multiple passes over the job or document data and independent of
+   whether the output is collated or not.  Thus the value is independent
+   of the implementation and indicates the size of the document(s)
+   measured in K octets independent of the number of copies.
+
+   This value MUST also not include the multiplicative factor due to a
+   copies instruction embedded in the document data.  If the document
+   data actually includes replications of the document data, this value
+   will include such replication.  In other words, this value is always
+   the size of the source document data, rather than a measure of the
+   hardcopy output to be produced.
+
+4.3.17.2 job-impressions (integer(0:MAX))
+
+   This attribute specifies the total size in number of impressions of
+   the document(s) being submitted (see the definition of impression in
+   section 12.2.5).
+
+   As with "job-k-octets", this value MUST NOT include the
+   multiplicative factors contributed by the number of copies specified
+   by the "copies" attribute, independent of whether the device can
+   process multiple copies without making multiple passes over the job
+   or document data and independent of whether the output is collated or
+   not.  Thus the value is independent of the implementation and
+   reflects the size of the document(s) measured in impressions
+   independent of the number of copies.
+
+   As with "job-k-octets", this value MUST also not include the
+   multiplicative factor due to a copies instruction embedded in the
+   document data.  If the document data actually includes replications
+   of the document data, this value will include such replication.  In
+   other words, this value is always the number of impressions in the
+   source document data, rather than a measure of the number of
+   impressions to be produced by the job.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 122]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.3.17.3 job-media-sheets (integer(0:MAX))
+
+   This attribute specifies the total number of media sheets to be
+   produced for this job.
+
+   Unlike the "job-k-octets" and the "job-impressions" attributes, this
+   value MUST include the multiplicative factors contributed by the
+   number of copies specified by the "copies" attribute and a 'number of
+   copies' instruction embedded in the document data, if any.  This
+   difference allows the system administrator to control the lower and
+   upper bounds of both (1) the size of the document(s) with "job-k-
+   octets-supported" and "job-impressions-supported" and (2) the size of
+   the job with "job-media-sheets-supported".
+
+4.3.18 Job Progress Attributes
+
+   This sub-section defines job attributes that describe the progress of
+   the job.  These attributes are intended to be counters.  That is, the
+   value for a job that has not started processing MUST be 0.  When the
+   job's "job-state" is 'processing' or 'processing-stopped', this value
+   is intended to contain the amount of the job that has been processed
+   to the time at which the attributes are requested.  When the job
+   enters the 'completed', 'canceled', or 'aborted' states, these values
+   are the final values for the job.
+
+4.3.18.1 job-k-octets-processed (integer(0:MAX))
+
+   This attribute specifies the total number of octets processed in K
+   octets, i.e., in units of 1024 octets so far.  The value MUST be
+   rounded up, so that a job between 1 and 1024 octets inclusive MUST be
+   indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc.
+
+   For implementations where multiple copies are produced by the
+   interpreter with only a single pass over the data, the final value
+   MUST be equal to the value of the "job-k-octets" attribute.  For
+   implementations where multiple copies are produced by the interpreter
+   by processing the data for each copy, the final value MUST be a
+   multiple of the value of the "job-k-octets" attribute.
+
+4.3.18.2 job-impressions-completed (integer(0:MAX))
+
+   This job attribute specifies the number of impressions completed for
+   the job so far.  For printing devices, the impressions completed
+   includes interpreting, marking, and stacking the output.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 123]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.3.18.3 job-media-sheets-completed (integer(0:MAX))
+
+   This job attribute specifies the media-sheets completed marking and
+   stacking for the entire job so far whether those sheets have been
+   processed on one side or on both.
+
+4.3.19 attributes-charset (charset)
+
+   This REQUIRED attribute is populated using the value in the client
+   supplied "attributes-charset" attribute in the create request.  It
+   identifies the charset (coded character set and encoding method) used
+   by any Job attributes with attribute syntax 'text' and 'name' that
+   were supplied by the client in the create request.  See Section 3.1.4
+   for a complete description of the "attributes-charset" operation
+   attribute.
+
+   This attribute does not indicate the charset in which the 'text' and
+   'name' values are stored internally in the Job object.  The internal
+   charset is implementation-defined.  The IPP object MUST convert from
+   whatever the internal charset is to that being requested in an
+   operation as specified in Section 3.1.4.
+
+4.3.20 attributes-natural-language (naturalLanguage)
+
+   This REQUIRED attribute is populated using the value in the client
+   supplied "attributes-natural-language" attribute in the create
+   request.  It identifies the natural language used for any Job
+   attributes with attribute syntax 'text' and 'name' that were supplied
+   by the client in the create request.  See Section 3.1.4 for a
+   complete description of the "attributes-natural-language" operation
+   attribute.  See Sections 4.1.1.2 and 4.1.2.2 for how a Natural
+   Language Override may be supplied explicitly for each 'text' and
+   'name' attribute value that differs from the value identified by the
+   "attributes-natural-language" attribute.
+
+4.4 Printer Description Attributes
+
+   These attributes form the attribute group called "printer-
+   description".  The following table summarizes these attributes, their
+   syntax, and whether or not they are REQUIRED for a Printer object to
+   support.  If they are not indicated as REQUIRED, they are OPTIONAL.
+   The maximum size in octets for 'text' and 'name' attributes is
+   indicated in parenthesizes.
+
+   Note: How these attributes are set by an Administrator is outside the
+   scope of this IPP/1.1 document.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 124]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+  +----------------------------+---------------------------+-----------+
+  |      Attribute             |     Syntax                | REQUIRED? |
+  +----------------------------+---------------------------+-----------+
+  | printer-uri-supported      | 1setOf uri                |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | uri-security-supported     | 1setOf type2 keyword      |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | uri-authentication-        | 1setOf type2 keyword      |  REQUIRED |
+  |     supported              |                           |           |
+  +----------------------------+---------------------------+-----------+
+  | printer-name               | name (127)                |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | printer-location           | text (127)                |           |
+  +----------------------------+---------------------------+-----------+
+  | printer-info               | text (127)                |           |
+  +----------------------------+---------------------------+-----------+
+  | printer-more-info          | uri                       |           |
+  +----------------------------+---------------------------+-----------+
+  | printer-driver-installer   | uri                       |           |
+  +----------------------------+---------------------------+-----------+
+  | printer-make-and-model     | text (127)                |           |
+  +----------------------------+---------------------------+-----------+
+  | printer-more-info-         | uri                       |           |
+  | manufacturer               |                           |           |
+  +----------------------------+---------------------------+-----------+
+  | printer-state              | type1 enum                |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | printer-state-reasons      | 1setOf type2 keyword      |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | printer-state-message      | text (MAX)                |           |
+  +----------------------------+---------------------------+-----------+
+  | ipp-versions-supported     | 1setOf type2 keyword      |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | operations-supported       | 1setOf type2 enum         |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | multiple-document-jobs-    | boolean                   |           |
+  |     supported              |                           |           |
+  +----------------------------+---------------------------+-----------+
+  | charset-configured         | charset                   |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | charset-supported          | 1setOf charset            |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | natural-language-configured| naturalLanguage           |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | generated-natural-language-| 1setOf naturalLanguage    |  REQUIRED |
+  | supported                  |                           |           |
+  +----------------------------+---------------------------+-----------+
+  | document-format-default    | mimeMediaType             |  REQUIRED |
+
+
+
+Hastings, et al.            Standards Track                   [Page 125]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+  +----------------------------+---------------------------+-----------+
+  | document-format-supported  | 1setOf mimeMediaType      |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | printer-is-accepting-jobs  | boolean                   |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | queued-job-count           | integer (0:MAX)           |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | printer-message-from-      | text (127)                |           |
+  | operator                   |                           |           |
+  +----------------------------+---------------------------+-----------+
+  | color-supported            | boolean                   |           |
+  +----------------------------+---------------------------+-----------+
+  | reference-uri-schemes-     | 1setOf uriScheme          |           |
+  |   supported                |                           |           |
+  +----------------------------+---------------------------+-----------+
+  | pdl-override-supported     | type2 keyword             |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | printer-up-time            | integer (1:MAX)           |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | printer-current-time       | dateTime                  |           |
+  +----------------------------+---------------------------+-----------+
+  | multiple-operation-time-out| integer (1:MAX)           |           |
+  +----------------------------+---------------------------+-----------+
+  | compression-supported      | 1setOf type3 keyword      |  REQUIRED |
+  +----------------------------+---------------------------+-----------+
+  | job-k-octets-supported     | rangeOfInteger (0:MAX)    |           |
+  +----------------------------+---------------------------+-----------+
+  | job-impressions-supported  | rangeOfInteger (0:MAX)    |           |
+  +----------------------------+---------------------------+-----------+
+  | job-media-sheets-supported | rangeOfInteger (0:MAX)    |           |
+  +----------------------------+---------------------------+-----------+
+  | pages-per-minute           | integer(0:MAX)            |           |
+  +----------------------------+---------------------------+-----------+
+  | pages-per-minute-color     | integer(0:MAX)            |           |
+  +----------------------------+---------------------------+-----------+
+
+4.4.1 printer-uri-supported (1setOf uri)
+
+   This REQUIRED Printer attribute contains at least one URI for the
+   Printer object.  It OPTIONALLY contains more than one URI for the
+   Printer object.    An administrator determines a Printer object's
+   URI(s) and configures this attribute to contain those URIs by some
+   means outside the scope of this IPP/1.1 document.  The precise format
+   of this URI is implementation dependent and depends on the protocol.
+   See the next two sections for a description of the "uri-security-
+   supported" and "uri-authentication-supported" attributes, both of
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 126]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   which are the REQUIRED companion attributes to this "printer-uri-
+   supported" attribute.  See section 2.4 on Printer object identity and
+   section 8.2 on security and URIs for more information.
+
+4.4.2 uri-authentication-supported (1setOf type2 keyword)
+
+   This REQUIRED Printer attribute MUST have the same cardinality
+   (contain the same number of values) as the "printer-uri-supported"
+   attribute.  This attribute identifies the Client Authentication
+   mechanism associated with each URI listed in the "printer-uri-
+   supported" attribute. The Printer object uses the specified mechanism
+   to identify the authenticated user (see section 8.3).  The "i th"
+   value in "uri-authentication-supported" corresponds to the "i th"
+   value in "printer-uri-supported" and it describes the authentication
+   mechanisms used by the Printer when accessed via that URI.  See
+   [RFC2910] for more details on Client Authentication.
+
+   The following standard keyword values are defined:
+
+      'none': There is no authentication mechanism associated with the
+         URI.  The Printer object assumes that the authenticated user is
+         "anonymous".
+      'requesting-user-name': When a client performs an operation whose
+         target is the associated URI, the Printer object assumes that
+         the authenticated user is specified by the "requesting-user-
+         name" Operation attribute (see section 8.3). If the
+         "requesting-user-name" attribute is absent in a request, the
+         Printer object assumes that the authenticated user is
+         "anonymous".
+      'basic': When a client performs an operation whose target is the
+         associated URI, the Printer object challenges the client with
+         HTTP basic authentication [RFC2617]. The Printer object assumes
+         that the authenticated user is the name received via the basic
+         authentication mechanism.
+      'digest': When a client performs an operation whose target is the
+         associated URI, the Printer object challenges the client with
+         HTTP digest authentication [RFC2617]. The Printer object
+         assumes that the authenticated user is the name received via
+         the digest authentication mechanism.
+      'certificate': When a client performs an operation whose target is
+         the associated URI, the Printer object expects the client to
+         provide a certificate. The Printer object assumes that the
+         authenticated user is the textual name contained within the
+         certificate.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 127]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.4.3 uri-security-supported (1setOf type2 keyword)
+
+   This REQUIRED Printer attribute MUST have the same cardinality
+   (contain the same number of values) as the "printer-uri-supported"
+   attribute.  This attribute identifies the security mechanisms used
+   for each URI listed in the "printer-uri-supported" attribute.  The "i
+   th" value in "uri-security-supported" corresponds to the "i th" value
+   in "printer-uri-supported" and it describes the security mechanisms
+   used for accessing the Printer object via that URI.  See [RFC2910]
+   for more details on security mechanisms.
+
+   The following standard keyword values are defined:
+
+      'none': There are no secure communication channel protocols in use
+         for the given URI.
+      'ssl3': SSL3 [SSL] is the secure communications channel protocol
+         in use for the given URI.
+      'tls':  TLS [RFC2246] is the secure communications channel
+         protocol in use for the given URI.
+
+   This attribute is orthogonal to the definition of a Client
+   Authentication mechanism.  Specifically, 'none' does not exclude
+   Client Authentication. See section 4.4.2.
+
+   Consider the following example.  For a single Printer object, an
+   administrator configures the "printer-uri-supported",  "uri-
+   authentication-supported" and "uri-security-supported" attributes as
+   follows:
+
+     "printer-uri-supported": 'xxx://acme.com/open-use-printer',
+        'xxx://acme.com/restricted-use-printer',
+        'xxx://acme.com/private-printer'
+     "uri-authentication-supported": 'none', 'digest', 'basic'
+     "uri-security-supported": 'none', 'none', 'tls'
+
+   Note:  'xxx'  is not a valid scheme.  See the IPP/1.1 "Transport and
+   Encoding" document [RFC2910] for the actual URI schemes to be used in
+   object target attributes.
+
+   In this case, one Printer object has three URIs.
+
+      - For the first URI, 'xxx://acme.com/open-use-printer', the value
+        'none' in "uri-security-supported" indicates that there is no
+        secure channel protocol configured to run under HTTP.  The value
+        of 'none' in "uri-authentication-supported" indicates that all
+        users are 'anonymous'.  There will be no challenge and the
+        Printer will ignore "requesting-user-name".
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 128]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - For the second URI, 'xxx://acme.com/restricted-use-printer', the
+        value 'none' in "uri-security-supported" indicates that there is
+        no secure channel protocol configured to run under HTTP. The
+        value of 'digest' in "uri-authentication-supported" indicates
+        that the Printer will issue a challenge and that the Printer
+        will use the name supplied by the digest mechanism to determine
+        the authenticated user (see section 8.3).
+      - For the third URI, 'xxx://acme.com/private-printer', the value
+        'tls' in "uri-security-supported" indicates that TLS is being
+        used to secure the channel.  The client SHOULD be prepared to
+        use TLS framing to negotiate an acceptable ciphersuite to use
+        while communicating with the Printer object.  In this case, the
+        name implies the use of a secure communications channel, but the
+        fact is made explicit by the presence of the 'tls' value in
+        "uri-security-supported".  The client does not need to resort to
+        understanding which security it must use by following naming
+        conventions or by parsing the URI to determine which security
+        mechanisms are implied.  The value of 'basic' in "uri-
+        authentication-supported" indicates that the Printer will issue
+        a challenge and that the Printer will use the name supplied by
+        the digest mechanism to determine the authenticated user (see
+        section 8.3).  Because this challenge occurs in a tls session,
+        the channel is secure.
+
+   It is expected that many IPP Printer objects will be configured to
+   support only one channel (either configured to use TLS access or not)
+   and only one authentication mechanism. Such Printer objects only have
+   one URI listed in the "printer-uri-supported" attribute.  No matter
+   the configuration of the Printer object (whether it has only one URI
+   or more than one URI), a client MUST supply only one URI in the
+   target "printer-uri" operation attribute.
+
+4.4.4 printer-name (name(127))
+
+   This REQUIRED Printer attribute contains the name of the Printer
+   object.  It is a name that is more end-user friendly than a URI. An
+   administrator determines a printer's name and sets this attribute to
+   that name. This name may be the last part of the printer's URI or it
+   may be unrelated.  In non-US-English locales, a name may contain
+   characters that are not allowed in a URI.
+
+4.4.5 printer-location (text(127))
+
+   This Printer attribute identifies the location of the device. This
+   could include things like: "in Room 123A, second floor of building
+   XYZ".
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 129]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.4.6 printer-info (text(127))
+
+   This Printer attribute identifies the descriptive information about
+   this Printer object.  This could include things like: "This printer
+   can be used for printing color transparencies for HR presentations",
+   or "Out of courtesy for others, please print only small (1-5 page)
+   jobs at this printer", or even "This printer is going away on July 1,
+   1997, please find a new printer".
+
+4.4.7 printer-more-info (uri)
+
+   This Printer attribute contains a URI used to obtain more information
+   about this specific Printer object.  For example, this could be an
+   HTTP type URI referencing an HTML page accessible to a Web Browser.
+   The information obtained from this URI is intended for end user
+   consumption.  Features outside the scope of IPP can be accessed from
+   this URI.  The information is intended to be specific to this printer
+   instance and site specific services (e.g. job pricing, services
+   offered, end user assistance). The device manufacturer may initially
+   populate this attribute.
+
+4.4.8 printer-driver-installer (uri)
+
+   This Printer attribute contains a URI to use to locate the driver
+   installer for this Printer object.   This attribute is intended for
+   consumption by automata.  The mechanics of print driver installation
+   is outside the scope of this IPP/1.1 document.  The device
+   manufacturer may initially populate this attribute.
+
+4.4.9 printer-make-and-model (text(127))
+
+   This Printer attribute identifies the make and model of the device.
+   The device manufacturer may initially populate this attribute.
+
+4.4.10 printer-more-info-manufacturer (uri)
+
+   This Printer attribute contains a URI used to obtain more information
+   about this type of device.  The information obtained from this URI is
+   intended for end user consumption.  Features outside the scope of IPP
+   can be accessed from this URI (e.g., latest firmware, upgrades, print
+   drivers, optional features available, details on color support).  The
+   information is intended to be germane to this printer without regard
+   to site specific modifications or services. The device manufacturer
+   may initially populate this attribute.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 130]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.4.11 printer-state (type1 enum)
+
+   This REQUIRED Printer attribute identifies the current state of the
+   device.  The "printer-state reasons" attribute augments the
+   "printer-state" attribute to give more detailed information about the
+   Printer in the given printer state.
+
+   A Printer object need only update this attribute before responding to
+   an operation which requests the attribute; the Printer object NEED
+   NOT update this attribute continually, since asynchronous event
+   notification is not part of IPP/1.1.  A Printer NEED NOT implement
+   all values if they are not applicable to a given implementation.
+
+   The following standard enum values are defined:
+
+   Value  Symbolic Name and Description
+
+   '3'    'idle':  Indicates that new jobs can start processing without
+                waiting.
+   '4'    'processing':  Indicates that jobs are processing; new jobs
+                will wait before processing.
+   '5'    'stopped':  Indicates that no jobs can be processed and
+                intervention is required.
+
+   Values of "printer-state-reasons", such as 'spool-area-full' and
+   'stopped-partly', MAY be used to provide further information.
+
+4.4.12 printer-state-reasons (1setOf type2 keyword)
+
+   This REQUIRED Printer attribute supplies additional detail about the
+   device's state.  Some of the these value definitions indicate
+   conformance requirements; the rest are OPTIONAL.
+
+   Each keyword value MAY have a suffix to indicate its level of
+   severity.  The three levels are: report (least severe), warning, and
+   error (most severe).
+
+      - '-report':  This suffix indicates that the reason is a "report".
+        An implementation may choose to omit some or all reports. Some
+        reports specify finer granularity about the printer state;
+        others serve as a precursor to a warning. A report MUST contain
+        nothing that could affect the printed output.
+      - '-warning': This suffix indicates that the reason is a
+        "warning".  An implementation may choose to omit some or all
+        warnings. Warnings serve as a precursor to an error. A warning
+        MUST contain nothing that prevents a job from completing, though
+        in some cases the output may be of lower quality.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 131]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - '-error': This suffix indicates that the reason is an "error".
+        An implementation MUST include all errors. If this attribute
+        contains one or more errors, printer MUST be in the stopped
+        state.
+
+   If the implementation does not add any one of the three suffixes, all
+   parties MUST assume that the reason is an "error".
+
+   If a Printer object controls more than one output device, each value
+   of this attribute MAY apply to one or more of the output devices.  An
+   error on one output device that does not stop the Printer object as a
+   whole MAY appear as a warning in the Printer's "printer-state-reasons
+   attribute".  If the "printer-state" for such a Printer has a value of
+   'stopped', then there MUST be an error reason among the values in the
+   "printer-state-reasons" attribute.
+
+   The following standard keyword values are defined:
+
+      'other': The device has detected an error other than one listed in
+         this document.
+      'none': There are not reasons. This state reason is semantically
+         equivalent to "printer-state-reasons" without any value and
+         MUST be used, since the 1setOf attribute syntax requires at
+         least one value.
+      'media-needed': A tray has run out of media.
+      'media-jam': The device has a media jam.
+      'moving-to-paused':  Someone has paused the Printer object using
+         the Pause-Printer operation (see section 3.2.7) or other means,
+         but the device(s) are taking an appreciable time to stop.
+         Later, when all output has stopped, the "printer-state" becomes
+         'stopped', and the 'paused' value replaces the 'moving-to-
+         paused' value in the "printer-state-reasons" attribute.  This
+         value MUST be supported, if the Pause-Printer operation is
+         supported and the implementation takes significant time to
+         pause a device in certain circumstances.
+      'paused': Someone has paused the Printer object using the Pause-
+         Printer operation (see section 3.2.7) or other means and the
+         Printer object's "printer-state" is 'stopped'.  In this state,
+         a Printer MUST NOT produce printed output, but it MUST perform
+         other operations requested by a client.  If a Printer had been
+         printing a job when the Printer was paused, the Printer MUST
+         resume printing that job when the Printer is no longer paused
+         and leave no evidence in the printed output of such a pause.
+         This value MUST be supported, if the Pause-Printer operation is
+         supported.
+      'shutdown': Someone has removed a Printer object from service, and
+         the device may be powered down or physically removed.  In this
+         state, a Printer object MUST NOT produce printed output, and
+
+
+
+Hastings, et al.            Standards Track                   [Page 132]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         unless the Printer object is realized by a print server that is
+         still active, the Printer object MUST perform no other
+         operations requested by a client, including returning this
+         value. If a Printer object had been printing a job when it was
+         shutdown, the Printer NEED NOT resume printing that job when
+         the Printer is no longer shutdown. If the Printer resumes
+         printing such a job, it may leave evidence in the printed
+         output of such a shutdown, e.g. the part printed before the
+         shutdown may be printed a second time after the shutdown.
+      'connecting-to-device': The Printer object has scheduled a job on
+         the output device and is in the process of connecting to a
+         shared network output device (and might not be able to actually
+         start printing the job for an arbitrarily long time depending
+         on the usage of the output device by other servers on the
+         network).
+      'timed-out': The server was able to connect to the output device
+         (or is always connected), but was unable to get a response from
+         the output device.
+      'stopping': The Printer object is in the process of stopping the
+         device and will be stopped in a while. When the device is
+         stopped, the Printer object will change the Printer object's
+         state to 'stopped'.  The 'stopping-warning' reason is never an
+         error, even for a Printer with a single output device.  When an
+         output-device ceases accepting jobs, the Printer will have this
+         reason while the output device completes printing.
+      'stopped-partly': When a Printer object controls more than one
+         output device, this reason indicates that one or more output
+         devices are stopped.  If the reason is a report, fewer than
+         half of the output devices are stopped.  If the reason is a
+         warning, fewer than all of the output devices are stopped.
+      'toner-low': The device is low on toner.
+      'toner-empty':  The device is out of toner.
+      'spool-area-full': The limit of persistent storage allocated for
+         spooling has been reached.  The Printer is temporarily unable
+         to accept more jobs.  The Printer will remove this value when
+         it is able to accept more jobs.  This value SHOULD be used by a
+         non-spooling Printer that only accepts one or a small number
+         jobs at a time or a spooling Printer that has filled the spool
+         space.
+      'cover-open': One or more covers on the device are open.
+      'interlock-open': One or more interlock devices on the printer are
+         unlocked.
+      'door-open': One or more doors on the device are open.
+      'input-tray-missing': One or more input trays are not in the
+         device.
+      'media-low': At least one input tray is low on media.
+      'media-empty': At least one input tray is empty.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 133]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      'output-tray-missing': One or more output trays are not in the
+         device
+      'output-area-almost-full': One or more output area is almost full
+         (e.g. tray, stacker, collator).
+      'output-area-full': One or more output area is full. (e.g. tray,
+         stacker, collator)
+      'marker-supply-low': The device is low on at least one marker
+         supply.  (e.g. toner, ink, ribbon)
+      'marker-supply-empty: The device is out of at least one marker
+         supply. (e.g. toner, ink, ribbon)
+      'marker-waste-almost-full': The device marker supply waste
+         receptacle is almost full.
+      'marker-waste-full': The device marker supply waste receptacle is
+         full.
+      'fuser-over-temp': The fuser temperature is above normal.
+      'fuser-under-temp': The fuser temperature is below normal.
+      'opc-near-eol': The optical photo conductor is near end of life.
+      'opc-life-over': The optical photo conductor is no longer
+         functioning.
+      'developer-low': The device is low on developer.
+      'developer-empty: The device is out of developer.
+      'interpreter-resource-unavailable': An interpreter resource is
+         unavailable (i.e. font, form)
+
+4.4.13 printer-state-message (text(MAX))
+
+   This Printer attribute specifies information about the "printer-
+   state" and "printer-state-reasons" attributes in human readable text.
+   If the Printer object supports this attribute, the Printer object
+   MUST be able to generate this message in any of the natural languages
+   identified by the Printer's "generated-natural-language-supported"
+   attribute (see the "attributes-natural-language" operation attribute
+   specified in Section 3.1.4.1).
+
+4.4.14 ipp-versions-supported (1setOf type2 keyword)
+
+   This REQUIRED attribute identifies the IPP protocol version(s) that
+   this Printer supports, including major and minor versions, i.e., the
+   version numbers for which this Printer implementation meets the
+   conformance requirements.  For version number validation, the Printer
+   matches the (two-octet binary) "version-number" parameter supplied by
+   the client in each request (see sections 3.1.1 and 3.1.8) with the
+   (US-ASCII) keyword values of this attribute.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 134]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The following standard keyword values are defined:
+
+      '1.0': Meets the conformance requirement of IPP version 1.0 as
+         specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565]
+         including any extensions registered according to Section 6 and
+         any extension defined in this version or any future version of
+         the IPP "Model and Semantics" document or the IPP "Encoding and
+         Transport" document following the rules, if any, when the
+         "version-number" parameter is '1.0'.
+      '1.1': Meets the conformance requirement of IPP version 1.1 as
+         specified in this document and [RFC2910] including any
+         extensions registered according to Section 6 and any extension
+         defined in any future versions of the IPP "Model and Semantics"
+         document or the IPP Encoding and Transport document following
+         the rules, if any, when the "version-number" parameter is
+         '1.1'.
+
+4.4.15 operations-supported (1setOf type2 enum)
+
+   This REQUIRED Printer attribute specifies the set of supported
+   operations for this Printer object and contained Job objects.
+
+   This attribute is encoded as any other enum attribute syntax
+   according to [RFC2910] as 32-bits.  However, all 32-bit enum values
+   for this attribute MUST NOT exceed 0x00008FFF, since these same
+   values are also passed in two octets in the "operation-id" parameter
+   (see section 3.1.1) in each Protocol request with the two high order
+   octets omitted in order to indicate the operation being performed
+   [RFC2910].
+
+   The following standard enum and "operation-id" (see section 3.1.2)
+   values are defined:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 135]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+     Value               Operation Name
+     -----------------   -------------------------------------
+
+     0x0000              reserved, not used
+     0x0001              reserved, not used
+     0x0002              Print-Job
+     0x0003              Print-URI
+     0x0004              Validate-Job
+     0x0005              Create-Job
+     0x0006              Send-Document
+     0x0007              Send-URI
+     0x0008              Cancel-Job
+     0x0009              Get-Job-Attributes
+     0x000A              Get-Jobs
+     0x000B              Get-Printer-Attributes
+     0x000C              Hold-Job
+     0x000D              Release-Job
+     0x000E              Restart-Job
+     0x000F              reserved for a future operation
+     0x0010              Pause-Printer
+     0x0011              Resume-Printer
+     0x0012              Purge-Jobs
+     0x0013-0x3FFF       reserved for future IETF standards track
+                         operations (see section 6.4)
+     0x4000-0x8FFF       reserved for vendor extensions (see section 6.4)
+
+4.4.16 multiple-document-jobs-supported (boolean)
+
+   This Printer attribute indicates whether or not the Printer supports
+   more than one document per job, i.e., more than one Send-Document or
+   Send-Data operation with document data.  If the Printer supports the
+   Create-Job and Send-Document operations (see section 3.2.4 and
+   3.3.1), it MUST support this attribute.
+
+4.4.17 charset-configured (charset)
+
+   This REQUIRED Printer attribute identifies the charset that the
+   Printer object has been configured to represent 'text' and 'name'
+   Printer attributes that are set by the operator, system
+   administrator, or manufacturer, i.e., for "printer-name" (name),
+   "printer-location" (text), "printer-info" (text), and "printer-make-
+   and-model" (text).  Therefore, the value of the Printer object's
+   "charset-configured" attribute MUST also be among the values of the
+   Printer object's "charset-supported" attribute.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 136]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.4.18 charset-supported (1setOf charset)
+
+   This REQUIRED Printer attribute identifies the set of charsets that
+   the Printer and contained Job objects support in attributes with
+   attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST
+   be present, since IPP objects MUST support the UTF-8 [RFC2279]
+   charset.  If a Printer object supports a charset, it means that for
+   all attributes of syntax 'text' and 'name' the IPP object MUST (1)
+   accept the charset in requests and return the charset in responses as
+   needed.
+
+   If more charsets than UTF-8 are supported, the IPP object MUST
+   perform charset conversion between the charsets as described in
+   Section 3.1.4.2.
+
+4.4.19 natural-language-configured (naturalLanguage)
+
+   This REQUIRED Printer attribute identifies the natural language that
+   the Printer object has been configured to represent 'text' and 'name'
+   Printer attributes that are set by the operator, system
+   administrator, or manufacturer, i.e., for "printer-name" (name),
+   "printer-location" (text), "printer-info" (text), and "printer-make-
+   and-model" (text).  When returning these Printer attributes, the
+   Printer object MAY return them in the configured natural language
+   specified by this attribute, instead of the natural language
+   requested by the client in the "attributes-natural-language"
+   operation attribute.  See Section 3.1.4.1 for the specification of
+   the OPTIONAL multiple natural language support.  Therefore, the value
+   of the Printer object's "natural-language-configured" attribute MUST
+   also be among the values of the Printer object's "generated-natural-
+   language-supported" attribute.
+
+4.4.20 generated-natural-language-supported (1setOf naturalLanguage)
+
+   This REQUIRED Printer attribute identifies the natural language(s)
+   that the Printer object and contained Job objects support in
+   attributes with attribute syntax 'text' and 'name'.  The natural
+   language(s) supported depends on implementation and/or configuration.
+   Unlike charsets, IPP objects MUST accept requests with any natural
+   language or any Natural Language Override whether the natural
+   language is supported or not.
+
+   If a Printer object supports a natural language, it means that for
+   any of the attributes for which the Printer or Job object generates
+   messages, i.e., for the "job-state-message" and "printer-state-
+   message" attributes and Operation Messages (see Section 3.1.5) in
+   operation responses, the Printer and Job objects MUST be able to
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 137]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   generate messages in any of the Printer's supported natural
+   languages.  See section 3.1.4 for the definition of 'text' and 'name'
+   attributes in operation requests and responses.
+
+   Note: A Printer object that supports multiple natural languages,
+   often has separate catalogs of messages, one for each natural
+   language supported.
+
+4.4.21 document-format-default (mimeMediaType)
+
+   This REQUIRED Printer attribute identifies the document format that
+   the Printer object has been configured to assume if the client does
+   not supply a "document-format" operation attribute in any of the
+   operation requests that supply document data.  The standard values
+   for this attribute are Internet Media types (sometimes called MIME
+   types).  For further details see the description of the
+   'mimeMediaType' attribute syntax in Section 4.1.9.
+
+4.4.22 document-format-supported (1setOf mimeMediaType)
+
+   This REQUIRED Printer attribute identifies the set of document
+   formats that the Printer object and contained Job objects can
+   support. For further details see the description of the
+   'mimeMediaType' attribute syntax in Section 4.1.9.
+
+4.4.23 printer-is-accepting-jobs (boolean)
+
+   This REQUIRED Printer attribute indicates whether the printer is
+   currently able to accept jobs, i.e., is accepting Print-Job, Print-
+   URI, and Create-Job requests.  If the value is 'true', the printer is
+   accepting jobs.  If the value is 'false', the Printer object is
+   currently rejecting any jobs submitted to it.  In this case, the
+   Printer object returns the 'server-error-not-accepting-jobs' status
+   code.
+
+   This value is independent of the "printer-state" and "printer-state-
+   reasons" attributes because its value does not affect the current
+   job; rather it affects future jobs.  This attribute, when 'false',
+   causes the Printer to reject jobs even when the "printer-state" is
+   'idle' or, when 'true', causes the Printer object to accepts jobs
+   even when the "printer-state" is 'stopped'.
+
+4.4.24 queued-job-count (integer(0:MAX))
+
+   This REQUIRED Printer attribute contains a count of the number of
+   jobs that are either 'pending', 'processing', 'pending-held', or
+   'processing-stopped' and is set by the Printer object.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 138]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+4.4.25 printer-message-from-operator (text(127))
+
+   This Printer attribute provides a message from an operator, system
+   administrator or "intelligent" process to indicate to the end user
+   information or status of the printer, such as why it is unavailable
+   or when it is expected to be available.
+
+4.4.26 color-supported (boolean)
+
+   This Printer attribute identifies whether the device is capable of
+   any type of color printing at all, including highlight color.  All
+   document instructions having to do with color are embedded within the
+   document PDL (none are external IPP attributes in IPP/1.1).
+
+   Note:  end-users are able to determine the nature and details of the
+   color support by querying the "printer-more-info-manufacturer"
+   Printer attribute.
+
+4.4.27 reference-uri-schemes-supported (1setOf uriScheme)
+
+   This Printer attribute specifies which URI schemes are supported for
+   use in the "document-uri" operation attribute of the Print-URI or
+   Send-URI operation.  If a Printer object supports these optional
+   operations, it MUST support the "reference-uri-schemes-supported"
+   Printer attribute with at least the following schemed URI value:
+
+      'ftp':  The Printer object will use an FTP 'get' operation as
+         defined in RFC 2228 [RFC2228] using FTP URLs as defined by
+         [RFC2396] and [RFC2316].
+
+   The Printer object MAY OPTIONALLY support other URI schemes (see
+   section 4.1.6).
+
+4.4.28 pdl-override-supported (type2 keyword)
+
+   This REQUIRED Printer attribute expresses the ability for a
+   particular Printer implementation to either attempt to override
+   document data instructions with IPP attributes or not.
+
+   This attribute takes on the following keyword values:
+
+      - 'attempted': This value indicates that the Printer object
+         attempts to make the IPP attribute values take precedence over
+         embedded instructions in the document data, however there is no
+         guarantee.
+      - 'not-attempted': This value indicates that the Printer object
+         makes no attempt to make the IPP attribute values take
+         precedence over embedded instructions in the document data.
+
+
+
+Hastings, et al.            Standards Track                   [Page 139]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Section 15 contains a full description of how this attribute
+   interacts with and affects other IPP attributes, especially the
+   "ipp-attribute-fidelity" attribute.
+
+4.4.29 printer-up-time (integer(1:MAX))
+
+   This REQUIRED Printer attribute indicates the amount of time (in
+   seconds) that this Printer instance has been up and running.  The
+   value is a monotonically increasing value starting from 1 when the
+   Printer object is started-up (initialized, booted, etc.).  This value
+   is used to populate the Event Time Job Description Job attributes
+   "time-at-creation", "time-at-processing", and "time-at-completed"
+   (see section 4.3.14).
+
+   If the Printer object goes down at some value 'n', and comes back up,
+   the implementation MAY:
+
+      1. Know how long it has been down, and resume at some value
+         greater than 'n', or
+      2. Restart from 1.
+
+   In other words, if the device or devices that the Printer object is
+   representing are restarted or power cycled, the Printer object MAY
+   continue counting this value or MAY reset this value to 1 depending
+   on implementation.  However, if the Printer object software ceases
+   running, and restarts without knowing the last value for "printer-
+   up-time", the implementation MUST reset this value to 1.  If this
+   value is reset and the Printer has persistent jobs, the Printer MUST
+   reset the "time-at-xxx(integer) Event Time Job Description attributes
+   according to Section 4.3.14.  An implementation MAY use both
+   implementation alternatives, depending on warm versus cold start,
+   respectively.
+
+4.4.30 printer-current-time (dateTime)
+
+   This Printer attribute indicates the current date and time.  This
+   value is used to populate the Event Time Job Description attributes:
+   "date-time-at-creation", "date-time-at-processing", and "date-time-
+   at-completed" (see Section 4.3.14).
+
+   The date and time is obtained on a "best efforts basis" and does not
+   have to be that precise in order to work in practice.  A Printer
+   implementation sets the value of this attribute by obtaining the date
+   and time via some implementation-dependent means, such as getting the
+   value from a network time server, initialization at time of
+   manufacture, or setting by an administrator.  See [IPP-IIG] for
+   examples.  If an implementation supports this attribute and the
+   implementation knows that it has not yet been set, then the
+
+
+
+Hastings, et al.            Standards Track                   [Page 140]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   implementation MUST return the value of this attribute using the
+   out-of-band 'no-value' meaning not configured.  See the beginning of
+   section 4.1.
+
+   The time zone of this attribute NEED NOT be the time zone used by
+   people located near the Printer object or device.  The client MUST
+   NOT expect that the time zone of any received 'dateTime' value to be
+   in the time zone of the client or in the time zone of the people
+   located near the printer.
+
+   The client SHOULD display any dateTime attributes to the user in
+   client local time by converting the 'dateTime' value returned by the
+   server to the time zone of the client, rather than using the time
+   zone returned by the Printer in attributes that use the 'dateTime'
+   attribute syntax.
+
+4.4.31 multiple-operation-time-out (integer(1:MAX))
+
+   This Printer attributes identifies the minimum time (in seconds) that
+   the Printer object waits for additional Send-Document or Send-URI
+   operations to follow a still-open Job object before taking  any
+   recovery actions, such as the ones indicated in section 3.3.1.  If
+   the Printer object supports the Create-Job and Send-Document
+   operations (see section 3.2.4 and 3.3.1), it MUST support this
+   attribute.
+
+   It is RECOMMENDED that vendors supply a value for this attribute that
+   is between 60 and 240 seconds.  An implementation MAY allow a system
+   administrator to set this attribute (by means outside this IPP/1.1
+   document).  If so, the system administrator MAY be able to set values
+   outside this range.
+
+4.4.32 compression-supported (1setOf type3 keyword)
+
+   This REQUIRED Printer attribute identifies the set of supported
+   compression algorithms for document data.  Compression only applies
+   to the document data; compression does not apply to the encoding of
+   the IPP operation itself.  The supported values are used to validate
+   the client supplied "compression" operation attributes in Print-Job,
+   Send-Document, and Send-URI requests.
+
+   Standard keyword values are :
+
+   'none': no compression is used.
+   'deflate':  ZIP public domain inflate/deflate) compression technology
+      in RFC 1951 [RFC1951]
+   'gzip' GNU zip compression technology described in RFC 1952
+      [RFC1952].
+
+
+
+Hastings, et al.            Standards Track                   [Page 141]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   'compress': UNIX compression technology in RFC 1977 [RFC1977]
+
+4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX))
+
+   This Printer attribute specifies the upper and lower bounds of total
+   sizes of jobs in K octets, i.e., in units of 1024 octets. The
+   supported values are used to validate the client supplied "job-k-
+   octets" operation attributes in create requests.  The corresponding
+   job description attribute "job-k-octets" is defined in section
+   4.3.17.1.
+
+4.4.34 job-impressions-supported (rangeOfInteger(0:MAX))
+
+   This Printer attribute specifies the upper and lower bounds for the
+   number of impressions per job. The supported values are used to
+   validate the client supplied "job-impressions" operation attributes
+   in create requests.  The corresponding job description attribute
+   "job-impressions" is defined in section 4.3.17.2.
+
+4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX))
+
+   This Printer attribute specifies the upper and lower bounds for the
+   number of media sheets per job. The supported values are used to
+   validate the client supplied "job-media-sheets" operation attributes
+   in create requests.  The corresponding Job attribute "job-media-
+   sheets" is defined in section 4.3.17.3.
+
+4.4.36 pages-per-minute (integer(0:MAX))
+
+   This Printer attributes specifies the nominal number of pages per
+   minute to the nearest whole number which may be generated by this
+   printer (e.g., simplex, black-and-white).  This attribute is
+   informative, not a service guarantee.  Generally, it is the value
+   used in the marketing literature to describe the device.
+
+   A value of 0 indicates a device that takes more than two minutes to
+   process a page.
+
+4.4.37 pages-per-minute-color (integer(0:MAX))
+
+   This Printer attributes specifies the nominal number of pages per
+   minute to the nearest whole number which may be generated by this
+   printer when printing color (e.g., simplex, color).  For purposes of
+   this attribute, "color" means the same as for the "color-supported"
+   attribute, namely, the device is capable of any type of color
+   printing at all, including highlight color.  This attribute is
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 142]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   informative, not a service guarantee.  Generally, it is the value
+   used in the marketing literature to describe the color capabilities
+   of this device.
+
+   A value of 0 indicates a device that takes more than two minutes to
+   process a page.
+
+   If a color device has several color modes, it MAY use the pages-per-
+   minute value for this attribute that corresponds to the mode that
+   produces the highest number.
+
+   Black and white only printers MUST NOT support this attribute.  If
+   this attribute is present, then the "color-supported" Printer
+   description attribute MUST be present and have a 'true' value.
+
+   The values of these two attributes returned by the Get-Printer-
+   Attributes operation MAY be affected by the "document-format"
+   attribute supplied by the client in the Get-Printer-Attributes
+   request.  In other words, the implementation MAY have different
+   speeds depending on the document format being processed.  See section
+   3.2.5.1 Get-Printer-Attributes.
+
+5. Conformance
+
+   This section describes conformance issues and requirements. This
+   document introduces model entities such as objects, operations,
+   attributes, attribute syntaxes, and attribute values.  These
+   conformance sections describe the conformance requirements which
+   apply to these model entities.
+
+5.1 Client Conformance Requirements
+
+   This section describes the conformance requirements for a client (see
+   section 2.1), whether it be:
+
+      1. contained within software controlled by an end user, e.g.
+         activated by the "Print" menu item in an application that sends
+         IPP requests or
+
+      2. the print server component that sends IPP requests to either an
+         output device or another "downstream" print server.
+
+   A conforming client MUST support all REQUIRED operations as defined
+   in this document.  For each attribute included in an operation
+   request, a conforming client MUST supply a value whose type and value
+   syntax conforms to the requirements of the Model document as
+   specified in Sections 3 and 4.  A conforming client MAY supply any
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 143]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   IETF standards track extensions and/or vendor extensions in an
+   operation request, as long as the extensions meet the requirements in
+   Section 6.
+
+   Otherwise, there are no conformance requirements placed on the user
+   interfaces provided by IPP clients or their applications.  For
+   example, one application might not allow an end user to submit
+   multiple documents per job, while another does.  One application
+   might first query a Printer object in order to supply a graphical
+   user interface (GUI) dialogue box with supported and default values
+   whereas a different implementation might not.
+
+   When sending a request, an IPP client NEED NOT supply any attributes
+   that are indicated as OPTIONALLY supplied by the client.
+
+   A client MUST be able to accept any of the attribute syntaxes defined
+   in Section 4.1, including their full range, that may be returned to
+   it in a response from a Printer object.  In particular for each
+   attribute that the client supports whose attribute syntax is 'text',
+   the client MUST accept and process both the 'textWithoutLanguage' and
+   'textWithLanguage' forms.  Similarly, for each attribute that the
+   client supports whose attribute syntax is 'name', the client MUST
+   accept and process both the 'nameWithoutLanguage' and
+   'nameWithLanguage' forms.  For presentation purposes, truncation of
+   long attribute values is not recommended.  A recommended approach
+   would be for the client implementation to allow the user to scroll
+   through long attribute values.
+
+   A response MAY contain attribute groups, attributes, attribute
+   syntaxes, values, and status codes that the client does not expect.
+   Therefore, a client implementation MUST gracefully handle such
+   responses and not refuse to inter-operate with a conforming Printer
+   that is returning IETF standards track extension or vendor
+   extensions, including attribute groups, attributes, attribute
+   syntaxes, attribute values, status codes, and out-of-band attribute
+   values that conform to Section 6.  Clients may choose to ignore any
+   parameters, attribute groups, attributes, attribute syntaxes, or
+   values that they do not understand.
+
+   While a client is sending data to a printer, it SHOULD do its best to
+   prevent a channel from being closed by a lower layer when the channel
+   is blocked (i.e. flow-controlled off) for whatever reason, e.g. 'out
+   of paper' or 'job ahead hasn't freed up enough memory'.  However, the
+   layer that launched the print submission (e.g. an end user) MAY close
+   the channel in order to cancel the job.  When a client closes a
+   channel, a Printer MAY print all or part of the received portion of
+   the document.  See the "Encoding and Transport" document [RFC2910]
+   for more details.
+
+
+
+Hastings, et al.            Standards Track                   [Page 144]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   A client MUST support Client Authentication as defined in the IPP/1.1
+   Encoding and Transport document [RFC2910].  A client SHOULD support
+   Operation Privacy and Server Authentication as defined in the IPP/1.1
+   Encoding and Transport document [RFC2910].  See also section 8 of
+   this document.
+
+5.2 IPP Object Conformance Requirements
+
+   This section specifies the conformance requirements for conforming
+   implementations of IPP objects (see section 2).  These requirements
+   apply to an IPP object whether it is:
+
+      (1) an (embedded) device component that accepts IPP requests and
+      controls the device or
+
+      (2) a component of a print server that accepts IPP requests (where
+      the print server control one or more networked devices using IPP or
+      other protocols).
+
+5.2.1 Objects
+
+   Conforming implementations MUST implement all of the model objects as
+   defined in this document in the indicated sections:
+
+      Section 2.1 - Printer Object
+      Section 2.2 - Job Object
+
+5.2.2 Operations
+
+   Conforming IPP object implementations MUST implement all of the
+   REQUIRED model operations, including REQUIRED responses, as defined
+   in this document in the indicated sections:
+
+      For a Printer object:
+         Print-Job (section 3.2.1)               REQUIRED
+         Print-URI (section 3.2.2)               OPTIONAL
+         Validate-Job (section 3.2.3)            REQUIRED
+         Create-Job (section 3.2.4)              OPTIONAL
+         Get-Printer-Attributes (section 3.2.5)  REQUIRED
+         Get-Jobs (section 3.2.6)                REQUIRED
+         Pause-Printer (section 3.2.7)           OPTIONAL
+         Resume-Printer (section 3.2.8)          OPTIONAL
+         Purge-Jobs (section 3.2.9)              OPTIONAL
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 145]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      For a Job object:
+         Send-Document (section 3.3.1)           OPTIONAL
+         Send-URI (section 3.3.2)                OPTIONAL
+         Cancel-Job (section 3.3.3)              REQUIRED
+         Get-Job-Attributes (section 3.3.4)      REQUIRED
+         Hold-Job (section 3.3.5)                OPTIONAL
+         Release-Job (section 3.3.6)             OPTIONAL
+         Restart-Job (section 3.3.7)             OPTIONAL
+
+   Conforming IPP objects MUST support all REQUIRED operation attributes
+   and all values of such attributes if so indicated in the description.
+   Conforming IPP objects MUST ignore all unsupported or unknown
+   operation attributes or operation attribute groups received in a
+   request, but MUST reject a request that contains a supported
+   operation attribute that contains an unsupported value.
+
+   Conforming IPP objects MAY return operation responses that contain
+   attributes groups, attributes names,  attribute syntaxes, attribute
+   values, and status codes that are extensions to this standard.  The
+   additional attribute groups MAY occur in any order.
+
+   The following section on object attributes specifies the support
+   required for object attributes.
+
+5.2.3 IPP Object Attributes
+
+   Conforming IPP objects MUST support all of the REQUIRED object
+   attributes, as defined in this document in the indicated sections.
+
+   If an object supports an attribute, it MUST support only those values
+   specified in this document or through the extension mechanism
+   described in section 5.2.4. It MAY support any non-empty subset of
+   these values.  That is, it MUST support at least one of the specified
+   values and at most all of them.
+
+5.2.4 Versions
+
+   IPP/1.1 clients MUST meet the conformance requirements for clients
+   specified in this document and [RFC2910].  IPP/1.1 clients MUST send
+   requests containing a "version-number" parameter with a '1.1' value.
+
+   IPP/1.1 Printer and Job objects MUST meet the conformance
+   requirements for IPP objects specified in this document and
+   [RFC2910].   IPP/1.1 objects MUST accept requests containing a
+   "version-number" parameter with a '1.1' value (or reject the request
+   if the operation is not supported).
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 146]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   It is beyond the scope of this specification to mandate conformance
+   with previous versions.  IPP/1.1 was deliberately designed, however,
+   to make supporting previous versions easy.  It is worth noting that,
+   at the time of composing this specification (1999), we would expect
+   IPP/1.1 Printer implementations to:
+
+     understand any valid request in the format of IPP/1.0, or 1.1;
+
+     respond appropriately with a response containing the same
+     "version-number" parameter value used by the client in the request.
+
+   And we would expect IPP/1.1 clients to:
+
+     understand any valid response in the format of IPP/1.0, or 1.1.
+
+   It is recommended that IPP/1.1 clients try supplying alternate
+   version numbers if they receive a 'server-error-version-not-
+   supported' error return in a response.
+
+5.2.5 Extensions
+
+   A conforming IPP object MAY support IETF standards track extensions
+   and vendor extensions, as long as the extensions meet the
+   requirements specified in Section 6.
+
+   For each attribute included in an operation response, a conforming
+   IPP object MUST return a value whose type and value syntax conforms
+   to the requirement of the Model document as specified in Sections 3
+   and 4.
+
+5.2.6 Attribute Syntaxes
+
+   An IPP object MUST be able to accept any of the attribute syntaxes
+   defined in Section 4.1, including their full range, in any operation
+   in which a client may supply attributes or the system administrator
+   may configure attributes (by means outside the scope of this IPP/1.1
+   document).  In particular for each attribute that the IPP object
+   supports whose attribute syntax is 'text', the IPP object MUST accept
+   and process both the 'textWithoutLanguage' and 'textWithLanguage'
+   forms.  Similarly, for each attribute that the IPP object supports
+   whose attribute syntax is 'name', the IPP object MUST accept and
+   process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms.
+   Furthermore, an IPP object MUST return attributes to the client in
+   operation responses that conform to the syntax specified in Section
+   4.1, including their full range if supplied previously by a client.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 147]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+5.2.7 Security
+
+   An IPP Printer implementation SHOULD contain support for Client
+   Authentication as defined in the IPP/1.1 Encoding and Transport
+   document [RFC2910].  A Printer implementation MAY allow an
+   administrator to configure the Printer so that all, some, or none of
+   the users are authenticated.  See also section 8 of this document.
+
+   An IPP Printer implementation SHOULD contain support for Operation
+   Privacy and Server Authentication as defined in the IPP/1.1 Encoding
+   and Transport document [RFC2910].  A Printer implementation MAY allow
+   an administrator to configure the degree of support for Operation
+   Privacy and Server Authentication.  See also section 8 of this
+   document.
+
+   Security MUST NOT be compromised when a client supplies a lower
+   "version-number" parameter in a request.  For example, if an IPP/1.1
+   conforming Printer object accepts version '1.0' requests and is
+   configured to enforce Digest Authentication, it MUST do the same for
+   a version '1.0' request.
+
+5.3 Charset and Natural Language Requirements
+
+   All clients and IPP objects MUST support the 'utf-8' charset as
+   defined in section 4.1.7.
+
+   IPP objects MUST be able to accept any client request which correctly
+   uses the "attributes-natural-language" operation attribute or the
+   Natural Language Override mechanism on any individual attribute
+   whether or not the natural language is supported by the IPP object.
+   If an IPP object supports a natural language, then it MUST be able to
+   translate (perhaps by table lookup) all generated 'text' or 'name'
+   attribute values into one of the supported languages (see section
+   3.1.4).  That is, the IPP object that supports a natural language
+   NEED NOT be a general purpose translator of any arbitrary 'text' or
+   'name' value supplied by the client into that natural language.
+   However, the object MUST be able to translate (automatically
+   generate) any of its own attribute values and messages into that
+   natural language.
+
+6. IANA Considerations
+
+   This section describes the procedures for defining semantics for the
+   following IETF standards track extensions and vendor extensions to
+   the IPP/1.1 Model and Semantics document:
+
+      1. keyword attribute values
+      2. enum attribute values
+
+
+
+Hastings, et al.            Standards Track                   [Page 148]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      3. attributes
+      4. attribute syntaxes
+      5. operations
+      6. attribute groups
+      7. status codes
+      8. out-of-band attribute values
+
+   Extensions registered for use with IPP/1.1 are OPTIONAL for client
+   and IPP object conformance to the IPP/1.1 "Model and Semantics"
+   document (this document).
+
+   These extension procedures are aligned with the guidelines as set
+   forth by the IESG [IANA-CON].  Section 11 describes how to propose
+   new registrations for consideration.  IANA will reject registration
+   proposals that leave out required information or do not follow the
+   appropriate format described in Section 11.  The IPP/1.1 Model and
+   Semantics document may also be extended by an appropriate RFC that
+   specifies any of the above extensions.
+
+6.1 Typed 'keyword' and 'enum' Extensions
+
+   IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3
+   and 4.1.4).  This document uses prefixes to the 'keyword' and 'enum'
+   basic attribute syntax type in order to communicate extra information
+   to the reader through its name. This extra information is not
+   represented in the protocol because it is unimportant to a client or
+   Printer object.  The list below describes the prefixes and their
+   meaning.
+
+      "type1":  This IPP specification document must be revised (or
+         another IETF standards track document which augments this
+         document) to add a new keyword or a new enum.  No vendor
+         defined keywords or enums are allowed.
+
+      "type2":  Implementers can, at any time, add new keyword or enum
+         values by proposing the complete specification to IANA:
+
+         iana@iana.org
+
+         IANA will forward the registration proposal to the IPP
+         Designated Expert who will review the proposal with a mailing
+         list that the Designated Expert keeps for this purpose.
+         Initially, that list will be the mailing list used by the IPP
+         WG:
+
+            ipp@pwg.org
+
+         even after the IPP WG is disbanded as permitted by [IANA-CON].
+
+
+
+Hastings, et al.            Standards Track                   [Page 149]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         The IPP Designated Expert is appointed by the IESG Area
+         Director responsible for IPP, according to [IANA-CON].
+
+         When a type2 keyword or enum is approved, the IPP Designated
+         Expert becomes the point of contact for any future maintenance
+         that might be required for that registration.
+
+      "type3":  Implementers can, at any time, add new keyword and enum
+         values by submitting the complete specification to IANA as for
+         type2 who will forward the proposal to the IPP Designated
+         Expert.  While no additional technical review is required, the
+         IPP Designated Expert may, at his/her discretion, forward the
+         proposal to the same mailing list as for type2 registrations
+         for advice and comment.
+
+         When a type3 keyword or enum is approved by the IPP Designated
+         Expert, the original proposer becomes the point of contact for
+         any future maintenance that might be required for that
+         registration.
+
+   For type2 and type3 keywords, the proposer includes the name of the
+   keyword in the registration proposal and the name is part of the
+   technical review.
+
+   After type2 and type3 enums specifications are approved, the IPP
+   Designated Expert in consultation with IANA assigns the next
+   available enum number for each enum value.
+
+   IANA will publish approved type2 and type3 keyword and enum
+   attributes value registration specifications in:
+
+      ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
+
+   where xxx is the attribute name that specifies the initial values and
+   yyy.txt is a descriptive file name that contains one or more enums or
+   keywords approved at the same time.  For example, if several
+   additional enums for stapling are approved for use with the
+   "finishings" attribute (and "finishings-default" and "finishings-
+   supported" attributes), IANA will publish the additional values in
+   the file:
+
+      ftp.isi.edu/iana/assignments/ipp/attribute-
+      values/finishings/stapling.txt
+
+   Note: Some attributes are defined to be: 'type3 keywords' | 'name'
+   which allows for attribute values to be extended by a site
+   administrator with administrator defined names.  Such names are not
+   registered with IANA.
+
+
+
+Hastings, et al.            Standards Track                   [Page 150]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   By definition, each of the three types above assert some sort of
+   registry or review process in order for extensions to be considered
+   valid.  Each higher numbered level (1, 2, 3) tends to be decreasingly
+   less stringent than the previous level.   Therefore, any typeN value
+   MAY be registered using a process for some typeM where M is less than
+   N, however such registration is NOT REQUIRED.  For example, a type3
+   value MAY be registered in a type 1 manner (by being included in a
+   future version of an IPP specification), however, it is NOT REQUIRED.
+
+   This document defines keyword and enum values for all of the above
+   types, including type3 keywords.
+
+   For vendor keyword extensions, implementers SHOULD use keywords with
+   a suitable distinguishing prefix, such as "xxx-" where xxx follows
+   the syntax rules for keywords (see section 4.1.3) and is the
+   (lowercase) fully qualified company name registered with IANA for use
+   in domain names [RFC1035].  For example, if the company XYZ Corp. had
+   obtained the domain name "XYZ.com", then a vendor keyword 'abc' would
+   be: 'xyz.com-abc'.
+
+   Note: RFC 1035 [RFC1035] indicates that while upper and lower case
+   letters are allowed in domain names, no significance is attached to
+   the case.  That is, two names with the same spelling but different
+   case are to be treated as if identical.  Also, the labels in a domain
+   name must follow the rules for ARPANET host names:  They must start
+   with a letter, end with a letter or digit, and have as interior
+   characters only letters, digits, and hyphen.  Labels must be 63
+   characters or less.  Labels are separated by the "." character.
+
+   For vendor enum extensions, implementers MUST use values in the
+   reserved integer range which is 2**30 to 2**31-1.
+
+6.2 Attribute Extensibility
+
+   Attribute names (see section 4.1.3) are type2 keywords.  Therefore,
+   new attributes may be registered and have the same status as
+   attributes in this document by following the type2 extension rules.
+   For vendor attribute extensions, implementers SHOULD use keywords
+   with a suitable distinguishing prefix as described in Section 6.1.
+
+   IANA will publish approved attribute registration specifications as
+   separate files:
+
+      ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt
+
+   where "xxx-yyy" is the new attribute name.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 151]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   If a new Printer object attribute is defined and its values can be
+   affected by a specific document format, its specification needs to
+   contain the following sentence:
+
+         "The value of this attribute returned in a Get-Printer-
+         Attributes response MAY depend on the "document-format"
+         attribute supplied (see Section 3.2.5.1)."
+
+   If the specification does not, then its value in the Get-Printer-
+   Attributes response MUST NOT depend on the "document-format" supplied
+   in the request.  When a new Job Template attribute is registered, the
+   value of the Printer attributes MAY vary with "document-format"
+   supplied in the request without the specification having to indicate
+   so.
+
+6.3 Attribute Syntax Extensibility
+
+   Attribute syntaxes (see section 4.1) are like type2 enums.
+   Therefore, new attribute syntaxes may be registered and have the same
+   status as attribute syntaxes in this document by following the type2
+   extension rules described in Section 6.1.  The initial set of value
+   codes that identify each of the attribute syntaxes have been assigned
+   in the "Encoding and Transport" document [RFC2910], including a
+   designated range for vendor extension.
+
+   For attribute syntaxes, the IPP Designated Expert in consultation
+   with IANA assigns the next attribute syntax code in the appropriate
+   range as specified in [RFC2910].  IANA will publish approved
+   attribute syntax registration specifications as separate files:
+
+      ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt
+
+   where 'xxx-yyy' is the new attribute syntax name.
+
+6.4 Operation Extensibility
+
+   Operations (see section 3) may also be registered following the type2
+   procedures described in Section 6.1, though major new operations will
+   usually be done by a new standards track RFC that augments this
+   document.  For vendor operation extensions, implementers MUST use the
+   range for the "operation-id" in requests specified in Section 4.4.15
+   "operations-supported" Printer attribute.
+
+   For operations, the IPP Designated Expert in consultation with IANA
+   assigns the next operation-id code as specified in Section 4.4.15.
+   IANA will publish approved operation registration specifications as
+   separate files:
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 152]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt
+
+   where "Xxx-Yyy" is the new operation name.
+
+6.5 Attribute Group Extensibility
+
+   Attribute groups (see section 3.1.3) passed in requests and responses
+   may be registered following the type2 procedures described in Section
+   6.1.  The initial set of attribute group tags have been assigned in
+   the "Encoding and Transport" document [RFC2910], including a
+   designated range for vendor extension.
+
+   For attribute groups, the IPP Designated Expert in consultation with
+   IANA assigns the next attribute group tag code in the appropriate
+   range as specified in [RFC2910].  IANA will publish approved
+   attribute group registration specifications as separate files:
+
+      ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
+      tag.txt
+
+   where 'xxx-yyy-tag' is the new attribute group tag name.
+
+6.6 Status Code Extensibility
+
+   Operation status codes (see section 3.1.6.1) may also be registered
+   following the type2 procedures described in Section 6.1.  The values
+   for status codes are allocated in ranges as specified in Section 14
+   for each status code class:
+
+      "informational" - Request received, continuing process
+      "successful" - The action was successfully received, understood, and
+         accepted
+      "redirection" - Further action must be taken in order to complete the
+         request
+      "client-error" - The request contains bad syntax or cannot be
+         fulfilled
+      "server-error" - The IPP object  failed to fulfill an apparently
+         valid request
+
+   For vendor operation status code extensions, implementers MUST use
+   the top of each range as specified in Section 13.
+
+   For operation status codes, the IPP Designated Expert in consultation
+   with IANA assigns the next status code in the appropriate class range
+   as specified in Section 13.  IANA will publish approved status code
+   registration specifications as separate files:
+
+      ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt
+
+
+
+Hastings, et al.            Standards Track                   [Page 153]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   where "xxx-yyy" is the new operation status code keyword.
+
+6.7 Out-of-band Attribute Value Extensibility
+
+   Out-of-band attribute values (see the beginning of section 4.1)
+   passed in requests and responses may be registered following the
+   type2 procedures described in Section 6.1.  The initial set of out-
+   of-band attribute value tags have been assigned in the "Encoding and
+   Transport" document [RFC2910].
+
+   For out-of-band attribute value tags, the IPP Designated Expert in
+   consultation with IANA assigns the next out-of-band attribute value
+   tag code in the appropriate range as specified in [RFC2910].  IANA
+   will publish approved out-of-band attribute value tags registration
+   specifications as separate files:
+
+      ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-
+      tags/xxx-yyy-tag.txt
+
+   where 'xxx-yyy-tag' is the new out-of-band attribute value tag name.
+
+6.8 Registration of MIME types/sub-types for document-formats
+
+   The "document-format" attribute's syntax is 'mimeMediaType'.  This
+   means that valid values are Internet Media Types (see Section 4.1.9).
+   RFC 2045 [RFC2045] defines the syntax for valid Internet media types.
+   IANA is the registry for all Internet media types.
+
+6.9 Registration of charsets for use in 'charset' attribute values
+
+   The "attributes-charset" attribute's syntax is 'charset'.  This means
+   that valid values are charsets names.  When a charset in the IANA
+   registry has more than one name (alias), the name labeled as
+   "(preferred MIME name)", if present, MUST be used (see Section
+   4.1.7).  IANA is the registry for charsets following the procedures
+   of [RFC2278].
+
+7. Internationalization Considerations
+
+   Some of the attributes have values that are text strings and names
+   which are intended for human understanding rather than machine
+   understanding (see the 'text' and 'name' attribute syntaxes in
+   Sections 4.1.1 and 4.1.2).
+
+   In each operation request, the client
+
+      - identifies the charset and natural language of the request which
+        affects each supplied 'text' and 'name' attribute value, and
+
+
+
+Hastings, et al.            Standards Track                   [Page 154]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - requests the charset and natural language for attributes
+        returned by the IPP object in operation responses (as described
+        in Section 3.1.4.1).
+
+   In addition, the client MAY separately and individually identify the
+   Natural Language Override of a supplied 'text' or 'name' attribute
+   using the 'textWithLanguage' and 'nameWithLanguage' technique
+   described section 4.1.1.2 and 4.1.2.2 respectively.
+
+   All IPP objects MUST support the UTF-8 [RFC2279] charset in all
+   'text' and 'name' attributes supported.  If an IPP object supports
+   more than the UTF-8 charset, the object MUST convert between them in
+   order to return the requested charset to the client according to
+   Section 3.1.4.2.  If an IPP object supports more than one natural
+   language, the object SHOULD return 'text' and 'name' values in the
+   natural language requested where those values are generated by the
+   Printer (see Section 3.1.4.1).
+
+   For Printers that support multiple charsets and/or multiple natural
+   languages in 'text' and 'name' attributes, different jobs may have
+   been submitted in differing charsets and/or natural languages.  All
+   responses MUST be returned in the charset requested by the client.
+   However, the Get-Jobs operation uses the 'textWithLanguage' and
+   'nameWithLanguage' mechanism to identify the differing natural
+   languages with each job attribute returned.
+
+   The Printer object also has configured charset and natural language
+   attributes.   The client can query the Printer object to determine
+   the list of charsets and natural languages supported by the Printer
+   object and what the Printer object's configured values are.  See the
+   "charset-configured", "charset-supported", "natural-language-
+   configured", and "generated-natural-language-supported" Printer
+   description attributes for more details.
+
+   The "charset-supported" attributed identifies the supported charsets.
+   If a charset is supported, the IPP object MUST be capable of
+   converting to and from that charset into any other supported charset.
+   In many cases, an IPP object will support only one charset and it
+   MUST be the UTF-8 charset.
+
+   The "charset-configured" attribute identifies the one supported
+   charset which is the native charset given the current configuration
+   of the IPP object (administrator defined).
+
+   The "generated-natural-language-supported" attribute identifies the
+   set of supported natural languages for generated messages; it is not
+   related to the set of natural languages that must be accepted for
+   client supplied 'text' and 'name' attributes.  For client supplied
+
+
+
+Hastings, et al.            Standards Track                   [Page 155]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   'text' and 'name' attributes, an IPP object MUST accept ALL supplied
+   natural languages.  Just because a Printer object is currently
+   configured to support 'en-us' natural language does not mean that the
+   Printer object should reject a job if the client supplies a job name
+   that is in 'fr-ca'.
+
+   The "natural-language-configured" attribute identifies the one
+   supported natural language for generated messages which is the native
+   natural language given the current configuration of the IPP object
+   (administrator defined).
+
+   Attributes of type 'text' and 'name' are populated from different
+   sources.  These attributes can be categorized into following groups
+   (depending on the source of the attribute):
+
+      1. Some attributes are supplied by the client (e.g., the client
+         supplied "job-name", "document-name", and "requesting-user-
+         name" operation attributes along with the corresponding Job
+         object's "job-name" and "job-originating-user-name"
+         attributes).  The IPP object MUST accept these attributes in
+         any natural language no matter what the set of supported
+         languages for generated messages
+      2. Some attributes are supplied by the system administrator (e.g.,
+         the Printer object's "printer-name" and "printer-location"
+         attributes).  These too can be in any natural language.  If the
+         natural language for these attributes is different than what a
+         client requests, then they must be reported using the Natural
+         Language Override mechanism.
+      3. Some attributes are supplied by the device manufacturer (e.g.,
+         the Printer object's "printer-make-and-model" attribute).
+         These too can be in any natural language.  If the natural
+         language for these attributes is different than what a client
+         requests, then they must be reported using the Natural Language
+         Override mechanism.
+      4. Some attributes are supplied by the operator (e.g., the Job
+         object's "job-message-from-operator" attribute). These too can
+         be in any natural language.  If the natural language for these
+         attributes is different than what a client requests, then they
+         must be reported using the Natural Language Override mechanism.
+      5. Some attributes are generated by the IPP object (e.g., the Job
+         object's "job-state-message" attribute, the Printer object's
+         "printer-state-message" attribute, and the "status-message"
+         operation attribute).  These attributes can only be in one of
+         the "generated-natural-language-supported" natural languages.
+         If a client requests some natural language for these attributes
+         other than one of the supported values, the IPP object SHOULD
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 156]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         respond using the value of the "natural-language-configured"
+         attribute (using the Natural Language Override mechanism if
+         needed).
+
+   The 'text' and 'name' attributes specified in this version of this
+   document (additional ones will be registered according to the
+   procedures in Section 6) are:
+
+                    Attributes                            Source
+
+   Operation Attributes:
+        job-name (name)                         client
+        document-name (name)                    client
+        requesting-user-name (name)             client
+        status-message (text)                   Job or Printer object
+        detailed-status-message (text)          Job or Printer object -
+                                                see rule 1
+        document-access-error (text)            Job or Printer object -
+                                                see rule 1
+
+   Job Template Attributes:
+        job-hold-until (keyword | name)         client matches
+                                                administrator-configured
+        job-hold-until-default (keyword | name) client matches
+                                                administrator-configured
+        job-hold-until-supported (keyword |     client matches
+        name)                                   administrator-configured
+        job-sheets (keyword | name)             client matches
+                                                administrator-configured
+        job-sheets-default (keyword | name)     client matches
+                                                administrator-configured
+        job-sheets-supported (keyword | name)   client matches
+                                                administrator-configured
+        media (keyword | name)                  client matches
+                                                administrator-configured
+        media-default (keyword | name)          client matches
+                                                administrator-configured
+        media-supported (keyword | name)        client matches
+                                                administrator-configured
+        media-ready (keyword | name)            client matches
+                                                administrator-configured
+
+   Job Description Attributes:
+        job-name (name)                         client or Printer object
+        job-originating-user-name (name)        Printer object
+        job-state-message (text)                Job or Printer object
+        output-device-assigned (name(127))      administrator
+        job-message-from-operator (text(127))   operator
+
+
+
+Hastings, et al.            Standards Track                   [Page 157]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+        job-detailed-status-messages (1setOf    Job or Printer object -
+        text)                                   see rule 1
+        job-document-access-errors (1setOf      Job or Printer object -
+        text)                                   see rule 1
+
+   Printer Description Attributes:
+        printer-name (name(127))                administrator
+        printer-location (text(127))            administrator
+        printer-info (text(127))                administrator
+        printer-make-and-model (text(127))      administrator or
+                                                manufacturer
+        printer-state-message (text)            Printer object
+        printer-message-from-operator           operator
+        (text(127))
+
+   Rule 1 - Neither the Printer nor the client localizes these message
+   attributes, since they are intended for use by the system
+   administrator or other experienced technical persons.
+
+8. Security Considerations
+
+   It is difficult to anticipate the security risks that might exist in
+   any given IPP environment. For example, if IPP is used within a given
+   corporation over a private network, the risks of exposing document
+   data may be low enough that the corporation will choose not to use
+   encryption on that data.  However, if the connection between the
+   client and the IPP object is over a public network, the client may
+   wish to protect the content of the information during transmission
+   through the network with encryption.
+
+   Furthermore, the value of the information being printed may vary from
+   one IPP environment to the next. Printing payroll checks, for
+   example, would have a different value than printing public
+   information from a file.  There is also the possibly of denial-of-
+   service attacks, but denial-of-service attacks against printing
+   resources are not well understood and there is no published
+   precedents regarding this scenario.
+
+   Once the authenticated identity of the requester has been supplied to
+   the IPP object, the object uses that identity to enforce any
+   authorization policy that might be in place.  For example, one site's
+   policy might be that only the job owner is allowed to cancel a job.
+   The details and mechanisms to set up a particular access control
+   policy are not part of IPP/1.1, and must be established via some
+   other type of administrative or access control framework.  However,
+   there are operation status codes that allow an IPP server to return
+   information back to a client about any potential access control
+   violations for an IPP object.
+
+
+
+Hastings, et al.            Standards Track                   [Page 158]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   During a create operation, the client's identity is recorded in the
+   Job object in an implementation-defined attribute.  This information
+   can be used to verify a client's identity for subsequent operations
+   on that Job object in order to enforce any access control policy that
+   might be in effect.  See section 8.3 below for more details.
+
+   Since the security levels or the specific threats that an IPP system
+   administrator may be concerned with cannot be anticipated, IPP MUST
+   be capable of operating with different security mechanisms and
+   security policies as required by the individual installation.
+   Security policies might vary from very strong, to very weak, to none
+   at all, and corresponding security mechanisms will be required.
+
+8.1 Security Scenarios
+
+   The following sections describe specific security attacks for IPP
+   environments.  Where examples are provided they should be considered
+   illustrative of the environment and not an exhaustive set. Not all of
+   these environments will necessarily be addressed in initial
+   implementations of IPP.
+
+8.1.1 Client and Server in the Same Security Domain
+
+   This environment is typical of internal networks where traditional
+   office workers print the output of personal productivity applications
+   on shared work-group printers, or where batch applications print
+   their output on large production printers. Although the identity of
+   the user may be trusted in this environment, a user might want to
+   protect the content of a document against such attacks as
+   eavesdropping, replaying or tampering.
+
+8.1.2 Client and Server in Different Security Domains
+
+   Examples of this environment include printing a document created by
+   the client on a publicly available printer, such as at a commercial
+   print shop; or printing a document remotely on a business associate's
+   printer.  This latter operation is functionally equivalent to sending
+   the document to the business associate as a facsimile. Printing
+   sensitive information on a Printer in a different security domain
+   requires strong security measures. In this environment authentication
+   of the printer is required as well as protection against unauthorized
+   use of print resources. Since the document crosses security domains,
+   protection against eavesdropping and document tampering are also
+   required. It will also be important in this environment to protect
+   Printers against "spamming" and malicious document content.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 159]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+8.1.3 Print by Reference
+
+   When the document is not stored on the client, printing can be done
+   by reference. That is, the print request can contain a reference, or
+   pointer, to the document instead of the actual document itself (see
+   sections 3.2.2 and 3.3.2). Standard methods currently do not exist
+   for remote entities to "assume" the credentials of a client for
+   forwarding requests to a 3rd party. It is anticipated that Print-By-
+   Reference will be used to access "public" documents and that
+   sophisticated methods for authenticating "proxies" is not specified
+   in this document.
+
+8.2 URIs in Operation, Job, and Printer attributes
+
+   The "printer-uri-supported" attribute contains the Printer object's
+   URI(s).  Its companion attribute, "uri-security-supported",
+   identifies the security mechanism used for each URI listed in the
+   "printer-uri-supported" attribute.  For each Printer operation
+   request, a client MUST supply only one URI in the "printer-uri"
+   operation attribute.  In other words, even though the Printer
+   supports more than one URI, the client only interacts with the
+   Printer object using one if its URIs.  This duality is not needed for
+   Job objects, since the Printer objects is the factory for Job
+   objects, and the Printer object will generate the correct URI for new
+   Job objects depending on the Printer object's security configuration.
+
+8.3 URIs for each authentication mechanisms
+
+   Each URI has an authentication mechanism associated with it. If the
+   URI is the i'th element of "printer-uri-supported", then
+   authentication mechanism is the "i th" element of "uri-
+   authentication-supported". For a list of possible authentication
+   mechanisms, see section 4.4.2.
+
+   The Printer object uses an authentication mechanism to determine the
+   name of the user performing an operation. This user is called the
+   "authenticated user". The credibility of authentication depends on
+   the mechanism that the Printer uses to obtain the user's name. When
+   the authentication mechanism is 'none', all authenticated users are
+   "anonymous".
+
+   During job creation operations, the Printer initializes the value of
+   the "job-originating-user-name" attribute (see section 4.3.6) to be
+   the authenticated user. The authenticated user is this case is called
+   the "job owner".
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 160]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   If an implementation can be configured to support more than one
+   authentication mechanism (see section 4.4.2), then it MUST implement
+   rules for determining equality of authenticated user names which have
+   been authenticated via different authentication mechanisms.  One
+   possible policy is that identical names that are authenticated via
+   different mechanisms are different.  For example, a user can cancel
+   his job only if he uses the same authentication mechanism for both
+   Cancel-Job and Print-Job.  Another policy is that identical names
+   that are authenticated via different mechanism are the same if the
+   authentication mechanism for the later operation is not less strong
+   than the authentication mechanism for the earlier job creation
+   operation.  For example, a user can cancel his job only if he uses
+   the same or stronger authentication mechanism for Cancel-Job and
+   Print-Job. With this second policy a job submitted via 'requesting-
+   user-name' authentication could be canceled via 'digest'
+   authentication. With the first policy, the job could not be canceled
+   in this way.
+
+   A client is able to determine the authentication mechanism used to
+   create a job. It is the i'th value of the Printer's "uri-
+   authentication-supported" attribute (see section 4.4.2), where i is
+   the index of the element of the Printer's "printer-uri-supported"
+   attribute (see section 4.4.1) equal to the job's "job-printer-uri"
+   attribute (see section 4.3.3).
+
+8.4 Restricted Queries
+
+   In many IPP operations, a client supplies a list of attributes to be
+   returned in the response.  For security reasons, an IPP object may be
+   configured not to return all attributes (or all values) that a client
+   requests.  The job attributes returned MAY depend on whether the
+   requesting user is the same as the user that submitted the job. The
+   IPP object MAY even return none of the requested attributes. In such
+   cases, the status returned is the same as if the object had returned
+   all requested attributes.  The client cannot tell by such a response
+   whether the requested attribute was present or absent on the object.
+
+8.5 Operations performed by operators and system administrators
+
+   For the three printer operations Pause-Printer, Resume-Printer, and
+   Purge-Jobs (see sections 3.2.7, 3.2.8 and 3.2.9), the requesting user
+   is intended to be an operator or administrator of the Printer object
+   (see section 1).  Otherwise, the IPP Printer MUST reject the
+   operation and return:  'client-error-forbidden', 'client-error-not-
+   authenticated', or 'client-error-not-authorized' as appropriate.  For
+   operations on jobs, the requesting user is intended to be the job
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 161]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   owner or may be an operator or administrator of the Printer object.
+   The means for authorizing an operator or administrator of the Printer
+   object are not specified in this document.
+
+8.6 Queries on jobs submitted using non-IPP protocols
+
+   If the device that an IPP Printer is representing is able to accept
+   jobs using other job submission protocols in addition to IPP, it is
+   RECOMMENDED that such an implementation at least allow such "foreign"
+   jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as
+   'unknown'.  Such an implementation NEED NOT support all of the same
+   IPP job attributes as for IPP jobs.  The IPP object returns the
+   'unknown' out-of-band value for any requested attribute of a foreign
+   job that is supported for IPP jobs, but not for foreign jobs.
+
+   It is further RECOMMENDED, that the IPP Printer generate "job-id" and
+   "job-uri" values for such "foreign jobs", if possible, so that they
+   may be targets of other IPP operations, such as Get-Job-Attributes
+   and Cancel-Job.  Such an implementation also needs to deal with the
+   problem of authentication of such foreign jobs.  One approach would
+   be to treat all such foreign jobs as belonging to users other than
+   the user of the IPP client.  Another approach would be for the
+   foreign job to belong to 'anonymous'.  Only if the IPP client has
+   been authenticated as an operator or administrator of the IPP Printer
+   object, could the foreign jobs be queried by an IPP request.
+   Alternatively, if the security policy is to allow users to query
+   other users' jobs, then the foreign jobs would also be visible to an
+   end-user IPP client using Get-Jobs and Get-Job-Attributes.
+
+9. References
+
+   [ASME-Y14.1M] Metric Drawing Sheet Size and Format, ASME Y14.1M-1995.
+                 This standard defines metric sheet sizes and formats
+                 for engineering drawings.
+
+   [ASCII]       Coded Character Set - 7-bit American Standard Code for
+                 Information Interchange (ASCII), ANSI X3.4-1986. This
+                 standard is the specification of the US-ASCII charset.
+
+   [BCP-11]      Bradner S. and R. Hovey, "The Organizations Involved in
+                 the IETF Standards Process", BCP 11, RFC 2028, October
+                 1996.
+
+   [HTPP]        J. Barnett, K. Carter, R. DeBry,  "Initial Draft -
+                 Hypertext Printing Protocol - HTPP/1.0", October 1996,
+              ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 162]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   [IANA-CON]    Narten, T. and H. Alvestrand, "Guidelines for Writing
+                 an IANA Considerations Section in RFCs", BCP 26, RFC
+                 2434, October 1998.
+
+   [IANA-CS]     IANA Registry of Coded Character Sets:
+                 ftp://ftp.isi.edu/in-notes/iana/assignments/character-
+                 sets
+
+   [IANA-MT]     IANA Registry of Media Types:  ftp://ftp.isi.edu/in-
+                 notes/iana/assignments/media-types/
+
+   [IPP-IIG]     Hastings, T., Manros, C., Kugler, C., Holst, H., and P.
+                 Zehler, "Internet Printing Protocol/1.1:  draft-ietf-
+                 ipp-implementers-guide-v11-01.txt, work in progress,
+                 May 30, 2000.
+
+   [ISO10646-1]  ISO/IEC 10646-1:1993, "Information technology --
+                 Universal Multiple-Octet Coded Character Set (UCS) -
+                 Part 1: Architecture and Basic Multilingual Plane,
+                 JTC1/SC2."
+
+   [ISO8859-1]   ISO/IEC 8859-1:1987, "Information technology -- 8-bit
+                 One-Byte Coded Character Set - Part 1: Latin Alphabet
+                 Nr 1", 1987, JTC1/SC2.
+
+   [ISO10175]    ISO/IEC 10175 Document Printing Application (DPA), June
+                 1996.
+
+   [LDPA]        T. Hastings,  S. Isaacson,  M. MacKay, C. Manros, D.
+                 Taylor, P. Zehler,  "LDPA - Lightweight Document
+                 Printing Application", October 1996,
+              ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
+
+   [P1387.4]     Kirk, M. (editor), POSIX System Administration - Part
+                 4:  Printing Interfaces, POSIX 1387.4 D8, 1994.
+
+   [PSIS]        Herriot, R. (editor), X/Open A Printing System
+                 Interoperability Specification (PSIS), August 1995.
+
+   [PWG]         Printer Working Group, http://www.pwg.org.
+
+   [RFC1035]     Mockapetris, P., "Domain Names - Implementation and
+                 Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1179]     McLaughlin, L., "Line Printer Daemon Protocol", RFC
+                 1179, August 1990.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 163]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   [RFC1759]     Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+                 Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+   [RFC1766]     Alvestrand, H., "Tags for the Identification of
+                 Languages", RFC 1766, March 1995.
+
+   [RFC1951]     Deutsch, P., "DEFLATE Compressed Data Format
+                 Specification version 1.3 ", RFC 1951, May 1996.
+
+   [RFC1952]     Deutsch, P., "GZIP file format specification version
+                 4.3", RFC 1952, May 1996.
+
+   [RFC1977]     Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
+                 August 1996.
+
+   [RFC2026]     Bradner, S., "The Internet Standards Process --
+                 Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2045]     Freed, N. and  N. Borenstein, ", Multipurpose Internet
+                 Mail Extensions (MIME) Part One: Format of Internet
+                 Message Bodies", RFC 2045, November 1996.
+
+   [RFC2046]     Freed, N. and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) Part Two: Media Types", RFC
+                 2046, November 1996.
+
+   [RFC2048]     Freed, N., Klensin, J. and J. Postel, "Multipurpose
+                 Internet Mail Extension (MIME) Part Four: Registration
+                 Procedures", RFC 2048, November 1996.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2228]     Horowitz, M. and S. Lunt, "FTP Security Extensions",
+                 RFC 2228, October 1997.
+
+   [RFC2246]     Dierks, T. and C. Allen, "The TLS Protocol Version
+                 1.0", RFC 2246, January 1999.
+
+   [RFC2277]     Alvestrand, H., "IETF Policy on Character Sets and
+                 Languages" BCP 18, RFC 2277, January 1998.
+
+   [RFC2278]     Freed, N. and J. Postel: "IANA CharSet Registration
+                 Procedures", BCP 19, RFC 2278, January 1998.
+
+   [RFC2279]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", RFC 2279, January 1998.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 164]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   [RFC2316]     Bellovin, S., "Report of the IAB Security Architecture
+                 Workshop", RFC 2316, April 1998.
+
+   [RFC2396]     Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+                 Resource Identifiers (URI): Generic Syntax", RFC 2396,
+                 August 1998.
+
+   [RFC2565]     Herriot, R., Butler, S., Moore, P. and R. Turner,
+                 "Internet Printing Protocol/1.0: Encoding and
+                 Transport", RFC 2565, April 1999.
+
+   [RFC2566]     deBry, R., Hastings, T., Herriot, R., Isaacson, S. and
+                 P. Powell, "Internet Printing Protocol/1.0: Model and
+                 Semantics", RFC 2566, April 1999.
+
+   [RFC2567]     Wright, D., "Design Goals for an Internet Printing
+                 Protocol", RFC 2567, April 1999.
+
+   [RFC2568]     Zilles, S., "Rationale for the Structure and Model and
+                 Protocol for the Internet Printing Protocol", RFC 2568,
+                 April 1999.
+
+   [RFC2569]     Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+                 "Mapping between LPD and IPP Protocols", RFC 2569,
+                 April 1999.
+
+   [RFC2579]     McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+                 "Textual Conventions for SMIv2", STD 58, RFC 2579,
+                 April 1999.
+
+   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+                 Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2617]     Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
+                 S., Leach, P., Luotonen, A. and L. Stewart, "HTTP
+                 Authentication:  Basic and Digest Access
+                 Authentication", RFC 2617, June 1999.
+
+   [RFC2639]     Hastings, T. and C. Manros, "Internet Printing
+                 Protocol/1.0: Encoding and Transport", RFC 2639, July
+                 1999.
+
+   [RFC2910]     Herriot, R., Butler, S., Moore, P., Turner, R. and J.
+                 Wenn, "Internet Printing Protocol/1.1: Encoding and
+                 Transport", RFC 2910, September 2000.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 165]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   [SSL]         Netscape, The SSL Protocol, Version 3, (Text version
+                 3.02), November 1996.
+
+   [SWP]         P. Moore, B. Jahromi, S. Butler, "Simple Web Printing
+                 SWP/1.0", May 7, 1997,
+                 ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf
+
+10. Authors' Addresses
+
+   Scott A. Isaacson, Editor
+   Novell, Inc.
+   122 E 1700 S
+   Provo, UT   84606
+
+   Phone: 801-861-7366
+   Fax:   801-861-2517
+   EMail: sisaacson@novell.com
+
+
+   Tom Hastings
+   Xerox Corporation
+   737 Hawaii St.  ESAE 231
+   El Segundo, CA   90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Robert Herriot
+   Xerox Corp.
+   3400 Hill View Ave, Building 1
+   Palo Alto, CA 94304
+
+   Phone: 650-813-7696
+   Fax:  650-813-6860
+   EMail: robert.herriot@pahv.xerox.com
+
+
+   Roger deBry
+   Utah Valley State College
+   Orem, UT 84058
+
+   Phone: (801) 222-8000
+   EMail: debryro@uvsc.edu
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 166]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Patrick Powell
+   Astart Technologies
+   9475 Chesapeake Dr., Suite D
+   San Diego, CA  95123
+
+   Phone: (619) 874-6543
+   Fax:   (619) 279-8424
+   EMail: papowell@astart.com
+
+   IPP Web Page:  http://www.pwg.org/ipp/
+   IPP Mailing List:  ipp@pwg.org
+
+   To subscribe to the ipp mailing list, send the following email:
+      1) send it to majordomo@pwg.org
+      2) leave the subject line blank
+      3) put the following two lines in the message body:
+            subscribe ipp
+            end
+
+   Implementers of this specification document are encouraged to join
+   IPP Mailing List in order to participate in any discussions of
+   clarification issues and review of registration proposals for
+   additional attributes and values.
+
+   Other Participants:
+
+   Chuck Adams - Tektronix             Shivaun Albright - HP
+   Stefan Andersson - Axis             Jeff Barnett - IBM
+   Ron Bergman - Hitachi Koki Imaging  Dennis Carney - IBM
+   Systems
+   Keith Carter - IBM                  Angelo Caruso - Xerox
+   Rajesh Chawla - TR Computing        Nancy Chen - Okidata
+   Solutions
+   Josh Cohen - Microsoft              Jeff Copeland - QMS
+   Andy Davidson - Tektronix           Roger deBry - IBM
+   Maulik Desai - Auco                 Mabry Dozier - QMS
+   Lee Farrell - Canon Information     Satoshi Fujitami - Ricoh
+   Systems
+   Steve Gebert - IBM                  Sue Gleeson - Digital
+   Charles Gordon - Osicom             Brian Grimshaw - Apple
+   Jerry Hadsell - IBM                 Richard Hart - Digital
+   Tom Hastings - Xerox                Henrik Holst - I-data
+   Stephen Holmstead                   Zhi-Hong Huang - Zenographics
+   Scott Isaacson - Novell             Babek Jahromi - Microsoft
+   Swen Johnson - Xerox                David Kellerman - Northlake
+                                       Software
+   Robert Kline - TrueSpectra          Charles Kong - Panasonic
+   Carl Kugler - IBM                   Dave Kuntz - Hewlett-Packard
+
+
+
+Hastings, et al.            Standards Track                   [Page 167]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Takami Kurono - Brother             Rick Landau - Digital
+   Scott Lawrence - Agranot Systems    Greg LeClair - Epson
+   Dwight Lewis - Lexmark              Harry Lewis - IBM
+   Tony Liao - Vivid Image             Roy Lomicka - Digital
+   Pete Loya - HP                      Ray Lutz - Cognisys
+   Mike MacKay - Novell, Inc.          David Manchala - Xerox
+   Carl-Uno Manros - Xerox             Jay Martin - Underscore
+   Stan McConnell - Xerox              Larry Masinter - Xerox
+   Sandra Matts - Hewlett Packard      Peter Michalek - Shinesoft
+   Ira McDonald - High North Inc.      Mike Moldovan - G3 Nova
+   Tetsuya Morita - Ricoh              Yuichi Niwa - Ricoh
+   Pat Nogay - IBM                     Ron Norton - Printronics
+   Hugo Parra, Novell                  Bob Pentecost - Hewlett-Packard
+   Patrick Powell - Astart             Jeff Rackowitz - Intermec
+   Technologies
+   Eric Random - Peerless              Rob Rhoads - Intel
+   Xavier Riley - Xerox                Gary Roberts - Ricoh
+   David Roach - Unisys                Stuart Rowley - Kyocera
+   Yuji Sasaki - Japan Computer        Richard Schneider - Epson
+   Industry
+   Kris Schoff - HP                    Katsuaki Sekiguchi - Canon
+   Bob Setterbo - Adobe                Gail Songer - Peerless
+   Hideki Tanaka - Cannon              Devon Taylor - Novell
+   Mike Timperman - Lexmark            Atsushi Uchino - Epson
+   Shigeru Ueda - Canon                Bob Von Andel - Allegro Software
+   William Wagner - NetSilicon/DPI     Jim Walker - DAZEL
+   Chris Wellens - Interworking Labs   Trevor Wells - Hewlett Packard
+   Craig Whittle - Sharp Labs          Rob Whittle - Novell, Inc.
+   Jasper Wong - Xionics               Don Wright - Lexmark
+   Michael Wu - Heidelberg Digital     Rick Yardumian - Xerox
+   Michael Yeung - Toshiba             Lloyd Young - Lexmark
+   Atsushi Yuki - Kyocera              Peter Zehler - Xerox
+   William Zhang- Canon Information    Frank Zhao - Panasonic
+   Systems
+   Steve Zilles - Adobe                Rob Zirnstein - Canon Information
+                                       Systems
+
+11. Formats for IPP Registration Proposals
+
+   In order to propose an IPP extension for registration, the proposer
+   must submit an application to IANA by email to "iana@iana.org" or by
+   filling out the appropriate form on the IANA web pages
+   (http://www.iana.org).  This section specifies the required
+   information and the formats for proposing registrations of extensions
+   to IPP as provided in Section 6 for:
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 168]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      1. type2 'keyword' attribute values
+      2. type3 'keyword' attribute values
+      3. type2 'enum' attribute values
+      4. type3 'enum' attribute values
+      5. attributes
+      6. attribute syntaxes
+      7. operations
+      8. status codes
+      9. out-of-band attribute values
+
+11.1 Type2 keyword attribute values registration,
+
+   Type of registration:  type2 keyword attribute value
+   Name of attribute to which this keyword specification is to be added:
+   Proposed keyword name of this keyword value:
+   Specification of this keyword value (follow the style of IPP Model
+   Section 4.1.2.3):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type2 keywords, the Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.2 Type3 keyword attribute values registration
+
+   Type of registration:  type3 keyword attribute value
+   Name of attribute to which this keyword specification is to be added:
+   Proposed keyword name of this keyword value:
+   Specification of this keyword value (follow the style of IPP Model
+   Section 4.1.2.3):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type3 keywords, the proposer will be the point of contact
+   for the approved registration specification, if any maintenance of
+   the registration specification is needed.
+
+11.3 Type2 enum attribute values registration
+
+   Type of registration:  type2 enum attribute value
+   Name of attribute to which this enum specification is to be added:
+   Keyword symbolic name of this enum value:
+   Numeric value (to be assigned by the IPP Designated Expert in
+   consultation with IANA):
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 169]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Specification of this enum value (follow the style of IPP Model
+   Section 4.1.4):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type2 enums, the Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.4 Type3 enum attribute values registration
+
+   Type of registration:  type3 enum attribute value
+   Name of attribute to which this enum specification is to be added:
+   Keyword symbolic name of this enum value:
+   Numeric value (to be assigned by the IPP Designated Expert in
+   consultation with IANA):
+   Specification of this enum value (follow the style of IPP Model
+   Section 4.1.4):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For type3 enums, the proposer will be the point of contact for
+   the approved registration specification, if any maintenance of the
+   registration specification is needed.
+
+11.5 Attribute registration
+
+   Type of registration:  attribute
+   Proposed keyword name of this attribute:
+   Types of attribute (Operation, Job Template, Job Description, Printer
+   Description):
+   Operations to be used with if the attribute is an operation attribute:
+   Object (Job, Printer, etc. if bound to an object):
+   Attribute syntax(es) (include 1setOf and range as in Section 4.2):
+   If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
+   If this is a Printer attribute, MAY the value returned depend on
+   "document-format" (See Section 6.2):
+   If this is a Job Template attribute, how does its specification depend
+   on the value of the "multiple-document-handling" attribute:
+   Specification of this attribute (follow the style of IPP Model Section
+   4.2):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 170]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Note:  For attributes, the IPP Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.6 Attribute Syntax registration
+
+   Type of registration:  attribute syntax
+   Proposed name of this attribute syntax:
+   Type of attribute syntax (integer, octetString, character-string,  see
+   [RFC2910]):
+   Numeric tag according to [RFC2910] (to be assigned by the IPP
+   Designated Expert in consultation with IANA):
+   Specification of this attribute (follow the style of IPP Model Section
+   4.1):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For attribute syntaxes, the IPP Designated Expert will be the
+   point of contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.7 Operation registration
+
+   Type of registration:  operation
+   Proposed name of this operation:
+   Numeric operation-id value according to section 4.4.15 (to be assigned
+   by the IPP Designated Expert in consultation with IANA):
+   Object Target (Job, Printer, etc. that operation is upon):
+   Specification of this operation (follow the style of IPP Model Section
+   3):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For operations, the IPP Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.8 Attribute Group registration
+
+   Type of registration:  attribute group
+   Proposed name of this attribute group:
+   Numeric tag according to [RFC2910] (to be assigned by the IPP
+   Designated Expert in consultation with IANA):
+   Operation requests and group number for each operation in which the
+   attribute group occurs:
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 171]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Operation responses and group number for each operation in which the
+   attribute group occurs:
+   Specification of this attribute group (follow the style of IPP Model
+   Section 3):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For attribute groups, the IPP Designated Expert will be the
+   point of contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.9 Status code registration
+
+   Type of registration:  status code
+   Keyword symbolic name of this status code value:
+   Numeric value (to be assigned by the IPP Designated Expert in
+   consultation with IANA):
+   Operations that this status code may be used with:
+   Specification of this status code (follow the style of IPP Model
+   Section 13 APPENDIX B:  Status Codes and Suggested Status Code
+   Messages):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For status codes, the Designated Expert will be the point of
+   contact for the approved registration specification, if any
+   maintenance of the registration specification is needed.
+
+11.10 Out-of-band Attribute Value registration
+
+   Type of registration:  out-of-band attribute value
+   Proposed name of this out-of-band attribute value:
+   Numeric tag according to [RFC2910] (to be assigned by the IPP Designated
+   Expert in consultation with IANA):
+   Operations that this out-of-band attribute value may be used with:
+   Attributes that this out-of-band attribute value may be used with:
+   Specification of this out-of-band attribute value (follow the style of
+   the beginning of IPP Model Section 4.1):
+   Name of proposer:
+   Address of proposer:
+   Email address of proposer:
+
+   Note:  For out-of-band attribute values, the IPP Designated Expert
+   will be the point of contact for the approved registration
+   specification, if any maintenance of the registration specification
+   is needed.
+
+
+
+Hastings, et al.            Standards Track                   [Page 172]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+12. APPENDIX A: Terminology
+
+   This specification document uses the terminology defined in this
+   section.
+
+12.1 Conformance Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and  "OPTIONAL" in this document are to be
+   interpreted as described in RFC 2119 [RFC2119].
+
+12.1.1 NEED NOT
+
+   This term is not included in RFC 2119.  The verb "NEED NOT" indicates
+   an action that the subject of the sentence does not have to implement
+   in order to claim conformance to the standard.  The verb "NEED NOT"
+   is used instead of "MAY NOT" since "MAY NOT" sounds like a
+   prohibition.
+
+12.2 Model Terminology
+
+12.2.1 Keyword
+
+   Keywords are used within this document as identifiers of semantic
+   entities within the abstract model (see section 4.1.2.3).  Attribute
+   names, some attribute values, attribute syntaxes, and attribute group
+   names are represented as keywords.
+
+12.2.2 Attributes
+
+   An attribute is an item of information that is associated with an
+   instance of an IPP object.  An attribute consists of an attribute
+   name and one or more attribute values.  Each attribute has a specific
+   attribute syntax.  All object attributes are defined in section 4 and
+   all operation attributes are defined in section 3.
+
+   Job Template Attributes are described in section 4.2. The client
+   optionally supplies Job Template attributes in a create request
+   (operation requests that create Job objects).  The Printer object has
+   associated attributes which define supported and default values for
+   the Printer.
+
+12.2.2.1 Attribute Name
+
+   Each attribute is uniquely identified in this document by its
+   attribute name.  An attribute name is a keyword.  The keyword
+   attribute name is given in the section header describing that
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 173]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   attribute.  In running text in this document, attribute names are
+   indicated inside double quotation marks (") where the quotation marks
+   are not part of the keyword itself.
+
+12.2.2.2 Attribute Group Name
+
+   Related attributes are grouped into named groups.  The name of the
+   group is a keyword.  The group name may be used in place of naming
+   all the attributes in the group explicitly.  Attribute groups are
+   defined in section 3.
+
+12.2.2.3 Attribute Value
+
+   Each attribute has one or more values.  Attribute values are
+   represented in the syntax type specified for that attribute. In
+   running text in this document, attribute values are indicated inside
+   single quotation marks ('), whether their attribute syntax is
+   keyword, integer, text, etc.  where the quotation marks are not part
+   of the value itself.
+
+12.2.2.4 Attribute Syntax
+
+   Each attribute is defined using an explicit syntax type.  In this
+   document, each syntax type is defined as a keyword with specific
+   meaning.  The "Encoding and Transport" document [RFC2910] indicates
+   the actual "on-the-wire" encoding rules for each syntax type.
+   Attribute syntax types are defined in section 4.1.
+
+12.2.3 Supports
+
+   By definition, a Printer object supports an attribute only if that
+   Printer object responds with the corresponding attribute populated
+   with some value(s) in a response to a query for that attribute.  A
+   Printer object supports an attribute value if the value is one of the
+   Printer object's "supported values" attributes.  The device behind a
+   Printer object may exhibit a behavior that corresponds to some IPP
+   attribute, but if the Printer object, when queried for that
+   attribute, doesn't respond with the attribute, then as far as IPP is
+   concerned, that implementation does not support that feature. If the
+   Printer object's "xxx-supported" attribute is not populated with a
+   particular value (even if that value is a legal value for that
+   attribute), then that Printer object does not support that particular
+   value.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 174]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   A conforming implementation MUST support all REQUIRED attributes.
+   However, even for REQUIRED attributes, conformance to IPP does not
+   mandate that all implementations support all possible values
+   representing all possible job processing behaviors and features.  For
+   example, if a given instance of a Printer supports only certain
+   document formats, then that Printer responds with the "document-
+   format-supported" attribute populated with a set of values, possibly
+   only one, taken from the entire set of possible values defined for
+   that attribute. This limited set of values represents the Printer's
+   set of supported document formats.  Supporting an attribute and some
+   set of values for that attribute enables IPP end users to be aware of
+   and make use of those features associated with that attribute and
+   those values.  If an implementation chooses to not support an
+   attribute or some specific value, then IPP end users would have no
+   ability to make use of that feature within the context of IPP itself.
+   However, due to existing practice and legacy systems which are not
+   IPP aware, there might be some other mechanism outside the scope of
+   IPP to control or request the "unsupported" feature (such as embedded
+   instructions within the document data itself).
+
+   For example, consider the "finishings-supported" attribute.
+
+      1) If a Printer object is not physically capable of stapling, the
+         "finishings-supported" attribute MUST NOT be populated with the
+         value of 'staple'.
+      2) A Printer object is physically capable of stapling, however an
+         implementation chooses not to support stapling in the IPP
+         "finishings" attribute.  In this case, 'staple' MUST NOT be a
+         value in the "finishings-supported" Printer object attribute.
+         Without support for the value 'staple', an IPP end user would
+         have no means within the protocol itself to request that a Job
+         be stapled.  However, an existing document data formatter might
+         be able to request that the document be stapled directly with
+         an embedded instruction within the document data.  In this
+         case, the IPP implementation does not "support" stapling,
+         however the end user is still able to have some control over
+         the stapling of the completed job.
+      3) A Printer object is physically capable of stapling, and an
+         implementation chooses to support stapling in the IPP
+         "finishings" attribute. In this case, 'staple' MUST be a value
+         in the "finishings-supported" Printer object attribute. Doing
+         so, would enable end users to be aware of and make use of the
+         stapling feature using IPP attributes.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 175]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Even though support for Job Template attributes by a Printer object
+   is OPTIONAL, it is RECOMMENDED that if the device behind a Printer
+   object is capable of realizing any feature or function that
+   corresponds to an IPP attribute and some associated value, then that
+   implementation SHOULD support that IPP attribute and value.
+
+   The set of values in any of the supported value attributes is set
+   (populated) by some administrative process or automatic sensing
+   mechanism that is outside the scope of this IPP/1.1 document.  For
+   administrative policy and control reasons, an administrator may
+   choose to make only a subset of possible values visible to the end
+   user.  In this case, the real output device behind the IPP Printer
+   abstraction may be capable of a certain feature, however an
+   administrator is specifying that access to that feature not be
+   exposed to the end user through the IPP protocol.  Also, since a
+   Printer object may represent a logical print device (not just a
+   physical device) the actual process for supporting a value is
+   undefined and left up to the implementation.  However, if a Printer
+   object supports a value, some manual human action may be needed to
+   realize the semantic action associated with the value, but no end
+   user action is required.
+
+   For example, if one of the values in the "finishings-supported"
+   attribute is 'staple', the actual process might be an automatic
+   staple action by a physical device controlled by some command sent to
+   the device.  Or, the actual process of stapling might be a manual
+   action by an operator at an operator attended Printer object.
+
+   For another example of how supported attributes function, consider a
+   system administrator who desires to control all print jobs so that no
+   job sheets are printed in order to conserve paper.  To force no job
+   sheets, the system administrator sets the only supported value for
+   the "job-sheets-supported" attribute to 'none'.  In this case, if a
+   client requests anything except 'none', the create request is
+   rejected or the "job-sheets" value is ignored (depending on the value
+   of "ipp-attribute-fidelity").  To force the use of job start/end
+   sheets on all jobs, the administrator does not include the value
+   'none' in the "job-sheets- supported" attribute.  In this case, if a
+   client requests 'none', the create request is rejected or the "job-
+   sheets" value is ignored (again depending on the value of "ipp-
+   attribute-fidelity").
+
+12.2.4 print-stream page
+
+   A "print-stream page" is a page according to the definition of pages
+   in the language used to express the document data.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 176]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+12.2.5 impression
+
+   An "impression" is the image (possibly many print-stream pages in
+   different configurations) imposed onto a single media page.
+
+13. APPENDIX B:  Status Codes and Suggested Status Code Messages
+
+   This section defines status code enum keywords and values that are
+   used to provide semantic information on the results of an operation
+   request.  Each operation response MUST include a status code.  The
+   response MAY also contain a status message that provides a short
+   textual description of the status.  The status code is intended for
+   use by automata, and the status message is intended for the human end
+   user.  Since the status message is an OPTIONAL component of the
+   operation response, an IPP application (i.e., a browser, GUI, print
+   driver or gateway) is NOT REQUIRED to examine or display the status
+   message, since it MAY not be returned to the application.
+
+   The prefix of the status keyword defines the class of response as
+   follows:
+
+      "informational" - Request received, continuing process
+      "successful" - The action was successfully received, understood,
+         and accepted
+      "redirection" - Further action must be taken in order to complete
+         the request
+      "client-error" - The request contains bad syntax or cannot be
+         fulfilled
+      "server-error" - The IPP object  failed to fulfill an apparently
+         valid request
+
+   As with type2 enums, IPP status codes are extensible.  IPP clients
+   are NOT REQUIRED to understand the meaning of all registered status
+   codes, though such understanding is obviously desirable.  However,
+   IPP clients MUST understand the class of any status code, as
+   indicated by the prefix, and treat any unrecognized response as being
+   equivalent to the first status code of that class, with the exception
+   that an unrecognized response MUST NOT be cached.  For example, if an
+   unrecognized status code of "client-error-xxx-yyy" 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 "client-
+   error-bad-request" status code.  In such cases, IPP applications
+   SHOULD present the OPTIONAL message (if present) to the end user
+   since the message is likely to contain human readable information
+   which will help to explain the unusual status.  The name of the enum
+   is the suggested status message for US English.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 177]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The status code values range from 0x0000 to 0x7FFF.  The value ranges
+   for each status code class are as follows:
+
+      "successful" - 0x0000 to 0x00FF
+      "informational" - 0x0100 to 0x01FF
+      "redirection" - 0x0200 to 0x02FF
+      "client-error" - 0x0400 to 0x04FF
+      "server-error" - 0x0500 to 0x05FF
+
+   The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0
+   to 5) is reserved for vendor use within each status code class.
+   Values 0x0600 to 0x7FFF are reserved for future assignment by IETF
+   standards track documents and MUST NOT be used.
+
+13.1 Status Codes
+
+   Each status code is described below. Section 13.1.5.9 contains a
+   table that indicates which status codes apply to which operations.
+   The Implementer's Guide [IPP-IIG] describe the suggested steps for
+   processing IPP attributes for all operations, including returning
+   status codes.
+
+13.1.1 Informational
+
+   This class of status code indicates a provisional response and is to
+   be used for informational purposes only.
+
+   There are no status codes defined in IPP/1.1 for this class of status
+   code.
+
+13.1.2 Successful Status Codes
+
+   This class of status code indicates that the client's request was
+   successfully received, understood, and accepted.
+
+13.1.2.1 successful-ok (0x0000)
+
+   The request has succeeded and no request attributes were substituted
+   or ignored.  In the case of a response to a create request, the
+   'successful-ok' status code indicates that the request was
+   successfully received and validated, and that the Job object has been
+   created; it does not indicate that the job has been processed.  The
+   transition of the Job object into the 'completed' state is the only
+   indicator that the job has been printed.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 178]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)
+
+   The request has succeeded, but some supplied (1) attributes were
+   ignored or (2) unsupported values were substituted with supported
+   values or were ignored in order to perform the operation without
+   rejecting it.  Unsupported attributes, attribute syntaxes, or values
+   MUST be returned in the Unsupported Attributes group of the response
+   for all operations.  There is an exception to this rule for the query
+   operations:  Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes
+   for the "requested-attributes" operation attribute only.  When the
+   supplied values of the "requested-attributes" operation attribute are
+   requesting attributes that are not supported, the IPP object MAY, but
+   is NOT REQUIRED to, return the "requested-attributes" attribute in
+   the Unsupported Attribute response group (with the unsupported values
+   only).  See sections 3.1.7 and 3.2.1.2.
+
+13.1.2.3 successful-ok-conflicting-attributes (0x0002)
+
+   The request has succeeded, but some supplied attribute values
+   conflicted with the values of other supplied attributes.  These
+   conflicting values were either (1) substituted with (supported)
+   values or (2) the attributes were removed in order to process the job
+   without rejecting it.  Attributes or values which conflict with other
+   attributes and have been substituted or ignored MUST be returned in
+   the Unsupported Attributes group of the response for all operations
+   as supplied by the client.  See sections 3.1.7 and 3.2.1.2.
+
+13.1.3 Redirection Status Codes
+
+   This class of status code indicates that further action needs to be
+   taken to fulfill the request.
+
+   There are no status codes defined in IPP/1.1 for this class of status
+   code.
+
+13.1.4 Client Error Status Codes
+
+   This class of status code is intended for cases in which the client
+   seems to have erred.  The IPP object SHOULD return a message
+   containing an explanation of the error situation and whether it is a
+   temporary or permanent condition.
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 179]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.4.1 client-error-bad-request (0x0400)
+
+   The request could not be understood by the IPP object due to
+   malformed syntax (such as the value of a fixed length attribute whose
+   length does not match the prescribed length for that attribute - see
+   the Implementer's Guide [IPP-IIG] ).  The IPP application SHOULD NOT
+   repeat the request without modifications.
+
+13.1.4.2 client-error-forbidden (0x0401)
+
+   The IPP object understood the request, but is refusing to fulfill it.
+   Additional authentication information or authorization credentials
+   will not help and the request SHOULD NOT be repeated.  This status
+   code is commonly used when the IPP object does not wish to reveal
+   exactly why the request has been refused or when no other response is
+   applicable.
+
+13.1.4.3 client-error-not-authenticated (0x0402)
+
+   The request requires user authentication.  The IPP client may repeat
+   the request with suitable authentication information. If the request
+   already included authentication information, then this status code
+   indicates that authorization has been refused for those credentials.
+   If this response contains the same challenge as the prior response,
+   and the user agent has already attempted authentication at least
+   once, then the response message may contain relevant diagnostic
+   information.  This status codes reveals more information than
+   "client-error-forbidden".
+
+13.1.4.4 client-error-not-authorized (0x0403)
+
+   The requester is not authorized to perform the request.  Additional
+   authentication information or authorization credentials will not help
+   and the request SHOULD NOT be repeated.  This status code is used
+   when the IPP object wishes to reveal that the authentication
+   information is understandable, however, the requester is explicitly
+   not authorized to perform the request.  This status codes reveals
+   more information than "client-error-forbidden" and "client-error-
+   not-authenticated".
+
+13.1.4.5 client-error-not-possible (0x0404)
+
+   This status code is used when the request is for something that can
+   not happen.  For example, there might be a request to cancel a job
+   that has already been canceled or aborted by the system.  The IPP
+   client SHOULD NOT repeat the request.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 180]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.4.6 client-error-timeout (0x0405)
+
+   The client did not produce a request within the time that the IPP
+   object was prepared to wait.  For example, a client issued a Create-
+   Job operation and then, after a long period of time, issued a Send-
+   Document operation and this error status code was returned in
+   response to the Send-Document request  (see section 3.3.1).  The IPP
+   object might have been forced to clean up resources that had been
+   held for the waiting additional Documents.  The IPP object was forced
+   to close the Job since the client took too long.  The client SHOULD
+   NOT repeat the request without modifications.
+
+13.1.4.7 client-error-not-found (0x0406)
+
+   The IPP object has not found anything matching the request URI.  No
+   indication is given of whether the condition is temporary or
+   permanent.  For example, a client with an old reference to a Job (a
+   URI) tries to cancel the Job, however in the mean time the Job might
+   have been completed and all record of it at the Printer has been
+   deleted.  This status code, 'client-error-not-found' is returned
+   indicating that the referenced Job can not be found.  This error
+   status code is also used when a client supplies a URI as a reference
+   to the document data in either a Print-URI or Send-URI operation, but
+   the document can not be found.
+
+   In practice, an IPP application should avoid a not found situation by
+   first querying and presenting a list of valid Printer URIs and Job
+   URIs to the end-user.
+
+13.1.4.8 client-error-gone (0x0407)
+
+   The requested object is no longer available and no forwarding address
+   is known.  This condition should be considered permanent.  Clients
+   with link editing capabilities should delete references to the
+   request URI after user approval.  If the IPP object does not know or
+   has no facility to determine, whether or not the condition is
+   permanent, the status code "client-error-not-found" should be used
+   instead.
+
+   This response is primarily intended to assist the task of maintenance
+   by notifying the recipient that the resource is intentionally
+   unavailable and that the IPP object administrator desires that remote
+   links to that resource be removed. 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 IPP
+   object administrator and/or Printer implementation.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 181]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.4.9 client-error-request-entity-too-large (0x0408)
+
+   The IPP object is refusing to process a request because the request
+   entity is larger than the IPP object is willing or able to process.
+   An IPP Printer returns this status code when it limits the size of
+   print jobs and it receives a print job that exceeds that limit or
+   when the attributes are so many that their encoding causes the
+   request entity to exceed IPP object capacity.
+
+13.1.4.10 client-error-request-value-too-long (0x0409)
+
+   The IPP object is refusing to service the request because one or more
+   of the client-supplied attributes has a variable length value that is
+   longer than the maximum length specified for that attribute.  The IPP
+   object might not have sufficient resources (memory, buffers, etc.) to
+   process (even temporarily), interpret, and/or ignore a value larger
+   than the maximum length.  Another use of this error code is when the
+   IPP object supports the processing of a large value that is less than
+   the maximum length, but during the processing of the request as a
+   whole, the object may pass the value onto some other system component
+   which is not able to accept the large value.  For more details, see
+   the Implementer's Guide [IPP-IIG] .
+
+   Note:  For attribute values that are URIs, this rare condition is
+   only likely to occur when a client has improperly submitted a request
+   with long query information (e.g. an IPP application allows an end-
+   user to enter an invalid URI), when the client has descended into a
+   URI "black hole" of redirection (e.g., a redirected URI prefix that
+   points to a suffix of itself), or when the IPP object is under attack
+   by a client attempting to exploit security holes present in some IPP
+   objects using fixed-length buffers for reading or manipulating the
+   Request-URI.
+
+13.1.4.11 client-error-document-format-not-supported (0x040A)
+
+   The IPP object is refusing to service the request because the
+   document data is in a format, as specified in the "document-format"
+   operation attribute, that is not supported by the Printer object.
+   This error is returned independent of the client-supplied "ipp-
+   attribute-fidelity".  The Printer object MUST return this status
+   code, even if there are other Job Template attributes that are not
+   supported as well, since this error is a bigger problem than with Job
+   Template attributes.  See sections 3.1.6.1, 3.1.7, and 3.2.1.1.
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 182]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
+
+   In a create request, if the Printer object does not support one or
+   more attributes, attribute syntaxes, or attribute values supplied in
+   the request and the client supplied the "ipp-attribute-fidelity"
+   operation attribute with the 'true' value, the Printer object MUST
+   return this status code.  The Printer object MUST also return in the
+   Unsupported Attributes Group all the attributes and/or values
+   supplied by the client that are not supported.  See section 3.1.7.
+   For example, if the request indicates 'iso-a4' media, but that media
+   type is not supported by the Printer object.  Or, if the client
+   supplies a Job Template attribute and the attribute itself is not
+   even supported by the Printer.  If the "ipp-attribute-fidelity"
+   attribute is 'false', the Printer MUST ignore or substitute values
+   for unsupported Job Template attributes and values rather than reject
+   the request and return this status code.
+
+   For any operation where a client requests attributes (such as a Get-
+   Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if
+   the IPP object does not support one or more of the requested
+   attributes, the IPP object simply ignores the unsupported requested
+   attributes and processes the request as if they had not been
+   supplied, rather than returning this status code.  In this case, the
+   IPP object MUST return the 'successful-ok-ignored-or-substituted-
+   attributes' status code and MAY return the unsupported attributes as
+   values of the "requested-attributes" in the Unsupported Attributes
+   Group (see section 13.1.2.2).
+
+13.1.4.13 client-error-uri-scheme-not-supported (0x040C)
+
+   The scheme of the client-supplied URI in a Print-URI or a Send-URI
+   operation is not supported.  See sections 3.1.6.1 and 3.1.7.
+
+13.1.4.14 client-error-charset-not-supported (0x040D)
+
+   For any operation, if the IPP Printer does not support the charset
+   supplied by the client in the "attributes-charset" operation
+   attribute, the Printer MUST reject the operation and return this
+   status and any 'text' or 'name' attributes using the 'utf-8' charset
+   (see Section 3.1.4.1).  See sections 3.1.6.1 and  3.1.7.
+
+13.1.4.15 client-error-conflicting-attributes (0x040E)
+
+   The request is rejected because some attribute values conflicted with
+   the values of other attributes which this document does not permit to
+   be substituted or ignored.  The Printer object MUST also return in
+   the Unsupported Attributes Group the conflicting attributes supplied
+   by the client.  See sections 3.1.7 and 3.2.1.2.
+
+
+
+Hastings, et al.            Standards Track                   [Page 183]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.4.16 client-error-compression-not-supported (0x040F)
+
+   The IPP object is refusing to service the request because the
+   document data, as specified in the "compression" operation attribute,
+   is compressed in a way that is not supported by the Printer object.
+   This error is returned independent of the client-supplied "ipp-
+   attribute-fidelity".  The Printer object MUST return this status
+   code, even if there are other Job Template attributes that are not
+   supported as well, since this error is a bigger problem than with Job
+   Template attributes.  See sections 3.1.6.1, 3.1.7, and 3.2.1.1.
+
+13.1.4.17 client-error-compression-error (0x0410)
+
+   The IPP object is refusing to service the request because the
+   document data cannot be decompressed when using the algorithm
+   specified by the "compression" operation attribute.  This error is
+   returned independent of the client-supplied "ipp-attribute-fidelity".
+   The Printer object MUST return this status code, even if there are
+   Job Template attributes that are not supported as well, since this
+   error is a bigger problem than with Job Template attributes.  See
+   sections 3.1.7 and 3.2.1.1.
+
+13.1.4.18 client-error-document-format-error (0x0411)
+
+   The IPP object is refusing to service the request because Printer
+   encountered an error in the document data while interpreting it.
+   This error is returned independent of the client-supplied "ipp-
+   attribute-fidelity".  The Printer object MUST return this status
+   code, even if there are Job Template attributes that are not
+   supported as well, since this error is a bigger problem than with Job
+   Template attributes.  See sections 3.1.7 and 3.2.1.1.
+
+13.1.4.19 client-error-document-access-error (0x0412)
+
+   The IPP object is refusing to service the Print-URI or Send-URI
+   request because Printer encountered an access error while attempting
+   to validate the accessibility or access the document data specified
+   in the "document-uri" operation attribute.  The Printer MAY also
+   return a specific document access error code using the "document-
+   access-error" operation attribute (see section 3.1.6.4).  This error
+   is returned independent of the client-supplied "ipp-attribute-
+   fidelity".  The Printer object MUST return this status code, even if
+   there are Job Template attributes that are not supported as well,
+   since this error is a bigger problem than with Job Template
+   attributes.  See sections 3.1.6.1 and 3.1.7.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 184]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.5 Server Error Status Codes
+
+   This class of status codes indicates cases in which the IPP object is
+   aware that it has erred or is incapable of performing the request.
+   The IPP object SHOULD include a message containing an explanation of
+   the error situation, and whether it is a temporary or permanent
+   condition.
+
+13.1.5.1 server-error-internal-error (0x0500)
+
+   The IPP object encountered an unexpected condition that prevented it
+   from fulfilling the request.  This error status code differs from
+   "server-error-temporary-error" in that it implies a more permanent
+   type of internal error.  It also differs from "server-error-device-
+   error" in that it implies an unexpected condition (unlike a paper-jam
+   or out-of-toner problem which is undesirable but expected).  This
+   error status code indicates that probably some knowledgeable human
+   intervention is required.
+
+13.1.5.2 server-error-operation-not-supported (0x0501)
+
+   The IPP object does not support the functionality required to fulfill
+   the request. This is the appropriate response when the IPP object
+   does not recognize an operation or is not capable of supporting it.
+   See sections 3.1.6.1 and 3.1.7.
+
+13.1.5.3 server-error-service-unavailable (0x0502)
+
+   The IPP object is currently unable to handle the request due to a
+   temporary overloading or maintenance of the IPP object.  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 the message.  If no delay is given, the IPP application
+   should handle the response as it would for a "server-error-
+   temporary-error" response.  If the condition is more permanent, the
+   error status codes "client-error-gone" or "client-error-not-found"
+   could be used.
+
+13.1.5.4 server-error-version-not-supported (0x0503)
+
+   The IPP object does not support, or refuses to support, the IPP
+   protocol version that was supplied as the value of the "version-
+   number" operation parameter in the request.  The IPP object is
+   indicating that it is unable or unwilling to complete the request
+   using the same major and minor version number as supplied in the
+   request other than with this error message. The error response SHOULD
+   contain a "status-message" attribute (see section 3.1.6.2) describing
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 185]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   why that version is not supported and what other versions are
+   supported by that IPP object.  See sections 3.1.6.1, 3.1.7, and
+   3.1.8.
+
+   The error response MUST identify in the "version-number" operation
+   parameter the closest version number that the IPP object does
+   support.  For example, if a client supplies version '1.0' and an
+   IPP/1.1 object supports version '1.0', then it responds with version
+   '1.0' in all responses to such a request.  If the IPP/1.1 object does
+   not support version '1.0', then it should accept the request and
+   respond with version '1.1' or may reject the request and respond with
+   this error code and version
+   '1.1'.  If a client supplies a version '1.2', the IPP/1.1 object
+   should accept the request and return version '1.1' or may reject the
+   request and respond with this error code and version '1.1'.  See
+   sections 3.1.8 and 4.4.14.
+
+13.1.5.5 server-error-device-error (0x0504)
+
+   A printer error, such as a paper jam, occurs while the IPP object
+   processes a Print or Send operation.  The response contains the true
+   Job Status (the values of the "job-state" and "job-state-reasons"
+   attributes).  Additional information can be returned in the OPTIONAL
+   "job-state-message" attribute value or in the OPTIONAL status message
+   that describes the error in more detail.  This error status code is
+   only returned in situations where the Printer is unable to accept the
+   create request because of such a device error.  For example, if the
+   Printer is unable to spool, and can only accept one job at a time,
+   the reason it might reject a create request is that the printer
+   currently has a paper jam.  In many cases however, where the Printer
+   object can accept the request even though the Printer has some error
+   condition, the 'successful-ok' status code will be returned.  In such
+   a case, the client would look at the returned Job Object Attributes
+   or later query the Printer to determine its state and state reasons.
+
+13.1.5.6 server-error-temporary-error (0x0505)
+
+   A temporary error such as a buffer full write error, a memory
+   overflow (i.e. the document data exceeds the memory of the Printer),
+   or a disk full condition, occurs while the IPP Printer processes an
+   operation.  The client MAY try the unmodified request again at some
+   later point in time with an expectation that the temporary internal
+   error condition may have been cleared.  Alternatively, as an
+   implementation option, a Printer object MAY delay the response until
+   the temporary condition is cleared so that no error is returned.
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 186]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+13.1.5.7 server-error-not-accepting-jobs (0x0506)
+
+   A temporary error indicating that the Printer is not currently
+   accepting jobs, because the administrator has set the value of the
+   Printer's "printer-is-accepting-jobs" attribute to 'false' (by means
+   outside the scope of this IPP/1.1 document).
+
+13.1.5.8 server-error-busy (0x0507)
+
+   A temporary error indicating that the Printer is too busy processing
+   jobs and/or other requests. The client SHOULD try the unmodified
+   request again at some later point in time with an expectation that
+   the temporary busy condition will have been cleared.
+
+13.1.5.9 server-error-job-canceled (0x0508)
+
+   An error indicating that the job has been canceled by an operator or
+   the system while the client was transmitting the data to the IPP
+   Printer.  If a job-id and job-uri had been created, then they are
+   returned in the Print-Job, Send-Document, or Send-URI response as
+   usual; otherwise, no job-id and job-uri are returned in the response.
+
+13.1.5.10 server-error-multiple-document-jobs-not-supported (0x0509)
+
+   The IPP object does not support multiple documents per job and a
+   client attempted to supply document data with a second Send-Document
+   or Send-URI operation.
+
+13.2 Status Codes for IPP Operations
+
+   PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document
+   SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and
+   Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 187]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+                                                  IPP Operations
+   IPP Status Keyword                       PJ PU CJ SD SU V GA GJ C
+   ------------------                       -- -- -- -- -- - -- -- -
+   successful-ok                            x  x  x  x  x  x x  x  x
+   successful-ok-ignored-or-substituted-    x  x  x  x  x  x x  x  x
+        attributes
+   successful-ok-conflicting-attributes     x  x  x  x  x  x x  x  x
+   client-error-bad-request                 x  x  x  x  x  x x  x  x
+   client-error-forbidden                   x  x  x  x  x  x x  x  x
+   client-error-not-authenticated           x  x  x  x  x  x x  x  x
+   client-error-not-authorized              x  x  x  x  x  x x  x  x
+   client-error-not-possible                x  x  x  x  x  x x  x  x
+   client-error-timeout                              x  x
+   client-error-not-found                   x  x  x  x  x  x x  x  x
+   client-error-gone                        x  x  x  x  x  x x  x  x
+   client-error-request-entity-too-large    x  x  x  x  x  x x  x  x
+   client-error-request-value-too-long      x  x  x  x  x  x x  x  x
+   client-error-document-format-not-        x  x     x  x  x x
+        supported
+   client-error-attributes-or-values-not-   x  x  x  x  x  x x  x  x
+        supported
+   client-error-uri-scheme-not-supported       x        x
+   client-error-charset-not-supported       x  x  x  x  x  x x  x  x
+   client-error-conflicting-attributes      x  x  x  x  x  x x  x  x
+   client-error-compression-not-supported   x  x     x  x  x
+   client-error-compression-error           x  x     x  x
+   client-error-document-format-error       x  x     x  x
+   client-error-document-access-error          x        x
+   server-error-internal-error              x  x  x  x  x  x x  x  x
+   server-error-operation-not-supported        x  x  x  x
+   server-error-service-unavailable         x  x  x  x  x  x x  x  x
+   server-error-version-not-supported       x  x  x  x  x  x x  x  x
+   server-error-device-error                x  x  x  x  x
+   server-error-temporary-error             x  x  x  x  x
+   server-error-not-accepting-jobs          x  x  x        x
+   server-error-busy                        x  x  x  x  x  x x  x  x
+   server-error-job-canceled                x        x  x
+   server-error-multiple-document-jobs-              x  x
+          not-supported
+
+   HJ = Hold-Job, RJ = Release-Job, RS = Restart-Job
+   PP = Pause-Printer, RP = Resume-Printer, PJ = Purge-Jobs
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 188]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+                                            IPP Operations (cont.)
+   IPP Status Keyword                       HJ RJ RS PP RP PJ
+   ------------------                       -- -- -- -- -- --
+   successful-ok                            x  x  x  x  x  x
+   successful-ok-ignored-or-substituted-    x  x  x  x  x  x
+        attributes
+   successful-ok-conflicting-attributes     x  x  x  x  x  x
+   client-error-bad-request                 x  x  x  x  x  x
+   client-error-forbidden                   x  x  x  x  x  x
+   client-error-not-authenticated           x  x  x  x  x  x
+   client-error-not-authorized              x  x  x  x  x  x
+   client-error-not-possible                x  x  x  x  x  x
+   client-error-timeout
+   client-error-not-found                   x  x  x  x  x  x
+   client-error-gone                        x  x  x  x  x  x
+   client-error-request-entity-too-large    x  x  x  x  x  x
+   client-error-request-value-too-long      x  x  x  x  x  x
+   client-error-document-format-not-
+        supported
+   client-error-attributes-or-values-not-   x  x  x  x  x  x
+        supported
+   client-error-uri-scheme-not-supported
+   client-error-charset-not-supported       x  x  x  x  x  x
+   client-error-conflicting-attributes      x  x  x  x  x  x
+   client-error-compression-not-supported
+   client-error-compression-error
+   client-error-document-format-error
+   client-error-document-access-error
+   server-error-internal-error              x  x  x  x  x  x
+   server-error-operation-not-supported     x  x  x  x  x  x
+   server-error-service-unavailable         x  x  x  x  x  x
+   server-error-version-not-supported       x  x  x  x  x  x
+   server-error-device-error
+   server-error-temporary-error             x  x  x  x  x  x
+   server-error-not-accepting-jobs
+   server-error-busy                        x  x  x  x  x  x
+   server-error-job-canceled
+   server-error-multiple-document-jobs-
+          not-supported
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 189]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+14.  APPENDIX C:  "media" keyword values
+
+   Standard keyword values are taken from several sources.
+
+   Standard values are defined (taken from DPA[ISO10175] and the Printer
+   MIB[RFC1759]):
+
+    'default': The default medium for the output device
+    'iso-a4-white': Specifies the ISO A4 white medium: 210 mm x 297 mm
+    'iso-a4-colored': Specifies the ISO A4 colored medium: 210 mm x 297
+       mm
+    'iso-a4-transparent' Specifies the ISO A4 transparent medium: 210 mm
+       x 297 mm
+    'iso-a3-white': Specifies the ISO A3 white medium: 297 mm x 420 mm
+    'iso-a3-colored': Specifies the ISO A3 colored medium: 297 mm x 420
+       mm
+    'iso-a5-white': Specifies the ISO A5 white medium: 148 mm x 210 mm
+    'iso-a5-colored': Specifies the ISO A5 colored medium: 148 mm x 210
+       mm
+    'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm
+    'iso-b4-colored': Specifies the ISO B4 colored medium: 250 mm x 353
+       mm
+    'iso-b5-white': Specifies the ISO B5 white medium: 176 mm x 250 mm
+    'iso-b5-colored': Specifies the ISO B5 colored medium: 176 mm x 250
+       mm
+    'jis-b4-white': Specifies the JIS B4 white medium: 257 mm x 364 mm
+    'jis-b4-colored': Specifies the JIS B4 colored medium: 257 mm x 364
+       mm
+    'jis-b5-white': Specifies the JIS B5 white medium: 182 mm x 257 mm
+    'jis-b5-colored': Specifies the JIS B5 colored medium: 182 mm x 257
+       mm
+
+   The following standard values are defined for North American media:
+
+    'na-letter-white': Specifies the North American letter white medium
+    'na-letter-colored': Specifies the North American letter colored
+       medium
+    'na-letter-transparent': Specifies the North American letter
+       transparent medium
+    'na-legal-white': Specifies the North American legal white medium
+    'na-legal-colored': Specifies the North American legal colored
+       medium
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 190]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The following standard values are defined for envelopes:
+
+    'iso-b4-envelope': Specifies the ISO B4 envelope medium
+    'iso-b5-envelope': Specifies the ISO B5 envelope medium
+    'iso-c3-envelope': Specifies the ISO C3 envelope medium
+    'iso-c4-envelope': Specifies the ISO C4 envelope medium
+    'iso-c5-envelope': Specifies the ISO C5 envelope medium
+    'iso-c6-envelope': Specifies the ISO C6 envelope medium
+    'iso-designated-long-envelope': Specifies the ISO Designated Long
+       envelope medium
+    'na-10x13-envelope': Specifies the North American 10x13 envelope
+       medium
+    'na-9x12-envelope': Specifies the North American 9x12 envelope
+       medium
+    'monarch-envelope': Specifies the Monarch envelope
+    'na-number-10-envelope': Specifies the North American number 10
+       business envelope medium
+    'na-7x9-envelope': Specifies the North American 7x9 inch envelope
+    'na-9x11-envelope': Specifies the North American 9x11 inch
+       envelope
+    'na-10x14-envelope': Specifies the North American 10x14 inch
+       envelope
+    'na-number-9-envelope': Specifies the North American number 9
+       business envelope
+    'na-6x9-envelope': Specifies the North American 6x9 inch envelope
+    'na-10x15-envelope': Specifies the North American 10x15 inch
+       envelope
+
+   The following standard values are defined for the less commonly used
+   media:
+
+ 'executive-white': Specifies the white executive medium
+ 'folio-white': Specifies the folio white medium
+ 'invoice-white': Specifies the white invoice medium
+ 'ledger-white': Specifies the white ledger medium
+ 'quarto-white': Specified the white quarto medium
+ 'iso-a0-white': Specifies the ISO A0 white medium: 841 mm x 1189 mm
+ 'iso-a0-transparent': Specifies the ISO A0 transparent medium: 841 mm
+    x 1189 mm
+ 'iso-a0-translucent': Specifies the ISO A0 translucent medium: 841 mm
+    x 1189 mm
+ 'iso-a1-white': Specifies the ISO A1 white medium: 594 mm x 841 mm
+ 'iso-a1-transparent': Specifies the ISO A1 transparent medium: 594 mm
+    x 841 mm
+ 'iso-a1-translucent': Specifies the ISO A1 translucent medium: 594 mm
+    x 841 mm
+ 'iso-a2-white': Specifies the ISO A2 white medium: 420 mm x 594 mm
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 191]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'iso-a2-transparent': Specifies the ISO A2 transparent medium: 420 mm
+    x 594 mm
+ 'iso-a2-translucent': Specifies the ISO A2 translucent medium: 420 mm
+    x 594 mm
+ 'iso-a3-transparent': Specifies the ISO A3 transparent medium: 297 mm
+    x 420 mm
+ 'iso-a3-translucent': Specifies the ISO A3 translucent medium: 297 mm
+    x 420 mm
+ 'iso-a4-translucent': Specifies the ISO A4 translucent medium: 210 mm
+    x 297 mm
+ 'iso-a5-transparent': Specifies the ISO A5 transparent medium: 148 mm
+    x 210 mm
+ 'iso-a5-translucent': Specifies the ISO A5 translucent medium: 148 mm
+    x 210 mm
+ 'iso-a6-white': Specifies the ISO A6 white medium: 105 mm x 148 mm
+ 'iso-a7-white': Specifies the ISO A7 white medium: 74 mm x 105 mm
+ 'iso-a8-white': Specifies the ISO A8 white medium: 52 mm x 74 mm
+ 'iso-a9-white': Specifies the ISO A9 white medium: 37 mm x 52 mm
+ 'iso-a10-white': Specifies the ISO A10 white medium: 26 mm x 37 mm
+ 'iso-b0-white': Specifies the ISO B0 white medium: 1000 mm x 1414 mm
+ 'iso-b1-white': Specifies the ISO B1 white medium: 707 mm x 1000 mm
+ 'iso-b2-white': Specifies the ISO B2 white medium: 500 mm x 707 mm
+ 'iso-b3-white': Specifies the ISO B3 white medium: 353 mm x 500 mm
+ 'iso-b6-white': Specifies the ISO B6 white medium: 125 mm x 176 mm
+ 'iso-b7-white': Specifies the ISO B7 white medium: 88 mm x 125 mm
+ 'iso-b8-white': Specifies the ISO B8 white medium: 62 mm x 88 mm
+ 'iso-b9-white': Specifies the ISO B9 white medium: 44 mm x 62 mm
+ 'iso-b10-white': Specifies the ISO B10 white medium: 31 mm x 44 mm
+ 'jis-b0-white': Specifies the JIS B0 white medium: 1030 mm x 1456 mm
+ 'jis-b0-transparent': Specifies the JIS B0 transparent medium: 1030
+    mm x 1456 mm
+ 'jis-b0-translucent': Specifies the JIS B0 translucent medium: 1030
+    mm x 1456 mm
+ 'jis-b1-white': Specifies the JIS B1 white medium: 728 mm x 1030 mm
+ 'jis-b1-transparent': Specifies the JIS B1 transparent medium: 728 mm
+    x 1030 mm
+ 'jis-b1-translucent': Specifies the JIS B1 translucent medium: 728 mm
+    x 1030 mm
+ 'jis-b2-white': Specifies the JIS B2 white medium: 515 mm x 728 mm
+ 'jis-b2-transparent': Specifies the JIS B2 transparent medium: 515 mm
+    x 728 mm
+ 'jis-b2-translucent': Specifies the JIS B2 translucent medium: 515 mm
+    x 728 mm
+ 'jis-b3-white': Specifies the JIS B3 white medium: 364 mm x 515 mm
+ 'jis-b3-transparent': Specifies the JIS B3 transparent medium: 364 mm
+    x 515 mm
+ 'jis-b3-translucent': Specifies the JIS B3 translucent medium: 364 mm
+    x 515 mm
+
+
+
+Hastings, et al.            Standards Track                   [Page 192]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'jis-b4-transparent': Specifies the JIS B4 transparent medium: 257 mm
+    x 364 mm
+ 'jis-b4-translucent': Specifies the JIS B4 translucent medium: 257 mm
+    x 364 mm
+ 'jis-b5-transparent': Specifies the JIS B5 transparent medium: 182 mm
+    x 257 mm
+ 'jis-b5-translucent': Specifies the JIS B5 translucent medium: 182 mm
+    x 257 mm
+ 'jis-b6-white': Specifies the JIS B6 white medium: 128 mm x 182 mm
+ 'jis-b7-white': Specifies the JIS B7 white medium: 91 mm x 128 mm
+ 'jis-b8-white': Specifies the JIS B8 white medium: 64 mm x 91 mm
+ 'jis-b9-white': Specifies the JIS B9 white medium: 45 mm x 64 mm
+ 'jis-b10-white': Specifies the JIS B10 white medium: 32 mm x 45 mm
+
+   The following standard values are defined for American Standard (i.e.
+   ANSI) engineering media:
+
+    'a-white': Specifies the engineering ANSI A size white medium: 8.5
+       inches x 11 inches
+    'a-transparent': Specifies the engineering ANSI A size transparent
+       medium: 8.5 inches x 11 inches
+    'a-translucent': Specifies the engineering ANSI A size translucent
+       medium: 8.5 inches x 11 inches
+    'b-white': Specifies the engineering ANSI B size white medium: 11
+       inches x 17 inches
+    'b-transparent': Specifies the engineering ANSI B size transparent
+       medium: 11 inches x 17 inches)
+    'b-translucent': Specifies the engineering ANSI B size translucent
+       medium: 11 inches x 17 inches
+    'c-white': Specifies the engineering ANSI C size white medium: 17
+       inches x 22 inches
+    'c-transparent': Specifies the engineering ANSI C size transparent
+       medium: 17 inches x 22 inches
+    'c-translucent': Specifies the engineering ANSI C size translucent
+       medium: 17 inches x 22 inches
+    'd-white': Specifies the engineering ANSI D size white medium: 22
+       inches x 34 inches
+    'd-transparent': Specifies the engineering ANSI D size transparent
+       medium: 22 inches x 34 inches
+    'd-translucent': Specifies the engineering ANSI D size translucent
+       medium: 22 inches x 34 inches
+    'e-white': Specifies the engineering ANSI E size white medium: 34
+       inches x 44 inches
+    'e-transparent': Specifies the engineering ANSI E size transparent
+       medium: 34 inches x 44 inches
+    'e-translucent': Specifies the engineering ANSI E size translucent
+       medium: 34 inches x 44 inches
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 193]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The following standard values are defined for American Standard (i.e.
+   ANSI) engineering media for devices that provide the "synchro-cut"
+   feature (see section 14.1):
+
+ 'axsynchro-white': Specifies the roll paper having the width of the
+    longer edge (11 inches) of the engineering ANSI A size white medium
+    and cuts synchronizing with data.
+ 'axsynchro-transparent': Specifies the roll paper having the width of
+    the longer edge (11 inches) of the engineering ANSI A size
+    transparent medium and cuts synchronizing with data.
+ 'axsynchro-translucent': Specifies the roll paper having the width of
+    the longer edge (11 inches) of the engineering ANSI A size
+    translucent medium and cuts synchronizing with data.
+ 'bxsynchro-white': Specifies the roll paper having the width of the
+    longer edge (17 inches) of the engineering ANSI B size white medium
+    and cuts synchronizing with data.
+ 'bxsynchro-transparent': Specifies the roll paper having the width of
+    the longer edge (17 inches) of the engineering ANSI B size
+    transparent medium and cuts synchronizing with data.
+ 'bxsynchro-translucent': Specifies the roll paper having the width of
+    the longer edge (17 inches) of the engineering ANSI B size
+    translucent medium and cuts synchronizing with data.
+ 'cxsynchro-white': Specifies the roll paper having the width of the
+    longer edge (22 inches) of the engineering ANSI C size white medium
+    and cuts synchronizing with data.
+ 'cxsynchro-transparent': Specifies the roll paper having the width of
+    the longer edge (22 inches) of the engineering ANSI C size
+    transparent medium and cuts synchronizing with data.
+ 'cxsynchro-translucent': Specifies the roll paper having the width of
+    the longer edge (22 inches) of the engineering ANSI C size
+    translucent medium and cuts synchronizing with data.
+ 'dxsynchro-white': Specifies the roll paper having the width of the
+    longer edge (34 inches) of the engineering ANSI D size white medium
+    and cuts synchronizing with data.
+ 'dxsynchro-transparent': Specifies the roll paper having the width of
+    the longer edge (34 inches) of the engineering ANSI D size
+    transparent medium and cuts synchronizing with data.
+ 'dxsynchro-translucent': Specifies the roll paper having the width of
+    the longer edge (34 inches) of the engineering ANSI D size
+    translucent medium and cuts synchronizing with data.
+ 'exsynchro-white': Specifies the roll paper having the width of the
+    longer edge (44 inches) of the engineering ANSI E size white medium
+    and cuts synchronizing with data.
+ 'exsynchro-transparent': Specifies the roll paper having the width of
+    the longer edge (44 inches) of the engineering ANSI E size
+    transparent medium and cuts synchronizing with data.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 194]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'exsynchro-translucent': Specifies the roll paper having the width of
+    the longer edge (44 inches) of the engineering ANSI E size
+    translucent medium and cuts synchronizing with data.
+
+   The following standard values are defined for American Architectural
+   engineering media:
+
+ 'arch-a-white': Specifies the Architectural A size white medium: 9
+    inches x 12 inches
+ 'arch-a-transparent': Specifies the Architectural A size transparent
+    medium: 9 inches x 12 inches
+ 'arch-a-translucent': Specifies the Architectural A size translucent
+    medium: 9 inches x 12 inches
+ 'arch-b-white': Specifies the Architectural B size white medium: 12
+    inches x 18 inches
+ 'arch-b-transparent': Specifies the Architectural B size transparent
+    medium: 12 inches x 18 inches
+ 'arch-b-translucent': Specifies the Architectural B size translucent
+    medium: 12 inches x 18 inches
+ 'arch-c-white': Specifies the Architectural C size white medium: 18
+    inches x 24 inches
+ 'arch-c-transparent': Specifies the Architectural C size transparent
+    medium: 18 inches x 24 inches
+ 'arch-c-translucent': Specifies the Architectural C size translucent
+    medium: 18 inches x 24 inches
+ 'arch-d-white': Specifies the Architectural D size white medium: 24
+    inches x 36 inches
+ 'arch-d-transparent': Specifies the Architectural D size transparent
+    medium: 24 inches x 36 inches
+ 'arch-d-translucent': Specifies the Architectural D size translucent
+    medium: 24 inches x 36 inches
+ 'arch-e-white': Specifies the Architectural E size white medium: 36
+    inches x 48 inches
+ 'arch-e-transparent': Specifies the Architectural E size transparent
+    medium: 36 inches x 48 inches
+ 'arch-e-translucent': Specifies the Architectural E size translucent
+    medium: 36 inches x 48 inches
+
+   The following standard values are defined for American Architectural
+   engineering media for devices that provide the "synchro-cut" feature
+   (see section 14.1):
+
+ 'arch-axsynchro-white': Specifies the roll paper having the width of
+    the longer edge (12 inches) of the Architectural A size white
+    medium and cuts synchronizing with data.
+ 'arch-axsynchro-transparent': Specifies the roll paper having the
+    width of the longer edge (12 inches) of the Architectural A size
+    transparent medium and cuts synchronizing with data.
+
+
+
+Hastings, et al.            Standards Track                   [Page 195]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'arch-axsynchro-translucent': Specifies the roll paper having the
+    width of the longer edge (12 inches) of the Architectural A size
+    translucent medium and cuts synchronizing with data.
+ 'arch-bxsynchro-white': Specifies the roll paper having the width of
+    the longer edge (18 inches) of the Architectural B size white
+    medium and cuts synchronizing with data.
+ 'arch-bxsynchro-transparent': Specifies the roll paper having the
+    width of the longer edge (18 inches) of the Architectural B size
+    transparent medium and cuts synchronizing with data.
+ 'arch-bxsynchro-translucent': Specifies the roll paper having the
+    width of the longer edge (18 inches) of the Architectural B size
+    translucent medium and cuts synchronizing with data.
+ 'arch-cxsynchro-white': Specifies the roll paper having the width of
+    the longer edge (24 inches) of the Architectural C size white
+    medium and cuts synchronizing with data.
+ 'arch-cxsynchro-transparent': Specifies the roll paper having the
+    width of the longer edge (24 inches) of the Architectural C size
+    transparent medium and cuts synchronizing with data.
+ 'arch-cxsynchro-translucent': Specifies the roll paper having the
+    width of the longer edge (24 inches) of the Architectural C size
+    translucent medium and cuts synchronizing with data.
+ 'arch-dxsynchro-white': Specifies the roll paper having the width of
+    the longer edge (36 inches) of the Architectural D size white
+    medium and cuts synchronizing with data.
+ 'arch-dxsynchro-transparent': Specifies the roll paper having the
+    width of the longer edge (36 inches) of the Architectural D size
+    transparent medium and cuts synchronizing with data.
+ 'arch-dxsynchro-translucent': Specifies the roll paper having the
+    width of the longer edge (36 inches) of the Architectural D size
+    translucent medium and cuts synchronizing with data.
+ 'arch-exsynchro-white': Specifies the roll paper having the width of
+    the longer edge (48 inches) of the Architectural E size white
+    medium and cuts synchronizing with data.
+ 'arch-exsynchro-transparent': Specifies the roll paper having the
+    width of the longer edge (48 inches) of the Architectural E size
+    transparent medium and cuts synchronizing with data.
+ 'arch-exsynchro-translucent': Specifies the roll paper having the
+    width of the longer edge (48 inches) of the Architectural E size
+    translucent medium and cuts synchronizing with data.
+
+   The following standard values are defined for Japanese and European
+   Standard (i.e. ISO) engineering media, which are of a long fixed size
+   [ASME-Y14.1M]:
+
+ 'iso-a1x3-white': Specifies the ISO A1X3 white medium having the
+      width of the longer edge (841 mm) of the ISO A1 medium
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 196]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'iso-a1x3-transparent': Specifies the ISO A1X3 transparent medium
+      having the width of the longer edge (841 mm) of the ISO A1
+      medium
+ 'iso-a1x3-translucent': Specifies the ISO A1X3 translucent medium
+      having the width of the longer edge (841 mm) of the ISO A1
+      medium
+ 'iso-a1x4-white': Specifies the ISO A1X4 white medium having the
+      width of the longer edge (841 mm) of the ISO A1 medium
+ 'iso-a1x4-transparent': Specifies the ISO A1X4 transparent medium
+      having the width of the longer edge (841 mm) of the ISO A1
+      medium
+ 'iso-a1x4- translucent': Specifies the ISO A1X4 translucent medium
+      having the width of the longer edge (841 mm) of the ISO A1
+      medium
+ 'iso-a2x3-white': Specifies the ISO A2X3 white medium having the
+      width of the longer edge (594 mm) of the ISO A2 medium
+ 'iso-a2x3-transparent': Specifies the ISO A2X3 transparent medium
+      having the width of the longer edge (594 mm) of the ISO A2
+      medium
+ 'iso-a2x3-translucent': Specifies the ISO A2X3 translucent medium
+      having the width of the longer edge (594 mm) of the ISO A2
+      medium
+ 'iso-a2x4-white': Specifies the ISO A2X4 white medium having the
+      width of the longer edge (594 mm) of the ISO A2 medium
+ 'iso-a2x4-transparent': Specifies the ISO A2X4 transparent medium
+      having the width of the longer edge (594 mm) of the ISO A2
+      medium
+ 'iso-a2x4-translucent': Specifies the ISO A2X4 translucent medium
+      having the width of the longer edge (594 mm) of the ISO A2
+      medium
+ 'iso-a2x5-white': Specifies the ISO A2X5 white medium having the
+      width of the longer edge (594 mm) of the ISO A2 medium
+ 'iso-a2x5-transparent': Specifies the ISO A2X5 transparent medium
+      having the width of the longer edge (594 mm) of the ISO A2
+      medium
+ 'iso-a2x5-translucent': Specifies the ISO A2X5 translucent medium
+      having the width of the longer edge (594 mm) of the ISO A2
+      medium
+ 'iso-a3x3-white': Specifies the ISO A3X3 white medium having the
+      width of the longer edge (420 mm) of the ISO A3 medium
+ 'iso-a3x3-transparent': Specifies the ISO A3X3 transparent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x3-translucent': Specifies the ISO A3X3 translucent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x4-white': Specifies the ISO A3X4 white medium having the
+      width of the longer edge (420 mm) of the ISO A3 medium
+
+
+
+Hastings, et al.            Standards Track                   [Page 197]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'iso-a3x4-transparent': Specifies the ISO A3X4 transparent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x4-translucent': Specifies the ISO A3X4 translucent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x5-white': Specifies the ISO A3X5 white medium having the
+      width of the longer edge (420 mm) of the ISO A3 medium
+ 'iso-a3x5-transparent': Specifies the ISO A3X5 transparent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x5-translucent': Specifies the ISO A3X5 translucent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x6-white': Specifies the ISO A3X6 white medium having the
+      width of the longer edge (420 mm) of the ISO A3 medium
+ 'iso-a3x6-transparent': Specifies the ISO A3X6 transparent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x6-translucent': Specifies the ISO A3X6 translucent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x7-white': Specifies the ISO A3X7 white medium having the
+      width of the longer edge (420 mm) of the ISO A3 medium
+ 'iso-a3x7-transparent': Specifies the ISO A3X7 transparent medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a3x7-translucent'': Specifies the ISO A3X7 translucent' medium
+      having the width of the longer edge (420 mm) of the ISO A3
+      medium
+ 'iso-a4x3-white': Specifies the ISO A4X3 white medium having the
+      width of the longer edge (297 mm) of the ISO A4 medium
+ 'iso-a4x3-transparent': Specifies the ISO A4X3 transparent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x3-translucent'': Specifies the ISO A4X3 translucent' medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x4-white': Specifies the ISO A4X4 white medium having the
+      width of the longer edge (297 mm) of the ISO A4 medium
+ 'iso-a4x4-transparent': Specifies the ISO A4X4 transparent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x4-translucent': Specifies the ISO A4X4 translucent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x5-white': Specifies the ISO A4X5 white medium having the
+      width of the longer edge (297 mm) of the ISO A4 medium
+
+
+
+Hastings, et al.            Standards Track                   [Page 198]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'iso-a4x5-transparent': Specifies the ISO A4X5 transparent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x5-translucent': Specifies the ISO A4X5 translucent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x6-white': Specifies the ISO A4X6 white medium having the
+      width of the longer edge (297 mm) of the ISO A4 medium
+ 'iso-a4x6-transparent': Specifies the ISO A4X6 transparent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x6-translucent': Specifies the ISO A4X6 translucent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x7-white': Specifies the ISO A4X7 white medium having the
+      width of the longer edge (297 mm) of the ISO A4 medium
+ 'iso-a4x7-transparent': Specifies the ISO A4X7 transparent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x7-translucent': Specifies the ISO A4X7 translucent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x8-white': Specifies the ISO A4X8 white medium having the
+      width of the longer edge (297 mm) of the ISO A4 medium
+ 'iso-a4x8-transparent': Specifies the ISO A4X8 transparent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x8-translucent': Specifies the ISO A4X8 translucent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x9-white': Specifies the ISO A4X9 white medium having the
+      width of the longer edge (297 mm) of the ISO A4 medium
+ 'iso-a4x9-transparent': Specifies the ISO A4X9 transparent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+ 'iso-a4x9-translucent': Specifies the ISO A4X9 translucent medium
+      having the width of the longer edge (297 mm) of the ISO A4
+      medium
+
+   The following standard values are defined for Japanese and European
+   Standard (i.e. ISO) engineering media, which are either a long fixed
+   size [ASME-Y14.1M] or roll feed, for devices that provide the
+   "synchro-cut" feature (see section 14.1):
+
+ 'iso-a0xsynchro-white': Specifies the paper having the width of the
+      longer edge (1189 mm) of the ISO A0 white medium and cuts
+      synchronizing with data.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 199]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'iso-a0xsynchro-transparent': Specifies the paper having the width of
+      the longer edge (1189 mm) of the ISO A0 transparent medium and
+      cuts synchronizing with data.
+ 'iso-a0xsynchro-translucent': Specifies the paper having the width of
+      the longer edge (1189 mm) of the ISO A0 translucent medium and
+      cuts synchronizing with data.
+ 'iso-a1xsynchro-white': Specifies the paper having the width of the
+      longer edge (841 mm) of the ISO A1 white medium and cuts
+      synchronizing with data.
+ 'iso-a1xsynchro-transparent': Specifies the paper having the width of
+      the longer edge (841 mm) of the ISO A1 transparent medium and
+      cuts synchronizing with data.
+ 'iso-a1xsynchro-translucent': Specifies the paper having the width of
+      the longer edge (841 mm) of the ISO A1 translucent medium and
+      cuts synchronizing with data.
+ 'iso-a2xsynchro-white': Specifies the paper having the width of the
+      longer edge (594 mm) of the ISO A2 white medium and cuts
+      synchronizing with data.
+ 'iso-a2xsynchro-transparent': Specifies the paper having the width of
+      the longer edge (594 mm) of the ISO A2 transparent medium and
+      cuts synchronizing with data.
+ 'iso-a2xsynchro-translucent': Specifies the paper having the width of
+      the longer edge (594 mm) of the ISO A2 translucent medium and
+      cuts synchronizing with data.
+ 'iso-a3xsynchro-white': Specifies the paper having the width of the
+      longer edge (420 mm) of the ISO A3 white medium and cuts
+      synchronizing with data.
+ 'iso-a3xsynchro-transparent': Specifies the paper having the width of
+      the longer edge (420 mm) of the ISO A3 transparent medium and
+      cuts synchronizing with data.
+ 'iso-a3xsynchro-translucent': Specifies the paper having the width of
+      the longer edge (420 mm) of the ISO A3 translucent medium and
+      cuts synchronizing with data.
+ 'iso-a4xsynchro-white': Specifies the paper having the width of the
+      longer edge (297 mm) of the ISO A4 white medium and cuts
+      synchronizing with data.
+ 'iso-a4xsynchro-transparent': Specifies the paper having the width of
+      the longer edge (297 mm) of the ISO A4 transparent medium and
+      cuts synchronizing with data.
+ 'iso-a4xsynchro-translucent': Specifies the paper having the width of
+      the longer edge (297 mm) of the ISO A4 transparent medium and
+      cuts synchronizing with data.
+
+   The following standard values are defined for American Standard (i.e.
+   ANSI) engineering media, American Architectural engineering media,
+   and Japanese and European Standard (i.e. ISO) engineering media,
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 200]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   which are either a long fixed size [ASME-Y14.1M] or roll feed, for
+   devices that provide the "synchro-cut" feature and/or the "auto-
+   select" feature (see section 14.1):
+
+ 'auto-white': Specifies that the printer selects the white medium
+      with the appropriate fixed size (e.g. a1, a2, etc.) or data-
+      synchro size, and the selection is implementation-defined.
+ 'auto-transparent': Specifies that the printer selects the
+      transparent medium with the appropriate fixed size (e.g. a1, a2,
+      etc.) or data-synchro size, and the selection is implementation-
+      defined.
+ 'auto-translucent': Specifies that the printer selects the
+      translucent medium with the appropriate fixed size (e.g. a1, a2,
+      etc.) or data-synchro size, and the selection is implementation-
+      defined.
+ 'auto-fixed-size-white': Specifies that the printer selects the white
+      medium with the appropriate fixed size (e.g. a1, a2, etc.) or
+      the appropriate long fixed size listed above.
+ 'auto-fixed-size-transparent': Specifies that the printer selects the
+      transparent medium with the appropriate fixed size (e.g. a1, a2,
+      etc.) or the appropriate long fixed size listed above.
+ 'auto-fixed-size-translucent': Specifies that the printer selects the
+      translucent medium with the appropriate fixed size (e.g. a1, a2,
+      etc.) or the appropriate long fixed size listed above.
+ 'auto-synchro-white': Specifies that the printer selects the white
+      paper with the appropriate width and cuts it synchronizing with
+      data.
+ 'auto-synchro-transparent': Specifies that the printer selects the
+      transparent paper with the appropriate width and cuts it
+      synchronizing with data.
+ 'auto-synchro-translucent': Specifies that the printer selects the
+      translucent paper with the appropriate width and cuts it
+      synchronizing with data.
+
+   The following standard values are defined for input-trays (from ISO
+   DPA and the Printer MIB):
+
+    'top': The top input tray in the printer.
+    'middle': The middle input tray in the printer.
+    'bottom': The bottom input tray in the printer.
+    'envelope': The envelope input tray in the printer.
+    'manual': The manual feed input tray in the printer.
+    'large-capacity': The large capacity input tray in the printer.
+    'main': The main input tray
+    'side': The side input tray
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 201]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The following standard values are defined for media sizes (from ISO
+   DPA):
+
+ 'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined in
+    ISO 216
+ 'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
+    ISO 216
+ 'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
+    ISO 216
+ 'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
+    ISO 216
+ 'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
+    ISO 216
+ 'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
+    ISO 216
+ 'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
+    ISO 216
+ 'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
+    ISO 216
+ 'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in ISO
+    216
+ 'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in ISO
+    216
+ 'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
+    ISO 216
+ 'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined in
+    ISO 216
+ 'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined in
+    ISO 216
+ 'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
+    ISO 216
+ 'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
+    ISO 216
+ 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
+    ISO 216
+ 'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
+    ISO 216
+ 'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
+    ISO 216
+ 'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
+    ISO 216
+ 'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in ISO
+    216
+ 'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in ISO
+    216
+ 'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
+    ISO 216
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 202]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'na-letter': Specifies the North American letter size: 8.5 inches by
+    11 inches
+ 'na-legal': Specifies the North American legal size: 8.5 inches by 14
+    inches
+ 'na-8x10': Specifies the North American 8 inches by 10 inches
+ 'na-5x7': Specifies the North American 5 inches by 7 inches
+ 'executive': Specifies the executive size (7.25 X 10.5 in)
+ 'folio': Specifies the folio size (8.5 X 13 in)
+ 'invoice': Specifies the invoice size (5.5 X 8.5 in)
+ 'ledger': Specifies the ledger size (11 X 17 in)
+ 'quarto': Specifies the quarto size (8.5 X 10.83 in)
+ 'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
+    ISO 269
+ 'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
+    ISO 269
+ 'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
+    ISO 269
+ 'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
+    ISO 269
+ 'iso-designated-long': Specifies the ISO Designated Long size: 110 mm
+    by 220 mm as defined in ISO 269
+ 'na-10x13-envelope': Specifies the North American 10x13 size: 10
+    inches by 13 inches
+ 'na-9x12-envelope': Specifies the North American 9x12 size: 9 inches
+    by 12 inches
+ 'na-number-10-envelope': Specifies the North American number 10
+    business envelope size: 4.125 inches by 9.5 inches
+ 'na-7x9-envelope': Specifies the North American 7x9 inch envelope
+    size
+ 'na-9x11-envelope': Specifies the North American 9x11 inch envelope
+    size
+ 'na-10x14-envelope': Specifies the North American 10x14 inch envelope
+    size
+ 'na-number-9-envelope': Specifies the North American number 9
+    business envelope size
+ 'na-6x9-envelope': Specifies the North American 6x9 envelope size
+ 'na-10x15-envelope': Specifies the North American 10x15 envelope size
+ 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
+    in)
+ 'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
+ 'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
+ 'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
+ 'jis-b3': Specifies the JIS B3 size: 364mm x 515mm
+ 'jis-b4': Specifies the JIS B4 size: 257mm x 364mm
+ 'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
+ 'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
+ 'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
+ 'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
+
+
+
+Hastings, et al.            Standards Track                   [Page 203]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+ 'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
+ 'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
+
+   The following standard values are defined for American Standard (i.e.
+   ANSI) engineering media sizes:
+
+    'a': Specifies the engineering ANSI A size medium: 8.5 inches x 11
+       inches
+    'b': Specifies the engineering ANSI B size medium: 11 inches x 17
+       inches
+    'c': Specifies the engineering ANSI C size medium: 17 inches x 22
+       inches
+    'd': Specifies the engineering ANSI D size medium: 22 inches x 34
+       inches
+    'e': Specifies the engineering ANSI E size medium: 34 inches x 44
+       inches
+
+   The following standard values are defined for American Architectural
+   engineering media sizes:
+
+    'arch-a': Specifies the Architectural A size medium: 9 inches x 12
+       inches
+    'arch-b': Specifies the Architectural B size medium: 12 inches x 18
+       inches
+    'arch-c': Specifies the Architectural C size medium: 18 inches x 24
+       inches
+    'arch-d': Specifies the Architectural D size medium: 24 inches x 36
+       inches
+    'arch-e': Specifies the Architectural E size medium: 36 inches x 48
+       inches
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 204]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+14.1. Examples
+
+   Below are examples to supplement the engineering media value
+   definitions.
+
+   Example 1:  "Synchro-Cut", a device cutting the roll paper in
+   synchronization with the data
+
+     data height:          A1 height
+     data width (shaded):  A1 width < data width < (A1 width) x 2
+     specified value:      'iso-a1xsynchro-white'
+
+               |                    |
+               |<--- data width --->|
+               |                    |
+               |              |     |        |
+               |<- A1 width ->|<- A1 width ->|
+               |              |     |        |
+     cross  ^  |              |     |        |
+      feed  |  +--------------------------------------------/
+ direction  |  |//////////////|/////|        |     ^       /
+            |  |//////////////|/////|        |     |      /
+            |  |//////////////|/////|        |     |     /
+            |  |//////////////|/////|        |     |     \
+<-----------+- |//////////////|/////|        |    A1      \  roll
+feed        |  |//////////////|/////|        |   height    \  paper
+direction      |//////////////|/////|        |     |        \
+               |//////////////|/////|        |     |        /
+               |//////////////|/////|        |     v       /
+               +------------------------------------------/
+                                    |
+                                    |
+                                    |<------ CUT HERE (to synchronize
+                                    |                with data width)
+                                    |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 205]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Example 2: "Auto-Cut", a device cutting the roll paper at multiples
+   of fixed-size media width
+
+     data height:          A1 height
+     data width (shaded):  A1 width < data width < (A1 width) x 2
+     specified value:      'auto-fixed-size-white'
+
+                 |                    |
+                 |<--- data width --->|
+                 |                    |
+                 |              |     |        |
+                 |<- A1 width ->|<- A1 width ->|
+                 |              |     |        |
+     cross  ^    |              |     |        |
+      feed  |    +--------------------------------------------/
+ direction  |    |//////////////|/////|        |     ^       /
+            |    |//////////////|/////|        |     |      /
+            |    |//////////////|/////|        |     |     /
+            |    |//////////////|/////|        |     |     \
+<-----------+-   |//////////////|/////|        |    A1      \  roll
+feed        |    |//////////////|/////|        |   height    \  paper
+direction        |//////////////|/////|        |     |        \
+                 |//////////////|/////|        |     |        /
+                 |//////////////|/////|        |     v       /
+                 +------------------------------------------/
+                                               |
+                                               |
+                                               |<--- CUT HERE
+                                               |      (to synchronize
+                                               |       with data width)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 206]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Example 3:  the 'iso-a4x4-white' fixed size paper
+
+     paper height:         A4 height
+     paper width:          (A4 width) x 4
+     specified value:      'iso-a4x4-white'
+
+   |              |              |              |              |
+   |<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->|
+   |              |              |              |              |
+   |              |              |              |              |
+   +-----------------------------------------------------------+
+   |       ^      |              |              |              |
+   |       |      |              |              |              |
+   |       |      |              |              |              |
+   |      A4      |              |              |              |
+   |    height    |              |              |              |
+   |       |      |              |              |              |
+   |       |      |              |              |              |
+   |       |      |              |              |              |
+   |       v      |              |              |              |
+   +-----------------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 207]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Example 4: "Synchro-Cut", a device cutting the fixed size paper in
+   synchronization with the data
+
+     data height:          A4 height
+     data width (shaded):  (A4 width) x 2 < data width < (A4 width) x 3
+     specified value:      'iso-a4xsynchro-white'
+
+                    |                                   |
+                    |<---------- data width ----------->|
+                    |                                   |
+                    |              |              |     |        |
+                    |<- A4 width ->|<- A4 width ->|<- A4 width ->|
+                    |              |              |     |        |
+        cross  ^    |              |              |     |        |
+         feed  |    +--------------------------------------------+
+    direction  |    |//////////////|//////////////|/////|    ^   |
+               |    |//////////////|//////////////|/////|    |   |
+               |    |//////////////|//////////////|/////|    |   |
+               |    |//////////////|//////////////|/////|    |   |
+   <-----------+-   |//////////////|//////////////|/////|   A4   |
+   feed        |    |//////////////|//////////////|/////| height |
+   direction        |//////////////|//////////////|/////|    |   |
+                    |//////////////|//////////////|/////|    |   |
+                    |//////////////|//////////////|/////|    v   |
+                    +--------------------------------------------+
+                                                        |
+                                          CUT HERE ---->|
+                                    (to synchronize     |
+                                    with data width)    |
+
+15. APPENDIX D: Processing IPP Attributes
+
+   When submitting a print job to a Printer object, the IPP model allows
+   a client to supply operation and Job Template attributes along with
+   the document data.  These Job Template attributes in the create
+   request affect the rendering, production and finishing of the
+   documents in the job.  Similar types of instructions may also be
+   contained in the document to be printed, that is, embedded within the
+   print data itself.  In addition, the Printer has a set of attributes
+   that describe what rendering and finishing options which are
+   supported by that Printer.  This model, which allows for flexibility
+   and power, also introduces the potential that at job submission time,
+   these client-supplied attributes may conflict with either:
+
+      - what the implementation is capable of realizing (i.e., what the
+        Printer supports), as well as
+      - the instructions embedded within the print data itself.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 208]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The following sections describe how these two types of conflicts are
+   handled in the IPP model.
+
+15.1 Fidelity
+
+   If there is a conflict between what the client requests and what a
+   Printer object supports, the client may request one of two possible
+   conflict handling mechanisms:
+
+      1) either reject the job since the job can not be processed
+         exactly as specified, or
+      2) allow the Printer to make any changes necessary to proceed with
+         processing the Job the best it can.
+
+   In the first case the client is indicating to the Printer object:
+   "Print the job exactly as specified with no exceptions, and if that
+   can't be done, don't even bother printing the job at all." In the
+   second case, the client is indicating to the Printer object: "It is
+   more important to make sure the job is printed rather than be
+   processed exactly as specified; just make sure the job is printed
+   even if some client-supplied attributes need to be changed or
+   ignored."
+
+   The IPP model accounts for this situation by introducing an "ipp-
+   attribute-fidelity" attribute.
+
+   In a create request, "ipp-attribute-fidelity" is a boolean operation
+   attribute that is OPTIONALLY supplied by the client.  The value
+   'true' indicates that total fidelity to client supplied Job Template
+   attributes and values is required.  The client is requesting that the
+   Job be printed exactly as specified, and if that is not possible then
+   the job MUST be rejected rather than processed incorrectly.  The
+   value 'false' indicates that a reasonable attempt to print the Job is
+   acceptable.  If a Printer does not support some of the client
+   supplied Job Template attributes or values, the Printer MUST ignore
+   them or substitute any supported value for unsupported values,
+   respectively.  The Printer may choose to substitute the default value
+   associated with that attribute, or use some other supported value
+   that is similar to the unsupported requested value.  For example, if
+   a client supplies a "media" value of 'na-letter', the Printer may
+   choose to substitute 'iso-a4' rather than a default value of
+   'envelope'. If the client does not supply the "ipp-attribute-
+   fidelity" attribute, the Printer assumes a value of 'false'.
+
+   Each Printer implementation MUST support both types of "fidelity"
+   printing (that is whether the client supplies a value of 'true' or
+   'false'):
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 209]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      - If the client supplies 'false' or does not supply the attribute,
+        the Printer object MUST always accept the request by ignoring
+        unsupported Job Template attributes and by substituting
+        unsupported values of supported Job Template attributes with
+        supported values.
+      - If the client supplies 'true', the Printer object MUST reject
+        the request if the client supplies unsupported Job Template
+        attributes.
+
+   Since a client can always query a Printer to find out exactly what is
+   and is not supported, "ipp-attribute-fidelity" set to 'false' is
+   useful when:
+
+      1) The End-User uses a command line interface to request
+         attributes that might not be supported.
+      2) In a GUI context, if the End User expects the job might be
+         moved to another printer and prefers a sub-optimal result to
+         nothing at all.
+      3) The End User just wants something reasonable in lieu of nothing
+         at all.
+
+15.2 Page Description Language (PDL) Override
+
+   If there is a conflict between the value of an IPP Job Template
+   attribute and a corresponding instruction in the document data, the
+   value of the IPP attribute SHOULD take precedence over the document
+   instruction.  Consider the case where a previously formatted file of
+   document data is sent to an IPP Printer.  In this case, if the client
+   supplies any attributes at job submission time, the client desires
+   that those attributes override the embedded instructions.  Consider
+   the case were a previously formatted document has embedded in it
+   commands to load 'iso-a4' media.  However, the document is passed to
+   an end user that only has access to a printer with 'na-letter' media
+   loaded.  That end user most likely wants to submit that document to
+   an IPP Printer with the "media" Job Template attribute set to 'na-
+   letter'.  The job submission attribute should take precedence over
+   the embedded PDL instruction.  However, until companies that supply
+   document data interpreters allow a way for external IPP attributes to
+   take precedence over embedded job production instructions, a Printer
+   might not be able to support the semantics that IPP attributes
+   override the embedded instructions.
+
+   The IPP model accounts for this situation by introducing a "pdl-
+   override-supported" attribute that describes the Printer objects
+   capabilities to override instructions embedded in the PDL data
+   stream.  The value of the "pdl-override-supported" attribute is
+   configured by means outside the scope of this IPP/1.1 document.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 210]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   This REQUIRED Printer attribute takes on the following values:
+
+      - 'attempted': This value indicates that the Printer object
+        attempts to make the IPP attribute values take precedence over
+        embedded instructions in the document data, however there is no
+        guarantee.
+      - 'not-attempted': This value indicates that the Printer object
+        makes no attempt to make the IPP attribute values take
+        precedence over embedded instructions in the document data.
+
+   At job processing time, an implementation that supports the value of
+   'attempted' might do one of several different actions:
+
+      1) Generate an output device specific command sequence to realize
+         the feature represented by the IPP attribute value.
+      2) Parse the document data itself and replace the conflicting
+         embedded instruction with a new embedded instruction that
+         matches the intent of the IPP attribute value.
+      3) Indicate to the Printer that external supplied attributes take
+         precedence over embedded instructions and then pass the
+         external IPP attribute values to the document data interpreter.
+      4) Anything else that allows for the semantics that IPP attributes
+         override embedded document data instructions.
+
+   Since 'attempted' does not offer any type of guarantee, even though a
+   given Printer object might not do a very "good" job of attempting to
+   ensure that IPP attributes take a higher precedence over instructions
+   embedded in the document data, it would still be a conforming
+   implementation.
+
+   At job processing time, an implementation that supports the value of
+   'not-attempted' might do one of the following actions:
+
+      1) Simply pre-pend the document data with the PDL instruction that
+         corresponds to the client-supplied PDL attribute, such that if
+         the document data also has the same PDL instruction, it will
+         override what the Printer object pre-pended.  In other words,
+         this implementation is using the same implementation semantics
+         for the client-supplied IPP attributes as for the Printer
+         object defaults.
+
+      2) Parse the document data and replace the conflicting embedded
+         instruction with a new embedded instruction that approximates,
+         but does not match, the semantic intent of the IPP attribute
+         value.
+
+   Note:  The "ipp-attribute-fidelity" attribute applies to the
+   Printer's ability to either accept or reject other unsupported Job
+
+
+
+Hastings, et al.            Standards Track                   [Page 211]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   Template attributes.  In other words, if "ipp-attribute-fidelity" is
+   set to 'true', a Job is accepted if and only if the client supplied
+   Job Template attributes and values are supported by the Printer.
+   Whether these attributes actually affect the processing of the Job
+   when the document data contains embedded instructions depends on the
+   ability of the Printer to override the instructions embedded in the
+   document data with the semantics of the IPP attributes.  If the
+   document data attributes can be overridden ("pdl-override-supported"
+   set to 'attempted'), the Printer makes an attempt to use the IPP
+   attributes when processing the Job. If the document data attributes
+   can not be overridden ("pdl-override-supported" set to 'not-
+   attempted'), the Printer makes no attempt to override the embedded
+   document data instructions with the IPP attributes when processing
+   the Job, and hence, the IPP attributes may fail to affect the Job
+   processing and output when the corresponding instruction is embedded
+   in the document data.
+
+15.3 Using Job Template Attributes During Document Processing.
+
+   The Printer object uses some of the Job object's Job Template
+   attributes during the processing of the document data associated with
+   that job.  These include, but are not limited to, "orientation-
+   requested", "number-up", "sides", "media", and "copies".  The
+   processing of each document in a Job Object MUST follow the steps
+   below. These steps are intended only to identify when and how
+   attributes are to be used in processing document data and any
+   alternative steps that accomplishes the same effect can be used to
+   implement this specification document.
+
+      1. Using the client supplied "document-format" attribute or some
+         form of document format detection algorithm (if the value of
+         "document-format" is not specific enough), determine whether or
+         not the document data has already been formatted for printing.
+         If the document data has been formatted, then go to step 2.
+         Otherwise, the document data MUST be formatted. The formatting
+         detection algorithm is implementation defined and is not
+         specified by this document.  The formatting of the document
+         data uses the "orientation-requested" attribute to determine
+         how the formatted print data should be placed on a print-stream
+         page, see section 4.2.10 for the details.
+
+      2. The document data is in the form of a print-stream in a known
+         media type. The "page-ranges" attribute is used to select, as
+         specified in section 4.2.7, a sub-sequence of the pages in the
+         print-stream that are to be processed and images.
+
+      3. The input to this step is a sequence of print-stream pages.
+         This step is controlled by the "number-up" attribute. If the
+
+
+
+Hastings, et al.            Standards Track                   [Page 212]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+         value of "number-up" is N, then during the processing of the
+         print-stream pages, each N print-stream pages are positioned,
+         as specified in section 4.2.9, to create a single impression.
+         If a given document does not have N more print-stream pages,
+         then the completion of the impression is controlled by the
+         "multiple-document-handling" attribute as described in section
+         4.2.4; when the value of this attribute is 'single-document' or
+         'single-document-new-sheet', the print-stream pages of document
+         data from subsequent documents is used to complete the
+         impression.
+
+         The size(scaling), position(translation) and rotation of the
+         print-stream pages on the impression is implementation defined.
+         Note that during this process the print-stream pages may be
+         rendered to a form suitable for placing on the impression; this
+         rendering is controlled by the values of the "printer-
+         resolution" and "print-quality" attributes as described in
+         sections 4.2.12 and 4.2.13. In the case N=1, the impression is
+         nearly the same as the print-stream page; the differences would
+         only be in the size, position and rotation of the print-stream
+         page and/or any decoration, such as a frame to the page, that
+         is added by the implementation.
+
+      4. The collection of impressions is placed, in sequence, onto
+         sides of the media sheets. This placement is controlled by the
+         "sides" attribute and the orientation of the print-stream page,
+         as described in section 4.2.8. The orientation of the print-
+         stream pages affects the orientation of the impression; for
+         example, if "number-up" equals 2, then, typically, two portrait
+         print-stream pages become one landscape impression. Note that
+         the placement of impressions onto media sheets is also
+         controlled by the "multiple-document-handling" attribute as
+         described in section 4.2.4.
+
+      5. The "copies" and "multiple-document-handling" attributes are
+         used to determine how many copies of each media instance are
+         created and in what order. See sections 4.2.5 and 4.2.4 for the
+         details.
+
+      6. When the correct number of copies are created, the media
+         instances are finished according to the values of the
+         "finishings" attribute as described in 4.2.6. Note that
+         sometimes finishing operations may require manual intervention
+         to perform the finishing operations on the copies, especially
+         uncollated copies. This document allows any or all of the
+         processing steps to be performed automatically or manually at
+         the discretion of the Printer object.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 213]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+16. APPENDIX E: Generic Directory Schema
+
+   This section defines a generic schema for an entry in a directory
+   service.  A directory service is a means by which service users can
+   locate service providers.  In IPP environments, this means that IPP
+   Printers can be registered (either automatically or with the help of
+   an administrator) as entries of type printer in the directory using
+   an implementation specific mechanism such as entry attributes, entry
+   type fields, specific branches, etc.  Directory clients can search or
+   browse for entries of type printer.  Clients use the directory
+   service to find entries based on naming, organizational contexts, or
+   filtered searches on attribute values of entries.  For example, a
+   client can find all printers in the "Local Department" context.
+   Authentication and authorization are also often part of a directory
+   service so that an administrator can place limits on end users so
+   that they are only allowed to find entries to which they have certain
+   access rights.  IPP itself does not require any specific directory
+   service protocol or provider.
+
+   Note: Some directory implementations allow for the notion of
+   "aliasing".  That is, one directory entry object can appear as
+   multiple directory entry object with different names for each object.
+   In each case, each alias refers to the same directory entry object
+   which refers to a single IPP Printer object.
+
+   The generic schema is a subset of IPP Printer Job Template and
+   Printer Description attributes (sections 4.2 and 4.4).  These
+   attributes are identified as either RECOMMENDED or OPTIONAL for the
+   directory entry itself.  This conformance labeling is NOT the same
+   conformance labeling applied to the attributes of IPP Printers
+   objects.  The conformance labeling in this Appendix is intended to
+   apply to directory templates and to IPP Printer implementations that
+   subscribe by adding one or more entries to a directory.  RECOMMENDED
+   attributes SHOULD be associated with each directory entry.  OPTIONAL
+   attributes MAY be associated with the directory entry (if known or
+   supported).  In addition, all directory entry attributes SHOULD
+   reflect the current attribute values for the corresponding Printer
+   object.
+
+   The names of attributes in directory schema and entries SHOULD be the
+   same as the IPP Printer attribute names as shown, as much as
+   possible.
+
+   In order to bridge between the directory service and the IPP Printer
+   object, one of the RECOMMENDED directory entry attributes is the
+   Printer object's "printer-uri-supported" attribute.  The directory
+   client queries the "printer-uri-supported" attribute (or its
+   equivalent) in the directory entry and then the IPP client addresses
+
+
+
+Hastings, et al.            Standards Track                   [Page 214]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   the IPP Printer object using one of its URIs.  The "uri-security-
+   supported" attribute identifies the protocol (if any) used to secure
+   a channel.
+
+   The following attributes define the generic schema for directory
+   entries of type PRINTER:
+
+     printer-uri-supported              RECOMMENDED    Section 4.4.1
+     uri-authentication-supported       RECOMMENDED    Section 4.4.2
+     uri-security-supported             RECOMMENDED    Section 4.4.3
+     printer-name                       RECOMMENDED    Section 4.4.4
+     printer-location                   RECOMMENDED    Section 4.4.5
+     printer-info                       OPTIONAL       Section 4.4.6
+     printer-more-info                  OPTIONAL       Section 4.4.7
+     printer-make-and-model             RECOMMENDED    Section 4.4.9
+     ipp-versions-supported             RECOMMENDED    Section 4.4.14
+     multiple-document-jobs-supported   OPTIONAL       Section 4.4.16
+     charset-supported                  OPTIONAL       Section 4.4.18
+
+     generated-natural-language-
+        supported                       OPTIONAL       Section 4.4.20
+     document-format-supported          RECOMMENDED    Section 4.4.22
+     color-supported                    RECOMMENDED    Section 4.4.26
+     compression-supported              RECOMMENDED    Section 4.4.32
+     pages-per-minute                   OPTIONAL       Section 4.4.36
+     pages-per-minute-color             OPTIONAL       Section 4.4.37
+
+     finishings-supported               OPTIONAL       Section 4.2.6
+     number-up-supported                OPTIONAL       Section 4.2.7
+     sides-supported                    RECOMMENDED    Section 4.2.8
+     media-supported                    RECOMMENDED    Section 4.2.11
+     printer-resolution-supported       OPTIONAL       Section 4.2.12
+     print-quality-supported            OPTIONAL       Section 4.2.13
+
+17. APPENDIX F:  Differences between the IPP/1.0 and IPP/1.1 "Model and
+    Semantics" Documents
+
+   This Appendix is divided into two lists that summarize the
+   differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566].
+   The section numbers refer to the numbers in this document which in
+   some cases have changed from RFC 2566.  When a change affects
+   multiple sections, the item is listed once in the order of the first
+   section affected and the remaining affected section numbers are
+   indicated.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 215]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+   The first list contains extensions and clarifications and the second
+   list contains changes in semantics or conformance.  However, client
+   and IPP object implementations of IPP/1.0 MAY implement any of the
+   extensions and clarifications in this document.
+
+   The following extensions and clarifications have been incorporated
+   into this document:
+
+      1.  Section 2.1 - clarified that the term "client" can be either
+          contained in software controlled by an end user or a part of a
+          print server that controls devices.
+      2.  Section 2 - clarified that the term "IPP object" and "Printer
+          object" can either be embedded in a device object or part of a
+          print server that accepts IPP requests.
+      3.  Section 2.4 - added the description of the new "uri-
+          authentication-supported" Printer Description attribute.
+      4.  Section 3.1.3, 3.1.6, 3.2.5.2, and 3.2.6.2 - clarified the
+          error handling for operation attributes that have their own
+          status code.
+      5.  Section 3.1.3 - clarified that multiple occurrences of the
+          same attribute in an attribute group is mal-formed.  An IPP
+          Printer MAY reject the request or choose one of the
+          attributes.
+      6.  Section 3.1.6 - reorganized this section into sub-sections to
+          separately describe "status-code", "status-message",
+          "detailed-status-message", and "document-access-error"
+          attributes.
+      7.  Section 3.1.6.1 - clarified the error status codes and their
+          relationship to operation attributes.
+      8.  Section 3.1.6.3 - Added the OPTIONAL "detailed-status-message
+          (text(MAX))" operation attribute to provide additional more
+          detailed information about a response.
+      9.  Section 3.1.6.4 and 3.2.2 - Added the OPTIONAL "document-
+          access-error (text(MAX))" operation attribute for use with
+          Print-URI and Send-URI responses.
+      10. Sections 3.1.7 - Added this new section to clarify returning
+          Unsupported Attributes for all operations, including only
+          returning attributes that were in the request.  Moved the text
+          from section 3.2.1.2 Unsupported Attributes to this section.
+      11. Sections 3.1.7 and 4.1 - clarified the encoding of the "out-
+          of-band" 'unsupported' and 'unknown' values.
+      12. Section 3.1.8 - clarified that only the version number
+          parameter will be carried forward into future major or minor
+          versions of the protocol.
+      13. Section 3.1.8 - relaxed the requirements to increment the
+          major version number in future versions of the Model and
+          Semantics document.
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 216]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      14. Section 3.1.9, and 3.2.5 - added the 'processing' state to the
+          list of job states that a job can be in after a Create-Job
+          operation.
+      15. Section 3.1.9 - clarified that a non-spooling Printer MAY
+          accept zero or more subsequent jobs while processing a job and
+          flow control them down.  Subsequent create requests are
+          rejected with the 'server-error-busy' error status.
+      16. Section 3.2.1.1 - clarified the validation of the
+          "compression" operation attribute and its relationship to the
+          validation of the "document-format" attribute and returning
+          Unsupported Attributes.
+      17. Sections 3.2.1.1, 4.3.8, 13.1.4.16, and 13.1.4.17 - added the
+          'client-error-compression-not-supported', 'client-error-
+          compression-error' status codes and the 'unsupported-
+          compression' and 'compression-error' job-state-reasons.
+      18. Sections 3.2.1.1 and 4.3.8 - added 'unsupported-document-
+          format' and 'document-format-error' job-state-reasons.
+      19. Sections 3.2.2, 4.3.8 and 13.1.4.19 - added 'client-error-
+          document-access-error' status code and 'document-access-error'
+          job state reason.
+      20. Section 3.2.5.2 and 3.2.6.2 - clarified that the Unsupported
+          Attributes group MUST NOT include attributes not requested in
+          the Get-Printer-Attributes request.
+      21. Section 3.2.6 - clarified that "limit" takes precedence over
+          "which-jobs" and "my-jobs'.
+      22. Section 3.2.6.2 - clarified that Get-Jobs returns
+          'successful-ok' when no jobs to return.
+      23. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause-
+          Printer, Resume-Printer, and Purge-Jobs operations
+      24. Section 3.3.1  - clarified that the authorization required for
+          a Send-Document request MUST be the same user as the Create-
+          Job or an operator.
+      25. Section 3.3.1.1 - clarified that a Create-Job Send-Document
+          with "last-document" = 'true' and no data is not an error; its
+          a job with no documents.
+      26. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold-
+          Job, Release-Job, and Restart-Job operations.  Clarified the
+          Restart-Job operation so that the Printer MUST re-fetch any
+          documents passed by-reference (Print-URI or Send-URI).
+      27. Section 4.1 - clarified that the encoding of the out-of-band
+          values are specified in the Encoding and Transport" document.
+      28. Section 4.1 - Clarified that the requirement that clients MUST
+          NOT send "out-of-band" values in requests applies only to
+          operations defined in this document.  Other operations are
+          allowed to define "out-of-band" values that clients can
+          supply.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 217]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      29. Sections 4.1.1 and 4.1.2 - clarified that the maximum 'text'
+          and 'name' values of 1023 and 255 are for the
+          'textWithoutLanguage' portion of the 'textWithLanguage' form,
+          so that the maximum number of octets for the actual text and
+          name data is the same for the without and with language forms;
+          the 'naturalLanguage' part is in addition.
+      30. Section 4.1.9 - clarified that 'mimeMediaType' values can
+          include any parameters from the IANA Registry, not just
+          charset parameters.
+      31. Section 4.1.9.1 - clarified that 'application/octet-stream'
+          auto-sensing can happen at create request time and/or
+          job/document processing time.
+      32. Section 4.1.9.1 - clarified that auto-sensing involves the
+          Printer examining some number of octets of document data using
+          an implementation-dependent method.
+      33. Section 4.1.14 - clarified that the localization of dateTime
+          by the client includes the time zone.
+      34. Section 4.2 - clarified that xxx-supported have multiple
+          keywords and/or names by adding parentheses to the table to
+          give:  (1setOf (type3 keyword | name))
+      35. Section 4.2.2 - added the 'indefinite' keyword value to the
+          "job-hold-until" attribute for use with the create operations
+          and Hold-Job and Restart-Job operations.
+      36. Section 4.2.6 - added more enum values to the "finishings" Job
+          Template attribute.
+      37. Section 4.2.6 - clarified that the landscape definition is a
+          rotation of the image with respect to the medium.
+      38. Section 4.3.7 - added that a forwarding server that cannot get
+          any job state MAY return the job's state as 'completed',
+          provided that it also return the new 'queued-in-device' job
+          state reason.
+      39. Section 4.3.7.2 - added the Partitioning of Job States section
+          to clarify the concepts of Job Retention, Job History, and Job
+          Removal.
+      40. Section 4.3.8 - added 'job-data-insufficient' job state reason
+          to indicate whether sufficient data has arrived for the
+          document to start to be processed.
+      41. Section 4.3.8 - added 'document-access-error' job state reason
+          to indicate an access error of any kind.
+      42. Section 4.3.8 - added 'job-queued-for-marker' job state reason
+          to indicate whether the job has completed some processing and
+          is waiting for the marker.
+      43. Section 4.3.8 - added 'unsupported-compression' and
+          'compression-error' job state reasons to indicate compression
+          not supported or compression processing error after the create
+          has been accepted.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 218]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      44. Section 4.3.8 - added 'unsupported-document-format' and
+          'document-format-error' job state reasons to indicate document
+          not supported or document format processing error after the
+          create has been accepted.
+      45. Section 4.3.8 - added 'queued-in-device' job state reason to
+          indicate that a job as been forwarded to a print system or
+          device that does not provide any job status.
+      46. Section 4.3.10 - added "job-detailed-status-messages (1setOf
+          text(MAX)) for returning detailed error messages.
+      47. Section 4.3.11 - added the "job-document-access-errors (1setOf
+          text(MAX))
+      48. Section 4.3.14.2 - clarified that the time recorded is the
+          first time processing since the create operation or the
+          Restart-Job operation.
+      49. Section 4.3.14.2 and 4.3.14.3 - clarified that the out-of-band
+          value 'no-value' is returned if the job has not started
+          processing or has not completed, respectively.
+      50. Section 4.3.14 - Added the OPTIONAL "date-time-at-creation",
+          "date-time-at-processing", and "date-time-at-completed" Event
+          Time Job Description attributes
+      51. Section 4.4.3 - added the 'tls' value to "uri-security-
+          supported" attribute.
+      52. Section 4.4.3 - clarified "uri-security-supported" is
+          orthogonal to Client Authentication so that 'none' does not
+          exclude Client Authentication.
+      53. Section 4.4.11 - simplified the "printer-state" descriptions
+          while generalizing to allow high end devices that interpret
+          one or more jobs while marking another.  Indicated that
+          'spool-area-full' and 'stopped-partly' "printer-state-reasons"
+          may be used to provide further state information.
+      54. Section 4.4.12 - added the 'moving-to-paused' keyword value to
+          the "printer-state-reasons" attribute for use with the Pause-
+          Printer operation.
+      55. Section 4.4.12 - replaced the duplicate 'marker-supply-low'
+          keyword with the missing 'toner-empty' keyword for the
+          "printer-state-reasons" attribute.  (This correction was also
+          made before RFC 2566 was published).
+      56. Section 4.4.12 - clarified 'spool-area-full' "printer-state-
+          reasons" to include non-spooling printers to indicate when it
+          can and cannot accept another job.
+      57. Section 4.4.15 - added the enum values to the "operations-
+          supported" attribute for the new operations.  Clarified that
+          the values of this attribute are encoded as any enum, namely
+          32-bit values.
+      58. Section 4.4.30 - clarified that the dateTime value of
+          "printer-current-time" is on a "best efforts basis".  If a
+          proper date-time cannot be obtained, the implementation
+          returns the 'no-value' out-of-band value.  Also clarified that
+
+
+
+Hastings, et al.            Standards Track                   [Page 219]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+          the time zone NEED NOT be the time zone that the people near
+          the device use and that the client SHOULD display the dateTime
+          attributes in the user's local time.
+      59. Sections 4.4.36 and 4.4.37 - added the OPTIONAL "pages-per-
+          minute" and "pages-per-minute-color" Printer Description
+          attributes.
+      60. Section 5.1 - clarified that the client conformance
+          requirements apply to clients controlled by an end user and
+          clients in servers.
+      61. Section 5.1 - clarified that any response MAY contain
+          additional attribute groups, attributes, attribute syntaxes,
+          or attribute values.
+      62. Section 5.1 - clarified that a client SHOULD do its best to
+          prevent a channel from being closed by a lower layer when the
+          channel is flow controlled off by the IPP Printer.
+      63. Section 5.2 - clarified that the IPP object requirements apply
+          to objects embedded in devices or that are parts of servers.
+      64. Section 5.2.2 - clarified that IPP objects MAY return
+          operation responses that contain attribute groups, attribute
+          names, attribute syntaxes, attribute values, and status codes
+          that are extensions to this standard.
+      65. Section 6 - changed the terminology of "private extensions" to
+          "vendor extensions" and indicated that they are registered
+          with IANA along with IETF standards track extensions.
+      66. Section 6.7 - inserted this section on registering out-of-band
+          attribute values with IANA as extensions.
+      67. Section 8.3 - clarified the use of URIs for each Client
+          Authentication mechanism.
+      68. Section 8.5 - added the security discussion around the new
+          operator/administrator operations.
+      69. Section 13.1.4.16 - added client-error-compression-not-
+          supported (0x040F)
+      70. Section 13.1.4.17 - added client-error-compression-error
+          (0x0410)
+      71. Section 13.1.4.18 - added client-error-document-format-error
+          (0x0411)
+      72. Section 13.1.4.19 - added client-error-document-access-error
+          (0x0412)
+      73. Section 13.1.5.10 - added server-error-multiple-document-
+          jobs-not-supported (0x0509)
+      74. Section 14 - added 'a-white', 'b-white', 'c-white', 'd-white',
+          and 'e-white' and clarified that the existing 'a', 'b', 'c',
+          'd', and 'e' values are size values.  Added American,
+          Japanese, and European Engineering sizes, filled out
+          -transparent and - translucent media names and drawings for
+          the synchro cut sizes.
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 220]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      75. Section 16 - softened the RECOMMENDATION for IPP Printer
+          attributes in a Directory schema so that they can have
+          equivalents.
+      76. Section 16 - added the OPTIONAL "pages-per-minute" and
+          "pages-per-minute-color" Printer attributes to the Directory
+          schema.
+      77. Section 16 - added OPTIONAL "multiple-document-jobs-supported"
+          to the Directory schema.
+      78. Section 16 - added RECOMMENDED "uri-authentication-supported",
+          "ipp-versions-supported", and "compression-supported" to the
+          Directory schema.
+
+   The following changes in semantics and/or conformance have been
+   incorporated into this document:
+
+      1.  Section 3.1.6.3 - allowed a Printer to localize the
+          "detailed-status-message" operation response attribute, but
+          indicated that such localization might obscure the technical
+          meaning of such messages.
+      2.  Section 3.1.8, 5.2.4, and 13.1.5.4 - Clients and IPP objects
+          MUST support version 1.1 conformance requirements.   It is
+          recommended that they interoperate with 1.0.  Also clarified
+          that IPP Printers MUST accept '1.1' requests.   It is
+          recommended that they also accept '1.x' requests.
+
+      3.  Section 3.2.1.1 and section 4.4.32 - changed the "compression"
+          operation and the "compression-supported" Printer Description
+          attribute from OPTIONAL to REQUIRED.
+      4.  Sections 3.2.1.2 and 4.3.8 - changed "job-state-reasons" from
+          RECOMMENDED to REQUIRED, so that "job-state-reasons" MUST be
+          returned in create operation responses.
+      5.  Sections 3.2.4, 3.3.1, 4.4.16, and 16 - changed Create-
+          Job/Send-Document so that they MAY be implemented while only
+          supporting one document jobs.  Added the "multiple-document-
+          jobs-supported" boolean Printer Description attribute to
+          indicate whether Create-Job/Send-Document support multiple
+          document jobs or not.  Added to the Directory schema.
+      6.  Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2',
+          since binary is not legal with the 'text' type.
+      7.  Section 4.1.9.1 - added the RECOMMENDATION that a Printer
+          indicate by printing on the job's job-start-sheet that auto-
+          sensing has occurred and what document format was auto-sensed.
+      8.  Section 4.2.4 - indicated that the "multiple-document-
+          handling" Job Template attribute MUST be supported with at
+          least one value if the Printer supports multiple documents per
+          job
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 221]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      9.  Section 4.3.7.2 - indicated that the 'job-restartable' job
+          state reason SHOULD be supported if the Restart-Job operation
+          is supported.
+      10. Section 4.3.8 - changed "job-state-reasons" from RECOMMENDED
+          to REQUIRED.
+      11. Section 4.3.8 - clarified the conformance of the values of the
+          "job-state-reasons" attribute by copying conformance
+          requirements from other sections of the document so that it is
+          clear from reading the definition of "job-state-reasons" which
+          values MUST or SHOULD be supported.  The 'none',
+          'unsupported-compression', and 'unsupported-document-format'
+          values MUST be supported.  The 'job-hold-until-specified'
+          SHOULD be specified if the "job-hold-until" Job Template is
+          supported.  The following values SHOULD be supported:  'job-
+          canceled-by-user', 'aborted-by-system', and 'job-completed-
+          successfully'.  The
+          'job-canceled-by-operator' SHOULD be supported if the
+          implementation permits canceling by other than the job owner.
+          The 'job-canceled-at-device' SHOULD be supported if the device
+          supports canceling jobs at the console.  The 'job-completed-
+          with-warnings' SHOULD be supported, if the implementation
+          detects warnings.  The 'job-completed-with-errors' SHOULD be
+          supported if the implementation detects errors.  The 'job-
+          restartable' SHOULD be supported if the Restart-Job operation
+          is supported.
+      12. Section 4.3.10 - allowed a Printer to localize the "job-
+          detailed-status-message" Job Description attribute, but
+          indicated that such localization might obscure the technical
+          meaning of such messages.
+      13. Section 4.3.14 - changed the "time-at-creation", "time-at-
+          processing", and "time-at-completed" Event Time Job
+          Description attributes from OPTIONAL to REQUIRED.
+      14. Section 4.3.14.4 - added the REQUIRED "job-printer-up-time
+          (integer(1:MAX))" Job Description attribute as an alias for
+          "printer-up-time" to reduce number of operations to get job
+          times.
+      15. Section 4.4.2 - added the REQUIRED "uri-authentication-
+          supported (1setOf type2 keyword)" Printer Description
+          attribute to describe the Client Authentication used by each
+          Printer URI.
+      16. Section 4.4.12 - changed "printer-state-reasons" Printer
+          Description attribute from OPTIONAL to REQUIRED.
+      17. Section 4.4.12 - changed 'paused' value of "printer-state-
+          reasons" to MUST if Pause-Printer operation is supported.
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 222]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+      18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported
+          (1setOf keyword)" Printer Description attribute, since IPP/1.1
+          Printers do not have to support version '1.0' conformance
+          requirements.  Section 4.4.16 - added the "multiple-document-
+          jobs-supported (boolean)" Printer Description attribute so
+          that a client can tell whether a Printer that supports
+          Create-Job/Send-Document supports multiple document jobs or
+          not.  This attribute is REQUIRED if the Create-Job operation
+          is supported.
+      19. Section 4.4.24 - changed the "queued-job-count" Printer
+          Description attribute from RECOMMENDED to REQUIRED.
+      20. Section 4.4.32 - changed "compression-supported (1setOf type3
+          keyword)" Printer Description attribute from OPTIONAL to
+          REQUIRED.
+      21. Section 5.1 - changed the client security requirements from
+          RECOMMENDED non-standards track SSL3 to MUST support Client
+          Authentication as defined in the IPP/1.1 Encoding and
+          Transport document [RFC2910].  A client SHOULD support
+          Operation Privacy and Server Authentication as defined in the
+          IPP/1.1 Encoding and Transport document [RFC2910].
+      22. Section 5.2.7 - changed the IPP object security requirements
+          from OPTIONAL non-standards track SSL3 to SHOULD contain
+          support for Client Authentication as defined in the IPP/1.1
+          Encoding and Transport document [RFC2910].  A Printer
+          implementation MAY allow an administrator to configure the
+          Printer so that all, some, or none of the users are
+          authenticated.  An IPP Printer implementation SHOULD contain
+          support for Operation Privacy and Server Authentication as
+          defined in the IPP/1.1 Encoding and Transport document
+          [RFC2910].  A Printer implementation MAY allow an
+          administrator to configure the degree of support for Operation
+          Privacy and Server Authentication.  Security MUST NOT be
+          compromised when the client supplies a lower version-number in
+          a request.
+      23. Section 14 (Appendix C): Corrected typo, changing the keyword
+          'iso-10-white' to 'iso-a10-white'.
+
+   See also the "IPP/1.1 Encoding and Transport" [RFC2910] document for
+   differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910].
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 223]
+
+RFC 2911              IPP/1.1: Model and Semantics        September 2000
+
+
+18.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.            Standards Track                   [Page 224]
+
diff --git a/standards/rfc2965.txt b/standards/rfc2965.txt
new file mode 100644
index 000000000..8a4d02b17
--- /dev/null
+++ b/standards/rfc2965.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                         D. Kristol
+Request for Comments: 2965        Bell Laboratories, Lucent Technologies
+Obsoletes: 2109                                              L. Montulli
+Category: Standards Track                             Epinions.com, Inc.
+                                                            October 2000
+
+
+                    HTTP State Management Mechanism
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+IESG Note
+
+   The IESG notes that this mechanism makes use of the .local top-level
+   domain (TLD) internally when handling host names that don't contain
+   any dots, and that this mechanism might not work in the expected way
+   should an actual .local TLD ever be registered.
+
+Abstract
+
+   This document specifies a way to create a stateful session with
+   Hypertext Transfer Protocol (HTTP) requests and responses.  It
+   describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
+   carry state information between participating origin servers and user
+   agents.  The method described here differs from Netscape's Cookie
+   proposal [Netscape], but it can interoperate with HTTP/1.0 user
+   agents that use Netscape's method.  (See the HISTORICAL section.)
+
+   This document reflects implementation experience with RFC 2109 and
+   obsoletes it.
+
+1.  TERMINOLOGY
+
+   The terms user agent, client, server, proxy, origin server, and
+   http_URL have the same meaning as in the HTTP/1.1 specification
+   [RFC2616].  The terms abs_path and absoluteURI have the same meaning
+   as in the URI Syntax specification [RFC2396].
+
+
+
+
+Kristol & Montulli          Standards Track                     [Page 1]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   Host name (HN) means either the host domain name (HDN) or the numeric
+   Internet Protocol (IP) address of a host.  The fully qualified domain
+   name is preferred; use of numeric IP addresses is strongly
+   discouraged.
+
+   The terms request-host and request-URI refer to the values the client
+   would send to the server as, respectively, the host (but not port)
+   and abs_path portions of the absoluteURI (http_URL) of the HTTP
+   request line.  Note that request-host is a HN.
+
+   The term effective host name is related to host name.  If a host name
+   contains no dots, the effective host name is that name with the
+   string .local appended to it.  Otherwise the effective host name is
+   the same as the host name.  Note that all effective host names
+   contain at least one dot.
+
+   The term request-port refers to the port portion of the absoluteURI
+   (http_URL) of the HTTP request line.  If the absoluteURI has no
+   explicit port, the request-port is the HTTP default, 80.  The
+   request-port of a cookie is the request-port of the request in which
+   a Set-Cookie2 response header was returned to the user agent.
+
+   Host names can be specified either as an IP address or a HDN string.
+   Sometimes we compare one host name with another.  (Such comparisons
+   SHALL be case-insensitive.)  Host A's name domain-matches host B's if
+
+      *  their host name strings string-compare equal; or
+
+      * A is a HDN string and has the form NB, where N is a non-empty
+         name string, B has the form .B', and B' is a HDN string.  (So,
+         x.y.com domain-matches .Y.com but not Y.com.)
+
+   Note that domain-match is not a commutative operation: a.b.c.com
+   domain-matches .c.com, but not the reverse.
+
+   The reach R of a host name H is defined as follows:
+
+      *  If
+
+         -  H is the host domain name of a host; and,
+
+         -  H has the form A.B; and
+
+         -  A has no embedded (that is, interior) dots; and
+
+         -  B has at least one embedded dot, or B is the string "local".
+            then the reach of H is .B.
+
+
+
+
+Kristol & Montulli          Standards Track                     [Page 2]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+      *  Otherwise, the reach of H is H.
+
+   For two strings that represent paths, P1 and P2, P1 path-matches P2
+   if P2 is a prefix of P1 (including the case where P1 and P2 string-
+   compare equal).  Thus, the string /tec/waldo path-matches /tec.
+
+   Because it was used in Netscape's original implementation of state
+   management, we will use the term cookie to refer to the state
+   information that passes between an origin server and user agent, and
+   that gets stored by the user agent.
+
+1.1  Requirements
+
+   The key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED",
+   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  STATE AND SESSIONS
+
+   This document describes a way to create stateful sessions with HTTP
+   requests and responses.  Currently, HTTP servers respond to each
+   client request without relating that request to previous or
+   subsequent requests; the state management mechanism allows clients
+   and servers that wish to exchange state information to place HTTP
+   requests and responses within a larger context, which we term a
+   "session".  This context might be used to create, for example, a
+   "shopping cart", in which user selections can be aggregated before
+   purchase, or a magazine browsing system, in which a user's previous
+   reading affects which offerings are presented.
+
+   Neither clients nor servers are required to support cookies.  A
+   server MAY refuse to provide content to a client that does not return
+   the cookies it sends.
+
+3.  DESCRIPTION
+
+   We describe here a way for an origin server to send state information
+   to the user agent, and for the user agent to return the state
+   information to the origin server.  The goal is to have a minimal
+   impact on HTTP and user agents.
+
+3.1  Syntax:  General
+
+   The two state management headers, Set-Cookie2 and Cookie, have common
+   syntactic properties involving attribute-value pairs.  The following
+   grammar uses the notation, and tokens DIGIT (decimal digits), token
+
+
+
+
+
+Kristol & Montulli          Standards Track                     [Page 3]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   (informally, a sequence of non-special, non-white space characters),
+   and http_URL from the HTTP/1.1 specification [RFC2616] to describe
+   their syntax.
+
+   av-pairs    =     av-pair *(";" av-pair)
+   av-pair     =     attr ["=" value]              ; optional value
+   attr        =     token
+   value       =     token | quoted-string
+
+   Attributes (names) (attr) are case-insensitive.  White space is
+   permitted between tokens.  Note that while the above syntax
+   description shows value as optional, most attrs require them.
+
+   NOTE: The syntax above allows whitespace between the attribute and
+   the = sign.
+
+3.2  Origin Server Role
+
+   3.2.1  General  The origin server initiates a session, if it so
+   desires.  To do so, it returns an extra response header to the
+   client, Set-Cookie2.  (The details follow later.)
+
+   A user agent returns a Cookie request header (see below) to the
+   origin server if it chooses to continue a session.  The origin server
+   MAY ignore it or use it to determine the current state of the
+   session.  It MAY send back to the client a Set-Cookie2 response
+   header with the same or different information, or it MAY send no
+   Set-Cookie2 header at all.  The origin server effectively ends a
+   session by sending the client a Set-Cookie2 header with Max-Age=0.
+
+   Servers MAY return Set-Cookie2 response headers with any response.
+   User agents SHOULD send Cookie request headers, subject to other
+   rules detailed below, with every request.
+
+   An origin server MAY include multiple Set-Cookie2 headers in a
+   response.  Note that an intervening gateway could fold multiple such
+   headers into a single header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                     [Page 4]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   3.2.2  Set-Cookie2 Syntax  The syntax for the Set-Cookie2 response
+   header is
+
+   set-cookie      =       "Set-Cookie2:" cookies
+   cookies         =       1#cookie
+   cookie          =       NAME "=" VALUE *(";" set-cookie-av)
+   NAME            =       attr
+   VALUE           =       value
+   set-cookie-av   =       "Comment" "=" value
+                   |       "CommentURL" "=" <"> http_URL <">
+                   |       "Discard"
+                   |       "Domain" "=" value
+                   |       "Max-Age" "=" value
+                   |       "Path" "=" value
+                   |       "Port" [ "=" <"> portlist <"> ]
+                   |       "Secure"
+                   |       "Version" "=" 1*DIGIT
+   portlist        =       1#portnum
+   portnum         =       1*DIGIT
+
+   Informally, the Set-Cookie2 response header comprises the token Set-
+   Cookie2:, followed by a comma-separated list of one or more cookies.
+   Each cookie begins with a NAME=VALUE pair, followed by zero or more
+   semi-colon-separated attribute-value pairs.  The syntax for
+   attribute-value pairs was shown earlier.  The specific attributes and
+   the semantics of their values follows.  The NAME=VALUE attribute-
+   value pair MUST come first in each cookie.  The others, if present,
+   can occur in any order.  If an attribute appears more than once in a
+   cookie, the client SHALL use only the value associated with the first
+   appearance of the attribute; a client MUST ignore values after the
+   first.
+
+   The NAME of a cookie MAY be the same as one of the attributes in this
+   specification.  However, because the cookie's NAME must come first in
+   a Set-Cookie2 response header, the NAME and its VALUE cannot be
+   confused with an attribute-value pair.
+
+   NAME=VALUE
+      REQUIRED.  The name of the state information ("cookie") is NAME,
+      and its value is VALUE.  NAMEs that begin with $ are reserved and
+      MUST NOT be used by applications.
+
+      The VALUE is opaque to the user agent and may be anything the
+      origin server chooses to send, possibly in a server-selected
+      printable ASCII encoding.  "Opaque" implies that the content is of
+      interest and relevance only to the origin server.  The content
+      may, in fact, be readable by anyone that examines the Set-Cookie2
+      header.
+
+
+
+Kristol & Montulli          Standards Track                     [Page 5]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   Comment=value
+      OPTIONAL.  Because cookies can be used to derive or store private
+      information about a user, the value of the Comment attribute
+      allows an origin server to document how it intends to use the
+      cookie.  The user can inspect the information to decide whether to
+      initiate or continue a session with this cookie.  Characters in
+      value MUST be in UTF-8 encoding. [RFC2279]
+
+   CommentURL="http_URL"
+      OPTIONAL.  Because cookies can be used to derive or store private
+      information about a user, the CommentURL attribute allows an
+      origin server to document how it intends to use the cookie.  The
+      user can inspect the information identified by the URL to decide
+      whether to initiate or continue a session with this cookie.
+
+   Discard
+      OPTIONAL.  The Discard attribute instructs the user agent to
+      discard the cookie unconditionally when the user agent terminates.
+
+   Domain=value
+      OPTIONAL.  The value of the Domain attribute specifies the domain
+      for which the cookie is valid.  If an explicitly specified value
+      does not start with a dot, the user agent supplies a leading dot.
+
+   Max-Age=value
+      OPTIONAL.  The value of the Max-Age attribute is delta-seconds,
+      the lifetime of the cookie in seconds, a decimal non-negative
+      integer.  To handle cached cookies correctly, a client SHOULD
+      calculate the age of the cookie according to the age calculation
+      rules in the HTTP/1.1 specification [RFC2616].  When the age is
+      greater than delta-seconds seconds, the client SHOULD discard the
+      cookie.  A value of zero means the cookie SHOULD be discarded
+      immediately.
+
+   Path=value
+      OPTIONAL.  The value of the Path attribute specifies the subset of
+      URLs on the origin server to which this cookie applies.
+
+   Port[="portlist"]
+      OPTIONAL.  The Port attribute restricts the port to which a cookie
+      may be returned in a Cookie request header.  Note that the syntax
+      REQUIREs quotes around the OPTIONAL portlist even if there is only
+      one portnum in portlist.
+
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                     [Page 6]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   Secure
+      OPTIONAL.  The Secure attribute (with no value) directs the user
+      agent to use only (unspecified) secure means to contact the origin
+      server whenever it sends back this cookie, to protect the
+      confidentially and authenticity of the information in the cookie.
+
+      The user agent (possibly with user interaction) MAY determine what
+      level of security it considers appropriate for "secure" cookies.
+      The Secure attribute should be considered security advice from the
+      server to the user agent, indicating that it is in the session's
+      interest to protect the cookie contents.  When it sends a "secure"
+      cookie back to a server, the user agent SHOULD use no less than
+      the same level of security as was used when it received the cookie
+      from the server.
+
+   Version=value
+      REQUIRED.  The value of the Version attribute, a decimal integer,
+      identifies the version of the state management specification to
+      which the cookie conforms.  For this specification, Version=1
+      applies.
+
+   3.2.3  Controlling Caching  An origin server must be cognizant of the
+   effect of possible caching of both the returned resource and the
+   Set-Cookie2 header.  Caching "public" documents is desirable.  For
+   example, if the origin server wants to use a public document such as
+   a "front door" page as a sentinel to indicate the beginning of a
+   session for which a Set-Cookie2 response header must be generated,
+   the page SHOULD be stored in caches "pre-expired" so that the origin
+   server will see further requests.  "Private documents", for example
+   those that contain information strictly private to a session, SHOULD
+   NOT be cached in shared caches.
+
+   If the cookie is intended for use by a single user, the Set-Cookie2
+   header SHOULD NOT be cached.  A Set-Cookie2 header that is intended
+   to be shared by multiple users MAY be cached.
+
+   The origin server SHOULD send the following additional HTTP/1.1
+   response headers, depending on circumstances:
+
+      *  To suppress caching of the Set-Cookie2 header:
+
+         Cache-control: no-cache="set-cookie2"
+
+   and one of the following:
+
+      *  To suppress caching of a private document in shared caches:
+
+         Cache-control: private
+
+
+
+Kristol & Montulli          Standards Track                     [Page 7]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+      *  To allow caching of a document and require that it be validated
+         before returning it to the client:
+
+         Cache-Control: must-revalidate, max-age=0
+
+      *  To allow caching of a document, but to require that proxy
+         caches (not user agent caches) validate it before returning it
+         to the client:
+
+         Cache-Control: proxy-revalidate, max-age=0
+
+      *  To allow caching of a document and request that it be validated
+         before returning it to the client (by "pre-expiring" it):
+
+         Cache-control: max-age=0
+
+         Not all caches will revalidate the document in every case.
+
+   HTTP/1.1 servers MUST send Expires: old-date (where old-date is a
+   date long in the past) on responses containing Set-Cookie2 response
+   headers unless they know for certain (by out of band means) that
+   there are no HTTP/1.0 proxies in the response chain.  HTTP/1.1
+   servers MAY send other Cache-Control directives that permit caching
+   by HTTP/1.1 proxies in addition to the Expires: old-date directive;
+   the Cache-Control directive will override the Expires: old-date for
+   HTTP/1.1 proxies.
+
+3.3  User Agent Role
+
+   3.3.1  Interpreting Set-Cookie2  The user agent keeps separate track
+   of state information that arrives via Set-Cookie2 response headers
+   from each origin server (as distinguished by name or IP address and
+   port).  The user agent MUST ignore attribute-value pairs whose
+   attribute it does not recognize.  The user agent applies these
+   defaults for optional attributes that are missing:
+
+   Discard The default behavior is dictated by the presence or absence
+           of a Max-Age attribute.
+
+   Domain  Defaults to the effective request-host.  (Note that because
+           there is no dot at the beginning of effective request-host,
+           the default Domain can only domain-match itself.)
+
+   Max-Age The default behavior is to discard the cookie when the user
+           agent exits.
+
+   Path    Defaults to the path of the request URL that generated the
+           Set-Cookie2 response, up to and including the right-most /.
+
+
+
+Kristol & Montulli          Standards Track                     [Page 8]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   Port    The default behavior is that a cookie MAY be returned to any
+           request-port.
+
+   Secure  If absent, the user agent MAY send the cookie over an
+           insecure channel.
+
+   3.3.2  Rejecting Cookies  To prevent possible security or privacy
+   violations, a user agent rejects a cookie according to rules below.
+   The goal of the rules is to try to limit the set of servers for which
+   a cookie is valid, based on the values of the Path, Domain, and Port
+   attributes and the request-URI, request-host and request-port.
+
+   A user agent rejects (SHALL NOT store its information) if the Version
+   attribute is missing.  Moreover, a user agent rejects (SHALL NOT
+   store its information) if any of the following is true of the
+   attributes explicitly present in the Set-Cookie2 response header:
+
+      *  The value for the Path attribute is not a prefix of the
+         request-URI.
+
+      *  The value for the Domain attribute contains no embedded dots,
+         and the value is not .local.
+
+      *  The effective host name that derives from the request-host does
+         not domain-match the Domain attribute.
+
+      *  The request-host is a HDN (not IP address) and has the form HD,
+         where D is the value of the Domain attribute, and H is a string
+         that contains one or more dots.
+
+      *  The Port attribute has a "port-list", and the request-port was
+         not in the list.
+
+   Examples:
+
+      *  A Set-Cookie2 from request-host y.x.foo.com for Domain=.foo.com
+         would be rejected, because H is y.x and contains a dot.
+
+      *  A Set-Cookie2 from request-host x.foo.com for Domain=.foo.com
+         would be accepted.
+
+      *  A Set-Cookie2 with Domain=.com or Domain=.com., will always be
+         rejected, because there is no embedded dot.
+
+      *  A Set-Cookie2 with Domain=ajax.com will be accepted, and the
+         value for Domain will be taken to be .ajax.com, because a dot
+         gets prepended to the value.
+
+
+
+
+Kristol & Montulli          Standards Track                     [Page 9]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+      *  A Set-Cookie2 with Port="80,8000" will be accepted if the
+         request was made to port 80 or 8000 and will be rejected
+         otherwise.
+
+      *  A Set-Cookie2 from request-host example for Domain=.local will
+         be accepted, because the effective host name for the request-
+         host is example.local, and example.local domain-matches .local.
+
+   3.3.3  Cookie Management  If a user agent receives a Set-Cookie2
+   response header whose NAME is the same as that of a cookie it has
+   previously stored, the new cookie supersedes the old when: the old
+   and new Domain attribute values compare equal, using a case-
+   insensitive string-compare; and, the old and new Path attribute
+   values string-compare equal (case-sensitive).  However, if the Set-
+   Cookie2 has a value for Max-Age of zero, the (old and new) cookie is
+   discarded.  Otherwise a cookie persists (resources permitting) until
+   whichever happens first, then gets discarded: its Max-Age lifetime is
+   exceeded; or, if the Discard attribute is set, the user agent
+   terminates the session.
+
+   Because user agents have finite space in which to store cookies, they
+   MAY also discard older cookies to make space for newer ones, using,
+   for example, a least-recently-used algorithm, along with constraints
+   on the maximum number of cookies that each origin server may set.
+
+   If a Set-Cookie2 response header includes a Comment attribute, the
+   user agent SHOULD store that information in a human-readable form
+   with the cookie and SHOULD display the comment text as part of a
+   cookie inspection user interface.
+
+   If a Set-Cookie2 response header includes a CommentURL attribute, the
+   user agent SHOULD store that information in a human-readable form
+   with the cookie, or, preferably, SHOULD allow the user to follow the
+   http_URL link as part of a cookie inspection user interface.
+
+   The cookie inspection user interface may include a facility whereby a
+   user can decide, at the time the user agent receives the Set-Cookie2
+   response header, whether or not to accept the cookie.  A potentially
+   confusing situation could arise if the following sequence occurs:
+
+      *  the user agent receives a cookie that contains a CommentURL
+         attribute;
+
+      *  the user agent's cookie inspection interface is configured so
+         that it presents a dialog to the user before the user agent
+         accepts the cookie;
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 10]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+      *  the dialog allows the user to follow the CommentURL link when
+         the user agent receives the cookie; and,
+
+      *  when the user follows the CommentURL link, the origin server
+         (or another server, via other links in the returned content)
+         returns another cookie.
+
+   The user agent SHOULD NOT send any cookies in this context.  The user
+   agent MAY discard any cookie it receives in this context that the
+   user has not, through some user agent mechanism, deemed acceptable.
+
+   User agents SHOULD allow the user to control cookie destruction, but
+   they MUST NOT extend the cookie's lifetime beyond that controlled by
+   the Discard and Max-Age attributes.  An infrequently-used cookie may
+   function as a "preferences file" for network applications, and a user
+   may wish to keep it even if it is the least-recently-used cookie. One
+   possible implementation would be an interface that allows the
+   permanent storage of a cookie through a checkbox (or, conversely, its
+   immediate destruction).
+
+   Privacy considerations dictate that the user have considerable
+   control over cookie management.  The PRIVACY section contains more
+   information.
+
+   3.3.4  Sending Cookies to the Origin Server  When it sends a request
+   to an origin server, the user agent includes a Cookie request header
+   if it has stored cookies that are applicable to the request, based on
+
+      * the request-host and request-port;
+
+      * the request-URI;
+
+      * the cookie's age.
+
+   The syntax for the header is:
+
+cookie          =  "Cookie:" cookie-version 1*((";" | ",") cookie-value)
+cookie-value    =  NAME "=" VALUE [";" path] [";" domain] [";" port]
+cookie-version  =  "$Version" "=" value
+NAME            =  attr
+VALUE           =  value
+path            =  "$Path" "=" value
+domain          =  "$Domain" "=" value
+port            =  "$Port" [ "=" <"> value <"> ]
+
+   The value of the cookie-version attribute MUST be the value from the
+   Version attribute of the corresponding Set-Cookie2 response header.
+   Otherwise the value for cookie-version is 0.  The value for the path
+
+
+
+Kristol & Montulli          Standards Track                    [Page 11]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   attribute MUST be the value from the Path attribute, if one was
+   present, of the corresponding Set-Cookie2 response header.  Otherwise
+   the attribute SHOULD be omitted from the Cookie request header.  The
+   value for the domain attribute MUST be the value from the Domain
+   attribute, if one was present, of the corresponding Set-Cookie2
+   response header.  Otherwise the attribute SHOULD be omitted from the
+   Cookie request header.
+
+   The port attribute of the Cookie request header MUST mirror the Port
+   attribute, if one was present, in the corresponding Set-Cookie2
+   response header.  That is, the port attribute MUST be present if the
+   Port attribute was present in the Set-Cookie2 header, and it MUST
+   have the same value, if any.  Otherwise, if the Port attribute was
+   absent from the Set-Cookie2 header, the attribute likewise MUST be
+   omitted from the Cookie request header.
+
+   Note that there is neither a Comment nor a CommentURL attribute in
+   the Cookie request header corresponding to the ones in the Set-
+   Cookie2 response header.  The user agent does not return the comment
+   information to the origin server.
+
+   The user agent applies the following rules to choose applicable
+   cookie-values to send in Cookie request headers from among all the
+   cookies it has received.
+
+   Domain Selection
+      The origin server's effective host name MUST domain-match the
+      Domain attribute of the cookie.
+
+   Port Selection
+      There are three possible behaviors, depending on the Port
+      attribute in the Set-Cookie2 response header:
+
+      1. By default (no Port attribute), the cookie MAY be sent to any
+         port.
+
+      2. If the attribute is present but has no value (e.g., Port), the
+         cookie MUST only be sent to the request-port it was received
+         from.
+
+      3. If the attribute has a port-list, the cookie MUST only be
+         returned if the new request-port is one of those listed in
+         port-list.
+
+   Path Selection
+      The request-URI MUST path-match the Path attribute of the cookie.
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 12]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   Max-Age Selection
+      Cookies that have expired should have been discarded and thus are
+      not forwarded to an origin server.
+
+   If multiple cookies satisfy the criteria above, they are ordered in
+   the Cookie header such that those with more specific Path attributes
+   precede those with less specific.  Ordering with respect to other
+   attributes (e.g., Domain) is unspecified.
+
+   Note: For backward compatibility, the separator in the Cookie header
+   is semi-colon (;) everywhere.  A server SHOULD also accept comma (,)
+   as the separator between cookie-values for future compatibility.
+
+   3.3.5  Identifying What Version is Understood:  Cookie2  The Cookie2
+   request header facilitates interoperation between clients and servers
+   that understand different versions of the cookie specification.  When
+   the client sends one or more cookies to an origin server, if at least
+   one of those cookies contains a $Version attribute whose value is
+   different from the version that the client understands, then the
+   client MUST also send a Cookie2 request header, the syntax for which
+   is
+
+   cookie2 =       "Cookie2:" cookie-version
+
+   Here the value for cookie-version is the highest version of cookie
+   specification (currently 1) that the client understands.  The client
+   needs to send at most one such request header per request.
+
+   3.3.6  Sending Cookies in Unverifiable Transactions  Users MUST have
+   control over sessions in order to ensure privacy.  (See PRIVACY
+   section below.)  To simplify implementation and to prevent an
+   additional layer of complexity where adequate safeguards exist,
+   however, this document distinguishes between transactions that are
+   verifiable and those that are unverifiable.  A transaction is
+   verifiable if the user, or a user-designated agent, has the option to
+   review the request-URI prior to its use in the transaction.  A
+   transaction is unverifiable if the user does not have that option.
+   Unverifiable transactions typically arise when a user agent
+   automatically requests inlined or embedded entities or when it
+   resolves redirection (3xx) responses from an origin server.
+   Typically the origin transaction, the transaction that the user
+   initiates, is verifiable, and that transaction may directly or
+   indirectly induce the user agent to make unverifiable transactions.
+
+   An unverifiable transaction is to a third-party host if its request-
+   host U does not domain-match the reach R of the request-host O in the
+   origin transaction.
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 13]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   When it makes an unverifiable transaction, a user agent MUST disable
+   all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
+   accept any received cookies) if the transaction is to a third-party
+   host.
+
+   This restriction prevents a malicious service author from using
+   unverifiable transactions to induce a user agent to start or continue
+   a session with a server in a different domain.  The starting or
+   continuation of such sessions could be contrary to the privacy
+   expectations of the user, and could also be a security problem.
+
+   User agents MAY offer configurable options that allow the user agent,
+   or any autonomous programs that the user agent executes, to ignore
+   the above rule, so long as these override options default to "off".
+
+   (N.B.  Mechanisms may be proposed that will automate overriding the
+   third-party restrictions under controlled conditions.)
+
+   Many current user agents already provide a review option that would
+   render many links verifiable.  For instance, some user agents display
+   the URL that would be referenced for a particular link when the mouse
+   pointer is placed over that link.  The user can therefore determine
+   whether to visit that site before causing the browser to do so.
+   (Though not implemented on current user agents, a similar technique
+   could be used for a button used to submit a form -- the user agent
+   could display the action to be taken if the user were to select that
+   button.)  However, even this would not make all links verifiable; for
+   example, links to automatically loaded images would not normally be
+   subject to "mouse pointer" verification.
+
+   Many user agents also provide the option for a user to view the HTML
+   source of a document, or to save the source to an external file where
+   it can be viewed by another application.  While such an option does
+   provide a crude review mechanism, some users might not consider it
+   acceptable for this purpose.
+
+3.4  How an Origin Server Interprets the Cookie Header
+
+   A user agent returns much of the information in the Set-Cookie2
+   header to the origin server when the request-URI path-matches the
+   Path attribute of the cookie.  When it receives a Cookie header, the
+   origin server SHOULD treat cookies with NAMEs whose prefix is $
+   specially, as an attribute for the cookie.
+
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 14]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+3.5  Caching Proxy Role
+
+   One reason for separating state information from both a URL and
+   document content is to facilitate the scaling that caching permits.
+   To support cookies, a caching proxy MUST obey these rules already in
+   the HTTP specification:
+
+      *  Honor requests from the cache, if possible, based on cache
+         validity rules.
+
+      *  Pass along a Cookie request header in any request that the
+         proxy must make of another server.
+
+      *  Return the response to the client.  Include any Set-Cookie2
+         response header.
+
+      *  Cache the received response subject to the control of the usual
+         headers, such as Expires,
+
+         Cache-control: no-cache
+
+         and
+
+         Cache-control: private
+
+      *  Cache the Set-Cookie2 subject to the control of the usual
+         header,
+
+         Cache-control: no-cache="set-cookie2"
+
+         (The Set-Cookie2 header should usually not be cached.)
+
+   Proxies MUST NOT introduce Set-Cookie2 (Cookie) headers of their own
+   in proxy responses (requests).
+
+4.  EXAMPLES
+
+4.1  Example 1
+
+   Most detail of request and response headers has been omitted.  Assume
+   the user agent has no stored cookies.
+
+      1. User Agent -> Server
+
+        POST /acme/login HTTP/1.1
+        [form data]
+
+        User identifies self via a form.
+
+
+
+Kristol & Montulli          Standards Track                    [Page 15]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+      2. Server -> User Agent
+
+        HTTP/1.1 200 OK
+        Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
+
+        Cookie reflects user's identity.
+
+      3. User Agent -> Server
+
+        POST /acme/pickitem HTTP/1.1
+        Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
+        [form data]
+
+        User selects an item for "shopping basket".
+
+      4. Server -> User Agent
+
+        HTTP/1.1 200 OK
+        Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
+                Path="/acme"
+
+        Shopping basket contains an item.
+
+      5. User Agent -> Server
+
+        POST /acme/shipping HTTP/1.1
+        Cookie: $Version="1";
+                Customer="WILE_E_COYOTE"; $Path="/acme";
+                Part_Number="Rocket_Launcher_0001"; $Path="/acme"
+        [form data]
+
+        User selects shipping method from form.
+
+      6. Server -> User Agent
+
+        HTTP/1.1 200 OK
+        Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme"
+
+        New cookie reflects shipping method.
+
+      7. User Agent -> Server
+
+        POST /acme/process HTTP/1.1
+        Cookie: $Version="1";
+                Customer="WILE_E_COYOTE"; $Path="/acme";
+                Part_Number="Rocket_Launcher_0001"; $Path="/acme";
+                Shipping="FedEx"; $Path="/acme"
+        [form data]
+
+
+
+Kristol & Montulli          Standards Track                    [Page 16]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+        User chooses to process order.
+
+      8. Server -> User Agent
+
+        HTTP/1.1 200 OK
+
+        Transaction is complete.
+
+   The user agent makes a series of requests on the origin server, after
+   each of which it receives a new cookie.  All the cookies have the
+   same Path attribute and (default) domain.  Because the request-URIs
+   all path-match /acme, the Path attribute of each cookie, each request
+   contains all the cookies received so far.
+
+4.2  Example 2
+
+   This example illustrates the effect of the Path attribute.  All
+   detail of request and response headers has been omitted.  Assume the
+   user agent has no stored cookies.
+
+   Imagine the user agent has received, in response to earlier requests,
+   the response headers
+
+   Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
+           Path="/acme"
+
+   and
+
+   Set-Cookie2: Part_Number="Riding_Rocket_0023"; Version="1";
+           Path="/acme/ammo"
+
+   A subsequent request by the user agent to the (same) server for URLs
+   of the form /acme/ammo/...  would include the following request
+   header:
+
+   Cookie: $Version="1";
+           Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
+           Part_Number="Rocket_Launcher_0001"; $Path="/acme"
+
+   Note that the NAME=VALUE pair for the cookie with the more specific
+   Path attribute, /acme/ammo, comes before the one with the less
+   specific Path attribute, /acme.  Further note that the same cookie
+   name appears more than once.
+
+   A subsequent request by the user agent to the (same) server for a URL
+   of the form /acme/parts/ would include the following request header:
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 17]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001";
+   $Path="/acme"
+
+   Here, the second cookie's Path attribute /acme/ammo is not a prefix
+   of the request URL, /acme/parts/, so the cookie does not get
+   forwarded to the server.
+
+5.  IMPLEMENTATION CONSIDERATIONS
+
+   Here we provide guidance on likely or desirable details for an origin
+   server that implements state management.
+
+5.1  Set-Cookie2 Content
+
+   An origin server's content should probably be divided into disjoint
+   application areas, some of which require the use of state
+   information.  The application areas can be distinguished by their
+   request URLs.  The Set-Cookie2 header can incorporate information
+   about the application areas by setting the Path attribute for each
+   one.
+
+   The session information can obviously be clear or encoded text that
+   describes state.  However, if it grows too large, it can become
+   unwieldy.  Therefore, an implementor might choose for the session
+   information to be a key to a server-side resource.  Of course, using
+   a database creates some problems that this state management
+   specification was meant to avoid, namely:
+
+      1. keeping real state on the server side;
+
+      2. how and when to garbage-collect the database entry, in case the
+         user agent terminates the session by, for example, exiting.
+
+5.2  Stateless Pages
+
+   Caching benefits the scalability of WWW.  Therefore it is important
+   to reduce the number of documents that have state embedded in them
+   inherently.  For example, if a shopping-basket-style application
+   always displays a user's current basket contents on each page, those
+   pages cannot be cached, because each user's basket's contents would
+   be different.  On the other hand, if each page contains just a link
+   that allows the user to "Look at My Shopping Basket", the page can be
+   cached.
+
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 18]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+5.3  Implementation Limits
+
+   Practical user agent implementations have limits on the number and
+   size of cookies that they can store.  In general, user agents' cookie
+   support should have no fixed limits.  They should strive to store as
+   many frequently-used cookies as possible.  Furthermore, general-use
+   user agents SHOULD provide each of the following minimum capabilities
+   individually, although not necessarily simultaneously:
+
+      *  at least 300 cookies
+
+      *  at least 4096 bytes per cookie (as measured by the characters
+         that comprise the cookie non-terminal in the syntax description
+         of the Set-Cookie2 header, and as received in the Set-Cookie2
+         header)
+
+      *  at least 20 cookies per unique host or domain name
+
+   User agents created for specific purposes or for limited-capacity
+   devices SHOULD provide at least 20 cookies of 4096 bytes, to ensure
+   that the user can interact with a session-based origin server.
+
+   The information in a Set-Cookie2 response header MUST be retained in
+   its entirety.  If for some reason there is inadequate space to store
+   the cookie, it MUST be discarded, not truncated.
+
+   Applications should use as few and as small cookies as possible, and
+   they should cope gracefully with the loss of a cookie.
+
+   5.3.1  Denial of Service Attacks  User agents MAY choose to set an
+   upper bound on the number of cookies to be stored from a given host
+   or domain name or on the size of the cookie information.  Otherwise a
+   malicious server could attempt to flood a user agent with many
+   cookies, or large cookies, on successive responses, which would force
+   out cookies the user agent had received from other servers.  However,
+   the minima specified above SHOULD still be supported.
+
+6.  PRIVACY
+
+   Informed consent should guide the design of systems that use cookies.
+   A user should be able to find out how a web site plans to use
+   information in a cookie and should be able to choose whether or not
+   those policies are acceptable.  Both the user agent and the origin
+   server must assist informed consent.
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 19]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+6.1  User Agent Control
+
+   An origin server could create a Set-Cookie2 header to track the path
+   of a user through the server.  Users may object to this behavior as
+   an intrusive accumulation of information, even if their identity is
+   not evident.  (Identity might become evident, for example, if a user
+   subsequently fills out a form that contains identifying information.)
+   This state management specification therefore requires that a user
+   agent give the user control over such a possible intrusion, although
+   the interface through which the user is given this control is left
+   unspecified.  However, the control mechanisms provided SHALL at least
+   allow the user
+
+      *  to completely disable the sending and saving of cookies.
+
+      *  to determine whether a stateful session is in progress.
+
+      *  to control the saving of a cookie on the basis of the cookie's
+         Domain attribute.
+
+   Such control could be provided, for example, by mechanisms
+
+      *  to notify the user when the user agent is about to send a
+         cookie to the origin server, to offer the option not to begin a
+         session.
+
+      * to display a visual indication that a stateful session is in
+         progress.
+
+      * to let the user decide which cookies, if any, should be saved
+         when the user concludes a window or user agent session.
+
+      * to let the user examine and delete the contents of a cookie at
+         any time.
+
+   A user agent usually begins execution with no remembered state
+   information.  It SHOULD be possible to configure a user agent never
+   to send Cookie headers, in which case it can never sustain state with
+   an origin server.  (The user agent would then behave like one that is
+   unaware of how to handle Set-Cookie2 response headers.)
+
+   When the user agent terminates execution, it SHOULD let the user
+   discard all state information.  Alternatively, the user agent MAY ask
+   the user whether state information should be retained; the default
+   should be "no".  If the user chooses to retain state information, it
+   would be restored the next time the user agent runs.
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 20]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   NOTE: User agents should probably be cautious about using files to
+   store cookies long-term.  If a user runs more than one instance of
+   the user agent, the cookies could be commingled or otherwise
+   corrupted.
+
+6.2  Origin Server Role
+
+   An origin server SHOULD promote informed consent by adding CommentURL
+   or Comment information to the cookies it sends.  CommentURL is
+   preferred because of the opportunity to provide richer information in
+   a multiplicity of languages.
+
+6.3  Clear Text
+
+   The information in the Set-Cookie2 and Cookie headers is unprotected.
+   As a consequence:
+
+      1. Any sensitive information that is conveyed in them is exposed
+         to intruders.
+
+      2. A malicious intermediary could alter the headers as they travel
+         in either direction, with unpredictable results.
+
+   These facts imply that information of a personal and/or financial
+   nature should only be sent over a secure channel.  For less sensitive
+   information, or when the content of the header is a database key, an
+   origin server should be vigilant to prevent a bad Cookie value from
+   causing failures.
+
+   A user agent in a shared user environment poses a further risk.
+   Using a cookie inspection interface, User B could examine the
+   contents of cookies that were saved when User A used the machine.
+
+7.  SECURITY CONSIDERATIONS
+
+7.1  Protocol Design
+
+   The restrictions on the value of the Domain attribute, and the rules
+   concerning unverifiable transactions, are meant to reduce the ways
+   that cookies can "leak" to the "wrong" site.  The intent is to
+   restrict cookies to one host, or a closely related set of hosts.
+   Therefore a request-host is limited as to what values it can set for
+   Domain.  We consider it acceptable for hosts host1.foo.com and
+   host2.foo.com to share cookies, but not a.com and b.com.
+
+   Similarly, a server can set a Path only for cookies that are related
+   to the request-URI.
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 21]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+7.2  Cookie Spoofing
+
+   Proper application design can avoid spoofing attacks from related
+   domains.  Consider:
+
+      1. User agent makes request to victim.cracker.edu, gets back
+         cookie session_id="1234" and sets the default domain
+         victim.cracker.edu.
+
+      2. User agent makes request to spoof.cracker.edu, gets back cookie
+         session-id="1111", with Domain=".cracker.edu".
+
+      3. User agent makes request to victim.cracker.edu again, and
+         passes
+
+         Cookie: $Version="1"; session_id="1234",
+                 $Version="1"; session_id="1111"; $Domain=".cracker.edu"
+
+         The server at victim.cracker.edu should detect that the second
+         cookie was not one it originated by noticing that the Domain
+         attribute is not for itself and ignore it.
+
+7.3  Unexpected Cookie Sharing
+
+   A user agent SHOULD make every attempt to prevent the sharing of
+   session information between hosts that are in different domains.
+   Embedded or inlined objects may cause particularly severe privacy
+   problems if they can be used to share cookies between disparate
+   hosts.  For example, a malicious server could embed cookie
+   information for host a.com in a URI for a CGI on host b.com.  User
+   agent implementors are strongly encouraged to prevent this sort of
+   exchange whenever possible.
+
+7.4  Cookies For Account Information
+
+   While it is common practice to use them this way, cookies are not
+   designed or intended to be used to hold authentication information,
+   such as account names and passwords.  Unless such cookies are
+   exchanged over an encrypted path, the account information they
+   contain is highly vulnerable to perusal and theft.
+
+8.  OTHER, SIMILAR, PROPOSALS
+
+   Apart from RFC 2109, three other proposals have been made to
+   accomplish similar goals.  This specification began as an amalgam of
+   Kristol's State-Info proposal [DMK95] and Netscape's Cookie proposal
+   [Netscape].
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 22]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   Brian Behlendorf proposed a Session-ID header that would be user-
+   agent-initiated and could be used by an origin server to track
+   "clicktrails".  It would not carry any origin-server-defined state,
+   however.  Phillip Hallam-Baker has proposed another client-defined
+   session ID mechanism for similar purposes.
+
+   While both session IDs and cookies can provide a way to sustain
+   stateful sessions, their intended purpose is different, and,
+   consequently, the privacy requirements for them are different.  A
+   user initiates session IDs to allow servers to track progress through
+   them, or to distinguish multiple users on a shared machine.  Cookies
+   are server-initiated, so the cookie mechanism described here gives
+   users control over something that would otherwise take place without
+   the users' awareness.  Furthermore, cookies convey rich, server-
+   selected information, whereas session IDs comprise user-selected,
+   simple information.
+
+9.  HISTORICAL
+
+9.1  Compatibility with Existing Implementations
+
+   Existing cookie implementations, based on the Netscape specification,
+   use the Set-Cookie (not Set-Cookie2) header.  User agents that
+   receive in the same response both a Set-Cookie and Set-Cookie2
+   response header for the same cookie MUST discard the Set-Cookie
+   information and use only the Set-Cookie2 information.  Furthermore, a
+   user agent MUST assume, if it received a Set-Cookie2 response header,
+   that the sending server complies with this document and will
+   understand Cookie request headers that also follow this
+   specification.
+
+   New cookies MUST replace both equivalent old- and new-style cookies.
+   That is, if a user agent that follows both this specification and
+   Netscape's original specification receives a Set-Cookie2 response
+   header, and the NAME and the Domain and Path attributes match (per
+   the Cookie Management section) a Netscape-style cookie, the
+   Netscape-style cookie MUST be discarded, and the user agent MUST
+   retain only the cookie adhering to this specification.
+
+   Older user agents that do not understand this specification, but that
+   do understand Netscape's original specification, will not recognize
+   the Set-Cookie2 response header and will receive and send cookies
+   according to the older specification.
+
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 23]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+   A user agent that supports both this specification and Netscape-style
+   cookies SHOULD send a Cookie request header that follows the older
+   Netscape specification if it received the cookie in a Set-Cookie
+   response header and not in a Set-Cookie2 response header.  However,
+   it SHOULD send the following request header as well:
+
+        Cookie2: $Version="1"
+
+   The Cookie2 header advises the server that the user agent understands
+   new-style cookies.  If the server understands new-style cookies, as
+   well, it SHOULD continue the stateful session by sending a Set-
+   Cookie2 response header, rather than Set-Cookie.  A server that does
+   not understand new-style cookies will simply ignore the Cookie2
+   request header.
+
+9.2  Caching and HTTP/1.0
+
+   Some caches, such as those conforming to HTTP/1.0, will inevitably
+   cache the Set-Cookie2 and Set-Cookie headers, because there was no
+   mechanism to suppress caching of headers prior to HTTP/1.1.  This
+   caching can lead to security problems.  Documents transmitted by an
+   origin server along with Set-Cookie2 and Set-Cookie headers usually
+   either will be uncachable, or will be "pre-expired".  As long as
+   caches obey instructions not to cache documents (following Expires:
+   <a date in the past> or Pragma: no-cache (HTTP/1.0), or Cache-
+   control:  no-cache (HTTP/1.1)) uncachable documents present no
+   problem.  However, pre-expired documents may be stored in caches.
+   They require validation (a conditional GET) on each new request, but
+   some cache operators loosen the rules for their caches, and sometimes
+   serve expired documents without first validating them.  This
+   combination of factors can lead to cookies meant for one user later
+   being sent to another user.  The Set-Cookie2 and Set-Cookie headers
+   are stored in the cache, and, although the document is stale
+   (expired), the cache returns the document in response to later
+   requests, including cached headers.
+
+10.  ACKNOWLEDGEMENTS
+
+   This document really represents the collective efforts of the HTTP
+   Working Group of the IETF and, particularly, the following people, in
+   addition to the authors: Roy Fielding, Yaron Goland, Marc Hedlund,
+   Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare, Foteos Macrides,
+   David W. Morris.
+
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 24]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+11.  AUTHORS' ADDRESSES
+
+   David M. Kristol
+   Bell Laboratories, Lucent Technologies
+   600 Mountain Ave.  Room 2A-333
+   Murray Hill, NJ  07974
+
+   Phone: (908) 582-2250
+   Fax: (908) 582-1239
+   EMail: dmk@bell-labs.com
+
+
+   Lou Montulli
+   Epinions.com, Inc.
+   2037 Landings Dr.
+   Mountain View, CA  94301
+
+   EMail: lou@montulli.org
+
+12.  REFERENCES
+
+   [DMK95]    Kristol, D.M., "Proposed HTTP State-Info Mechanism",
+              available at <http://portal.research.bell-
+              labs.com/~dmk/state-info.html>, September, 1995.
+
+   [Netscape] "Persistent Client State -- HTTP Cookies", available at
+              <http://www.netscape.com/newsref/std/cookie_spec.html>,
+              undated.
+
+   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
+              Mechanism", RFC 2109, February 1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of Unicode
+              and ISO-10646", RFC 2279, January 1998.
+
+   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
+              RFC 2616, June 1999.
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 25]
+
+RFC 2965            HTTP State Management Mechanism         October 2000
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kristol & Montulli          Standards Track                    [Page 26]
+
diff --git a/standards/rfc3239.txt b/standards/rfc3239.txt
new file mode 100644
index 000000000..edd131517
--- /dev/null
+++ b/standards/rfc3239.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          C. Kugler
+Request for Comments: 3239                                      H. Lewis
+Category: Informational                                  IBM Corporation
+                                                             T. Hastings
+                                                       Xerox Corporation
+                                                           February 2002
+
+
+                   Internet Printing Protocol (IPP):
+  Requirements for Job, Printer, and Device Administrative Operations
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document specifies the requirements and uses cases for some
+   optional administrative operations for use with the Internet Printing
+   Protocol (IPP) version 1.0 and version 1.1.  Some of these
+   administrative operations operate on the IPP Job and Printer objects.
+   The remaining operations operate on a new Device object that more
+   closely models a single output device.
+
+Table of Contents
+
+   1  Introduction.....................................................2
+   2  Terminology......................................................2
+   3  Requirements and Use Cases.......................................3
+   4  IANA Considerations.............................................10
+   5  Internationalization Considerations.............................10
+   6  Security Considerations.........................................10
+   7  References......................................................11
+   Appendix A: Description of base IPP documents......................12
+   Authors' Addresses.................................................14
+   Full Copyright Statement...........................................15
+
+List of Tables
+
+   Table 1 - List of Printer Operations and corresponding Device
+      Operations ..................................................... 9
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 1]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+1 Introduction
+
+   The Internet Printing Protocol (IPP) is an application level protocol
+   that can be used for distributed printing using Internet tools and
+   technologies.  IPP version 1.1 ([RFC2911, RFC2910]) focuses on end
+   user functionality with a few administrative operations included (for
+   a description of the base IPP documents, see Appendix A).  This
+   document defines the requirements and use cases for additional
+   optional end user, operator, and administrator operations used to
+   control Job objects, Printer objects (see [RFC2911]) and a new Device
+   object.  The new Device object more closely models a single output
+   device and has no notion of a job, while the Printer object models a
+   print service which understands jobs and may represent one or more
+   output devices.
+
+   The scope of IPP is characterized in RFC 2567 [RFC2567] "Design Goals
+   for an Internet Printing Protocol".  It is not the intent of this
+   document to revise or clarify this scope or conjecture as to the
+   degree of industry adoption or trends related to IPP within printing
+   systems.  It is the intent of this document to extend the original
+   set of operations - in a similar fashion to the Set1 extensions which
+   referred to IPP/1.0 and were later incorporated into IPP/1.1.
+
+2 Terminology
+
+   This section defines terminology used throughout this document and
+   the corresponding documents that define the Administrative operations
+   on Job, Printer, and Device objects.
+
+   This document uses terms such as "client", "Printer", "Job",
+   "attributes", "keywords", and "support".  These terms have special
+   meaning and are defined in the model terminology [RFC2911] section
+   12.2.
+
+   In addition, the following capitalized terms are defined:
+
+      IPP Printer object (or Printer for short) - a software abstraction
+         defined by [RFC2911].
+
+      Printer Operation - an operation whose target is an IPP Printer
+         object and whose effect is on the Printer object.
+
+      Output Device - the physical imaging mechanism that an IPP Printer
+         controls.  Note: while this term is capitalized in this
+         specification (but not in [RFC2911]), there is no formal object
+         called an Output Device.
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 2]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+      Device Operation - an operation whose target is an IPP Printer
+         object and whose defined effect is on an Output Device.
+
+      Output Device Fan-Out - a configuration in which an IPP Printer
+         controls more that one output-device.
+
+      Printer fan-out - a configuration in which an IPP Printer object
+         controls more than one Subordinate IPP Printer object.
+
+      Printer fan-in - a configuration in which an IPP Printer object is
+         controlled by more than one IPP Printer object.
+
+      Subordinate Printer - an IPP Printer object that is controlled by
+         another IPP Printer object.  Such a Subordinate Printer may
+         have one or more Subordinate Printers.
+
+      Leaf Printer - a Subordinate Printer that has no Subordinate
+         Printers.
+
+      Non-Leaf Printer - an IPP Printer object that has one or more
+         Subordinate Printers.
+
+      Chained Printer - a Non-Leaf Printer that has exactly one
+         Subordinate Printer.
+
+      Job Creation operations - IPP operations that create a Job object:
+         Print-Job, Print-URI, and Create-Job.
+
+3 Requirements and Use Cases
+
+   The Administrative operations for Job and Printer objects will be
+   defined in one document [ipp-ops-set2].  The Administrative
+   operations for Device objects will be defined in a separate document.
+   The requirements are presented here together to show the parallelism.
+
+      1.    Have separate operations for affecting the IPP Printer
+            versus affecting the Output Device, so its clear what the
+            intent of each is, and implementers can implement one or the
+            other or both.
+
+      2.    Support fan-out of Printer objects.
+
+      3.    Support fan-out of Output Devices.
+
+      4.    Support fan-in of Printer objects, as long as it doesn't
+            make the semantics more complicated when not supporting
+            fan-in.
+
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 3]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+      5.    Support fan-in of output objects, as long as it doesn't make
+            the semantics more complicated when not supporting fan-in.
+
+      6.    Instead of having operation attributes that alter the
+            behavior of the operation significantly, have separate
+            operations, so that it is simple and clear to a client which
+            semantics the Printer is supporting (by querying the
+            "operations-supported" attribute) and it is simple to
+            describe the capabilities of a Printer implementation in
+            written documentation (just list the optional operations
+            supported).
+
+      7.    Need a Printer Operation to prevent a Printer object from
+            accepting new IPP jobs, but currently accepted jobs continue
+            unaffected to be scheduled and processed.  Need a companion
+            one to restore the Printer object to accept new IPP jobs.
+
+            Usage:  Operator is preparing to take the IPP Printer out of
+            service or to change the configuration of the IPP Printer.
+
+            Suggested name and operations:  Disable-Printer and Enable-
+            Printer
+
+      8.    Need a Device Operation to prevent an Output Device from
+            accepting any new jobs from any job submission protocol and
+            a companion one to restore the Output Device to accepting
+            any jobs.
+
+            Usage:  Operator is preparing to take the Output Device out
+            of service.
+
+            Suggested name and operations:  Disable-Device and Enable
+            Device
+
+      9.    Need a Printer Operation to stop the processing after the
+            current IPP job completes and not start processing any
+            additional IPP jobs (either by scheduling the jobs or
+            sending them to the Output Device), but continue to accept
+            new IPP jobs.  Need a companion operation to start
+            processing/sending IPP jobs again.
+
+            Usage:  Operator wants to gracefully stop the IPP Printer at
+            the next job boundary.  The Pause-Printer-After-Current-Job
+            operation is also invoked implicitly by the Deactivate-
+            Printer and the Shutdown-Printer Operations.
+
+            Suggested name and operations:  Pause-Printer-After-
+            Current-Job, (IPP/1.1) Resume-Printer
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 4]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+      10.   Need a Device Operation to stop the processing the current
+            job "immediately", no matter what protocol.  Its like the
+            Pause button on the Output Device.  This operation is for
+            emergencies.  The stop point depends on implementation, but
+            can be mid page, end of page, end of sheet, or after a few
+            sheets for Output Devices that can't stop that quickly.  The
+            paper path isn't run out.  Need a companion operation to
+            start processing the current any-protocol job without losing
+            any thing.
+
+            Usage:  Operator sees something bad about to happen, such as
+            the paper is about to jam, or the toner is running out, or
+            the device is overheating or wants to add more paper.
+
+            Suggested name and operations:  Pause-Device-Now, Resume-
+            Device
+
+      11.   Need a Printer Operation to stop the processing of IPP jobs
+            after all of the currently accepted jobs have been
+            processed, but any newly accepted jobs go into the
+            'processing-held' state.
+
+            Usage:  This allows an operator to reconfigure the Output
+            Device in order to let jobs that are held waiting for
+            resources, such as special media, get a chance.  Then the
+            operator uses another operation after reconfiguring.  He
+            repeats the two operations to restore the Output Device to
+            its normal media.
+
+            Suggested name and operations:  Hold-New-Jobs, Release-
+            Held-New-Jobs
+
+      12.   Need a Device Operation to stop processing the current any-
+            protocol job at a convenient point, such as after the
+            current copy (or end of job if last or only copy).  Need a
+            companion operation to start processing the current any-
+            protocol job or next job without losing any thing.
+
+            Usage:  The operator wants to empty the output bin that is
+            near full.  The paper path is run out.
+
+            Suggested name and operations:  Pause-Device-After-Current-
+            Copy, Resume-Device
+
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 5]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+      13.   Need a Device Operation that always pauses on a device-
+            defined boundary, no matter how many copies, in order to not
+            break up a job.  Need a companion operation to start
+            processing the current any-protocol job or next job without
+            losing any thing.
+
+            Usage:  The operator wants to empty the output bin that is
+            near full, but he doesn't want to break up a job in case it
+            has multiple copies.  The paper path is run out.
+
+            Suggested name and operations:  Pause-Device-After-Current-
+            Job, Resume-Device
+
+      14.   Need a Printer Operation that combines Disable-Printer,
+            Pause-Printer-After-Current-Job, and rejects all other Job,
+            Printer, and Device Operations, except Job and Printer
+            queries, System Administrator Set-Printer-Attributes, and
+            the companion operation to resume activity.  In other words,
+            this operation makes the Printer a read-only object in a
+            graceful manner for end-users and the operator.
+
+            Usage:  The administrator wants to reconfigure the Printer
+            object using the Set-Printer-Attributes operation without
+            disturbing the current in process work, but wants to make
+            sure that the operator isn't also trying to change the
+            Printer object as part of running the Printer.
+
+            Suggested name and operation:  Deactivate-Printer,
+            Activate-Printer
+
+      15.   Need a Device Operation that combines Disable-Device,
+            Pause-Device-After-Current-Job, and rejects all other Device
+            Operations, except Job and Printer queries and the companion
+            operation to resume activity.  In other words, this
+            operation makes the Output Device a read-only object in a
+            graceful manner.
+
+            Usage:  The field service person wants to open up the device
+            without disturbing the current in process work, perhaps to
+            replace staples, or replace the toner cartridge.
+
+            Suggested name and operation:  Deactivate-Device, Activate-
+            Device
+
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 6]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+      16.   Need a Printer Operation to recover from the IPP Printer
+            software that has gotten confused (run out of heap memory or
+            gotten into a state that it doesn't seem to be able to get
+            out of).  This is a condition that shouldn't happen, but
+            does in real life.  Any volatile information is saved if
+            possible before the software is re-initialized.  No
+            companion operation is needed to undo this.  We don't want
+            to go back to the "confused" state :-).
+
+            Usage:  The IPP Printer software has gotten confused or
+            isn't responding properly.
+
+            Suggested name and operation:  Restart-Printer
+
+      17.   Need a Device Operation to recover from the Output Device
+            hardware and software that has gotten confused (gotten into
+            a state that it doesn't seem to be able to get out of, run
+            out of heap memory, etc.).  This is a condition that
+            shouldn't happen, but does in real life.  This is the same
+            and has the same options as the Printer MIB reset.  No
+            companion operation is needed to undo this.  We don't want
+            to go back to the "confused" state :-).
+
+            Usage:  The Output Device has gotten confused or need
+            resetting to some initial conditions.
+
+            Suggested name and operation:  Reset-Device
+
+      18.   Need a Printer Operation to put the IPP Printer object out
+            of business with no way in the protocol to bring that
+            instantiation back to life (but see Startup-Printer which
+            brings up exactly one new instantiation to life with the
+            same URL).  Any volatile information is saved if possible.
+
+            Usage:  The Printer is being moved or the building's power
+            is being shut off.
+
+            Suggested name and operation:  Shutdown-Printer
+
+      19.   Need a Printer Operation to bring an IPP Printer to life
+            when there is an already running host.
+
+            Usage:  After the host is started (by means outside the IPP
+            protocol), the operator is able to ask the host to bring up
+            any number of Printer objects (that the host has been
+            configured in some way) each with distinct URLs.
+
+            Suggested name and operation:  Startup-Printer
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 7]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+      20.   Need a Device Operation to power off the Output Device after
+            writing out any software state.  It is assumed that other
+            operations have more gracefully prepared the Output Device
+            for this drastic and immediate.  There is no companion
+            Device Operation to bring the power back on.
+
+            Usage:  The Output Device is going to be moved, the power in
+            the building is going to be shutoff, the repair man has
+            arrived and needs to take the Output Device apart.
+
+            Suggested name and operation:  Power-Off-Device
+
+      21.   Need a Device Operation to startup a powered-off device.
+
+            Usage:  After a Power-Off-Device, if the device can be
+            powered back up (possibly by an intervening host that
+            supports the Device Operation).
+
+            Suggest name and operation:  Power-On-Device
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 8]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+   The tentative list of Printer and the corresponding Device Operations
+   is shown in Table 1:
+
+   Table 1 - List of Printer Operations and corresponding Device
+             Operations
+
+   Printer Operation                   Corresponding Device Operation
+                                       equivalent
+
+   Disable-Printer                     Disable-Device
+
+   Enable-Printer                      Enable-Device
+
+   Pause-Printer (IPP/1.1 - [RFC2911]  Pause-Device-Now
+   - one interpretation)
+
+   no                                  Pause-Device-After-Current-Copy
+
+   Pause-Printer-After-Current-Job     Pause-Device-After-Current-Job
+
+   Resume-Printer (IPP/1.1 -           Resume-Device
+   [RFC2911])
+
+   Hold-New-Jobs                       no
+
+   Release-Held-New-Jobs               no
+
+   Deactivate-Printer                  Deactivate-Device
+
+   Activate-Printer                    Activate-Device
+
+   Purge-Jobs (IPP/1.1 - [RFC2911])    Purge-Device
+
+   Restart-Printer                     Reset-Device
+
+   Shutdown-Printer                    Power-Off-Device
+
+   Startup-Printer                     Power-On-Device
+
+   There are no conformance dependencies between Printer Operations and
+   Device Operations.  Either may be supported without supporting the
+   corresponding operations.
+
+
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                      [Page 9]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+4 IANA Considerations
+
+   This document does not define anything to be registered.  When a
+   document is produced that defines operations that meet the
+   requirements in this document, those operations will be registered
+   according to the procedures in [RFC2911] section 6.4.
+
+5 Internationalization Considerations
+
+   This document has the same localization considerations as the
+   [RFC2911].
+
+6 Security Considerations
+
+   This document defines the requirements for operations that are
+   intended to be used by an operator or system administrator.  These
+   operations, when defined, would affect how the Printer behaves and
+   establish policy and/or operating behavior that ordinary users
+   shouldn't be able to perform.  Printer implementations that support
+   such operations should authenticate users and authorized them as
+   being an operator or a system administrator for the system.
+   Otherwise, unprivileged users could affect the policy and behavior of
+   IPP Printers, thereby affecting other users.  Similarly clients that
+   supports such operations should be prepared to provide the necessary
+   authentication information.  See the security provisions in [RFC2911]
+   for authentication, such as TLS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                     [Page 10]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+7 References
+
+   [ipp-ntfy]     Herriot, R., Hastings, T., Isaacson, S., Martin, J.,
+                  deBry, R., Shepherd, M. and R. Bergman, "Internet
+                  Printing Protocol/1.1:  IPP Event Notifications and
+                  Subscriptions", Work in Progress.
+
+   [ipp-ops-set2] Kugler, C., Hastings, T. and H. Lewis, "Internet
+                  Printing Protocol (IPP): Job and Printer
+                  Administrative Operations", Work in Progress.
+
+   [RFC2565]      Herriot, R., Butler, S., Moore, P. and R. Tuner,
+                  "Internet Printing Protocol/1.0: Encoding and
+                  Transport", RFC 2565, April 1999.
+
+   [RFC2566]      deBry, R., Hastings, T., Herriot, R. and S. Isaacson,
+                  P. Powell, "Internet Printing Protocol/1.0: Model and
+                  Semantics", RFC 2566, April 1999.
+
+   [RFC2567]      Wright, D., "Design Goals for an Internet Printing
+                  Protocol", RFC 2567, April 1999.
+
+   [RFC2568]      Zilles, S., "Rationale for the Structure and Model and
+                  Protocol for the Internet Printing Protocol", RFC
+                  2568, April 1999.
+
+   [RFC2569]      Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+                  "Mapping between LPD and IPP Protocols", RFC 2569,
+                  April 1999.
+
+   [RFC2616]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                  Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+                  Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2910]      Herriot, R., Butler, S., Moore, P. and R. Tuner,
+                  "Internet Printing Protocol/1.1: Encoding and
+                  Transport", RFC 2910, September 2000.
+
+   [RFC2911]      deBry, R., Hastings, T., Herriot, R., Isaacson, S. and
+                  P. Powell, "Internet Printing Protocol/1.0: Model and
+                  Semantics", RFC 2911, September 2000.
+
+   [RFC3196]      Hastings, T., Manros, C., Zehler, P., Kuger, C. and H.
+                  Holst, "Internet Printing Protocol/1.1: Implementer's
+                  Guide", RFC 3196, November 2001.
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                     [Page 11]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+Appendix A: Description of base IPP documents
+
+   The base set of IPP documents includes:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+      Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+      Mapping between LPD and IPP Protocols [RFC2569]
+      Internet Printing Protocol (IPP): IPP Event Notifications and
+      Subscriptions [ipp-ntfy]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0.  A few optional operator operations have
+   been added to IPP/1.1.
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF working group's major decisions.
+
+   The "Internet Printing Protocol/1.1: Model and Semantics" document
+   describes a simplified model with abstract objects, their attributes,
+   and their operations that are independent of encoding and transport.
+   It introduces a Printer and a Job object.  The Job object optionally
+   supports multiple documents per Job.  It also addresses security,
+   internationalization, and directory issues.
+
+   The "Internet Printing Protocol/1.1: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1 [RFC2616].  It defines the
+   encoding rules for a new Internet MIME media type called
+   "application/ipp".  This document also defines the rules for
+   transporting over HTTP a message body whose Content-Type is
+   "application/ipp".  This document defines the 'ippget' scheme for
+   identifying IPP printers and jobs.
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                     [Page 12]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+   The "Internet Printing Protocol/1.1: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.1 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+   The "IPP Event Notifications and Subscriptions" document defines an
+   extension to IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [RFC2911,
+   RFC2910].  This extension allows a client to subscribe to printing
+   related Events and defines the semantics for delivering asynchronous
+
+   Event Notifications to the specified Notification Recipient via a
+   specified Delivery Method (i.e., protocols) defined in (separate)
+   Delivery Method documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                     [Page 13]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+Authors' Addresses
+
+   Carl Kugler
+   IBM
+   Boulder CO
+
+   Phone: (303) 924-5060
+   EMail:  kugler@us.ibm.com
+
+
+   Tom Hastings
+   Xerox Corporation
+   737 Hawaii St.  ESAE 231
+   El Segundo, CA  90245
+
+   Phone: 310-333-6413
+   Fax: 310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Harry Lewis
+   IBM
+   Boulder CO
+
+   Phone: (303) 924-5337
+   EMail:  harryl@us.ibm.com
+
+   IPP Web Page:  http://www.pwg.org/ipp/
+   IPP Mailing List:  ipp@pwg.org
+
+   To subscribe to the ipp mailing list, send the following email:
+
+      1) send it to majordomo@pwg.org
+      2) leave the subject line blank
+      3) put the following two lines in the message body:
+           subscribe ipp
+           end
+
+   Implementers of this specification document are encouraged to join
+   the IPP Mailing List in order to participate in any discussions of
+   clarification issues and review of registration proposals for
+   additional attributes and values.  In order to reduce spam the
+   mailing list rejects mail from non-subscribers, so you must subscribe
+   to the mailing list in order to send a question or comment to the
+   mailing list.
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                     [Page 14]
+
+RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, Lewis & Hastings     Informational                     [Page 15]
+
diff --git a/standards/rfc3380.txt b/standards/rfc3380.txt
new file mode 100644
index 000000000..6ea6c07ce
--- /dev/null
+++ b/standards/rfc3380.txt
@@ -0,0 +1,3307 @@
+
+
+
+
+
+
+Network Working Group                                        T. Hastings
+Request for Comments: 3380                             Xerox Corporation
+Updates: 2910, 2911                                           R. Herriot
+Category: Standards Track                                     Consultant
+                                                               C. Kugler
+                                                                H. Lewis
+                                                         IBM Corporation
+                                                          September 2002
+
+
+                   Internet Printing Protocol (IPP):
+                     Job and Printer Set Operations
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document is an OPTIONAL extension to the Internet Printing
+   Protocol (IPP/1.0 and IPP/1.1).  This document specifies 3 additional
+   OPTIONAL operations for use with the Internet Printing Protocol/1.0
+   (IPP) and IPP/1.1.  The end user, operator, and administrator Set-
+   Job-Attributes and Set-Printer-Attributes operations are used to
+   modify IPP Job objects and Printer objects, respectively.  The Get-
+   Printer-Supported-Values administrative operation returns values that
+   the IPP Printer will accept for setting its "xxx-supported"
+   attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 1]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+Table of Contents
+
+   1 Introduction......................................................4
+   2 Terminology.......................................................5
+   2.1 Conformance Terminology.........................................5
+   2.2 Other terminology...............................................5
+   3 Requirements and Use Cases........................................5
+   4 Definition of the Set operations..................................6
+   4.1 Set-Printer-Attributes Operation................................7
+   4.1.1 Settable and READ-ONLY Printer Description attributes.........9
+   4.1.2 Set-Printer-Attributes Request...............................10
+   4.1.3 Set-Printer-Attributes Response..............................12
+   4.2 Set-Job-Attributes Operation...................................13
+   4.2.1 Settable and READ-ONLY Job Description attributes............16
+   4.2.2 Set-Job-Attributes Request...................................17
+   4.2.3 Set-Job-Attributes Response..................................18
+   4.3 Get-Printer-Supported-Values Operation.........................19
+   4.3.1 Definition of the usage of the 'admin-define' out-of-band
+         attribute value..............................................20
+   5 New Operation attributes.........................................22
+   5.1 printer-message-from-operator (text(127))......................22
+   5.2 job-message-from-operator (text(127))..........................23
+   6 New Printer Description Attributes...............................24
+   6.1 printer-settable-attributes-supported (1setOf type2 keyword)...24
+   6.2 job-settable-attributes-supported (1setOf type2 keyword).......25
+   6.3 document-format-varying-attributes (1setOf type2 keyword)......25
+   6.4 printer-message-time (integer(MIN:MAX))........................25
+   6.5 printer-message-date-time (dateTime)...........................26
+   6.6 printer-xri-supported (1setOf collection)......................26
+   6.7 xri-uri-scheme-supported (1setOf uriScheme)....................28
+   6.8 xri-authentication-supported (1setOf type2 keyword)............29
+   6.9 xri-security-supported (1setOf type2 keyword)..................29
+   7 Additional status codes..........................................29
+   7.1 client-error-attributes-not-settable (0x0413)..................29
+   8 Additional out-of-band values....................................30
+   8.1 'not-settable' out-of-band value...............................30
+   8.1.1 Encoding of the 'not-settable' out-of-band attribute value...30
+   8.2 'delete-attribute' out-of-band value...........................30
+   8.2.1 Encoding of the 'delete-attribute' out-of-band value.........31
+   8.3 'admin-define' out-of-band attribute value.....................31
+   8.3.1 Encoding of the 'admin-define' out-of-band attribute value...32
+   9 New Values for Existing Printer Description Attributes...........33
+   9.1 operations-supported (1setOf type2 enum).......................33
+   10 Conformance Requirements........................................33
+   11 IANA Considerations.............................................34
+   11.1 Operation Registrations.......................................35
+   11.2 Additional Enum Attribute Value Registrations for the
+        "operations-supported" Printer Attribute......................35
+
+
+
+Hastings, et. al.           Standards Track                     [Page 2]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   11.3 Attribute Registrations.......................................35
+   11.4 Status code Registrations.....................................36
+   11.5 Out-of-band Attribute Value Registrations.....................36
+   12 Internationalization Considerations.............................37
+   13 Security Considerations.........................................37
+   14 References......................................................38
+   14.1 Normative References..........................................38
+   14.2 Informative References........................................38
+   Appendix A: Allowed Values for Set-Printer-Attributes and Set-Job-
+               Attributes requests (Normative)........................39
+   Appendix B: Attributes returned from Get-Printer-Supported-Values
+               (Normative)............................................50
+   Appendix C: Description of the Base IPP Documents (Informative)....55
+   Authors' Addresses.................................................56
+   Full Copyright Statement...........................................58
+
+Table of Tables
+
+   Table 1 -  Operation-Id assignments.................................7
+   Table 2 -  Job State Transition Table for the Set-Job-Attributes
+              operation ..............................................15
+   Table 3 -  Member attributes of "printer-xri-supported" (1setOf
+              collection) ............................................27
+   Table 4 -  Operation-id assignments................................33
+   Table 5 -  Validation rules for 'Any of "xxx-supported" '..........40
+   Table 6 -  Validation rules for 'From Get-Printer-Supported-Values'41
+   Table 7 -  Values allowed for Job Template Attributes in the Set-Job-
+              Attributes Operation ...................................42
+   Table 8 -  Values allowed for Job Description Attributes in the Set-
+              Job-Attributes Operation ...............................43
+   Table 9 -  Values allowed for Printer Job Template Attributes in the
+              Set-Printer-Attributes Operation .......................44
+   Table 10 - Values allowed for Printer Description Attributes in the
+              Set-Printer-Attributes Operation .......................47
+   Table 11 - Printer Job Template Attributes returned from Get-Printer-
+              Supported-Values .......................................51
+   Table 12 - Printer Job Template Attributes returned from Get-Printer-
+              Supported-Values .......................................51
+   Table 13 - Printer Description Attributes returned from Get-Printer-
+              Supported-Values .......................................51
+   Table 14 - Printer Job Template Attributes returned from Get-Printer-
+              Supported-Values .......................................52
+   Table 15 - Printer Job Template Attributes returned from Get-Printer-
+              Supported-Values .......................................52
+   Table 16 - Printer Description Attributes returned from Get-Printer-
+              Supported-Values .......................................53
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 3]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+1 Introduction
+
+   This document is an OPTIONAL extension to IPP/1.0 [RFC2565, RFC2566]
+   and IPP/1.1 [RFC2911, RFC2910].  For a description of the base IPP
+   documents see Appendix C.
+
+   The Internet Printing Protocol (IPP) is an application level protocol
+   that can be used for distributed printing using Internet tools and
+   technologies.  IPP version 1.1 [RFC2911, RFC2910] focuses on end user
+   functionality with a few administrative operations included.  This
+   document defines additional OPTIONAL end user, operator, and
+   administrator Set-Job-Attributes and Set-Printer-Attributes
+   operations used to modify IPP Job objects and Printer objects,
+   respectively.  It also defines a third Get-Printer-Supported-Values
+   administrator operation that returns values that the IPP Printer will
+   accept for setting its "xxx-supported" attributes.  The Get-Printer-
+   Supported-Values operation MUST be supported, if the implementation
+   supports setting any "xxx-supported" Printer attributes using the
+   Set-Printer-Attributes operation.
+
+   Nine Printer Description attributes are defined:
+
+   printer-settable-attributes-supported (1setOf type2 keyword)
+   job-settable-attributes-supported (1setOf type2 keyword)
+   document-format-varying-attributes (1setOf type2 keyword)
+   printer-message-time (integer(MIN:MAX))
+   printer-message-date-time (dateTime)
+   printer-xri-supported (1setOf collection)
+   xri-uri-scheme-supported (1setOf uriScheme)
+   xri-authentication-supported (1setOf type2 keyword)
+   xri-security-supported (1setOf type2 keyword)
+
+   Three out-of-band values are defined for use with these three
+   operations: 'delete-attribute' for deleting Job attributes with the
+   Set-Job-Attributes request, 'not-settable' for use in either the
+   Set-Job-Attributes or Set-Printer-Attributes responses, and 'admin-
+   define' for use in the Get-Printer-Supported-Values response.
+
+   Two operation attributes: "printer-message-from-operator" (text) and
+   "job-message-from-operator" (text) are defined to set the
+   corresponding IPP/1.1 Printer and Job Description attributes with the
+   same names.  These operation attributes may be used with any
+   operation that affect the Printer or Job object for which an
+   operation might want to indicate a message.  For the Set-Job-
+   Attributes and Set-Printer-Attributes operations, the client MUST
+   explicitly set them, rather than using these operation attributes.
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 4]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   A Printer implementation can make the value of some attributes
+   dependent on the document-format, e.g., "resolution-supported".
+
+2 Terminology
+
+   This section defines terminology used throughout this document.
+
+2.1 Conformance Terminology
+
+   Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+   NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+   conformance as defined in BCP 14, RFC 2119 [RFC2119] and [RFC2911]
+   section 12.1.  If an implementation supports the extension defined in
+   this document, then these terms apply; otherwise, they do not.  These
+   terms define conformance to this document only; they do not affect
+   conformance to other documents, unless explicitly stated otherwise.
+
+2.2 Other terminology
+
+   This document uses terms such as Job object (or Job), IPP Printer
+   object (or Printer), "operation", "request", response", "attributes",
+   "keywords", and "support".  These terms have special meaning and are
+   defined in the model terminology [RFC2911], section 12.2.  The
+   following additional terms are introduced in this document:
+
+   READ-ONLY: used in an attribute definition document to indicate that
+      the attribute MUST NOT be settable using an IPP protocol Set
+      operation.  In other words, the attribute is not settable by
+      definition.
+
+   not-settable: an implementation does not support setting an attribute
+      (whether or not the attribute's definition is READ-ONLY).
+
+3 Requirements and Use Cases
+
+   The following requirements and usage are intended to be met by the
+   specification in this document.
+
+   1. The end-user and the operator need a way to modify a Job that is
+      in the 'pending' or 'pending-held' state.
+
+      Usage: The end-user discovers that he/she forgot to include a
+      print instruction, such as "finishings" = 'staple' after
+      submitting a job.  Rather than canceling the job and resubmitting
+      it to the same IPP Printer, the end-user is able to modify the job
+      on the IPP Printer.
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 5]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      The operator needs to modify a job because it is requesting a
+      particular kind of media for which there is no more, but the
+      policy is to print the job on a comparable medium.
+
+   2. The system administrator needs a way to re-configure or change the
+      policy of the IPP Printer remotely.
+
+      Usage: The system administrator is adding additional named media
+      to the supported media list (setting 'name' values to the "media-
+      supported" Printer attribute).
+
+      The system administrator is reducing the capability of the IPP
+      Printer by removing one of the operations from the supported
+      operations list, such as Cancel-Job, because the policy is to run
+      the IPP Printer like a public facsimile machine.  After having
+      removed Cancel-Job from the list of supported operations, an
+      administrative client needs to be able to display to an
+      administrator that the implementation is capable of being
+      reconfigured to support Cancel-Job once again.
+
+      The system administrator is remotely configuring the IPP Printer
+      after installing it, and so is replacing the Printer Description
+      attributes that have the out-of-band 'no-value' value (see
+      [RFC2911], section 4.1) with the proper values.
+
+      The operator is changing the media loaded in the input tray, and
+      so is replacing the "media-ready" Job Template Printer attribute
+      value with the proper values.
+
+4 Definition of the Set operations
+
+   The Set-Printer-Attributes operations (as are all Printer operations)
+   are directed at Printer objects.  A client MUST always supply the
+   "printer-uri" operation attribute in order to identify the correct
+   target of the operation.  These descriptions assume all of the common
+   semantics of the IPP/1.1 Model and Semantics document [RFC2911],
+   section 3.1.
+
+   The Set-Job-Attributes operations (as are all Job operations) are
+   directed at Job objects.  A client MUST always supply some means of
+   identifying the Job object in order to identify the correct target of
+   the operation.  That job identification MAY either be a single Job
+   URI or a combination of a Printer URI with a Job ID, as defined in
+   [RFC2911].  The IPP object implementation MUST support both forms of
+   identification for every job.  If possible, a client SHOULD use the
+   Printer URI with a Job ID rather than a Job URI, since the 32-bit
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 6]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   "job-id" is more readily translated to and from other print protocols
+   that MAY be serving as gateways into or out of the IPP
+   implementation.
+
+   The Set Printer operations are summarized in Table 1:
+
+                     Table 1 - Operation-Id assignments
+
+      Operation Name      Operation  Brief description
+                          -Id
+
+      Set-Printer-        0x0013     Sets attribute values of the target
+      Attributes                     Printer object
+
+      Set-Job-Attributes  0x0014     Sets attribute values of the target
+                                     Job object
+
+      Get-Printer-        0x0015     Gets values that are valid for
+      Supported-Values               setting "xxx-supported" attributes
+                                     using the Set-Printer-Attributes
+                                     operation
+
+4.1 Set-Printer-Attributes Operation
+
+   This OPTIONAL operation allows a client to set the values of the
+   attributes of a Printer object.  In the request, the client supplies
+   the set of Printer keyword attribute names and values that are to be
+   set.  In the response, the Printer object returns success or rejects
+   the entire request with indications of which attribute or attributes
+   could not be set.
+
+   The Printer object validates the client-supplied attributes in the
+   Set-Printer-Attributes request.  For an attribute to validate, it
+   MUST meet all of the following rules:
+
+   1. The number of attributes supplied by the client MUST NOT exceed
+      the maximum number that the Printer supports in a Set-Printer-
+      Attributes request.  A Printer MUST accept at least one attribute,
+      but SHOULD accept a reasonable number in a single Set-Printer-
+      Attributes request.
+
+      Note: There is no way for the client to determine the maximum
+      number of attributes that the Printer supports in a Set-Printer-
+      Attributes request, except to try a reasonable number.
+
+   2. The Printer MUST support the attribute.
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 7]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   3. The attribute MUST NOT be READ-ONLY, i.e., the definition of the
+      attribute MUST NOT indicate that the attribute is READ-ONLY (see
+      Appendix A for an indication of which IPP/1.1 attributes are
+      READ-ONLY).
+
+   4. The attribute MUST be settable in this implementation.
+
+   5. The Printer MUST support the value, according to the rules defined
+      in Appendix A, i.e., each value of each supplied "xxx" attribute
+      MUST be validated against the value of a corresponding "xxx-
+      supported" Printer attribute.  One of those rules permits an
+      administrator to set arbitrary 'name' values to those "xxx-
+      supported" Printer attributes that include the 'name' attribute
+      syntax if the implementation supports the 'admin-define' out-of-
+      band value for that "xxx-supported" attribute (see section 8.3 and
+      Appendix A).
+
+   6. The attribute's values MUST NOT conflict with the values of other
+      Printer attributes, including ones being set in this same
+      operation.
+
+   If any of the supplied attributes are not validate, the Printer
+   object MUST reject the entire operation; the Printer object MUST NOT
+   partially set some of the supplied attributes.  In other words, after
+   the operation, all the supplied attributes MUST be set or none of
+   them MUST be set, thus making the Set-Printer-Attributes an atomic
+   operation.
+
+   The Printer MUST accept this operation when its READ-ONLY "printer-
+   state" attribute (see [RFC2911], section 4.4.11) is 'idle' or
+   'stopped', and SHOULD accept it when the value is 'processing'.  The
+   Printer MUST accept this operation for any of the values of the
+   Printer object's READ-ONLY "printer-state-reasons" and "printer-is-
+   accepting-jobs" attributes, unless explicitly defined otherwise in
+   the definition of these attributes' values.
+
+   This operation MUST NOT change the value of attributes not specified
+   in the operation unless the definition of the attribute explicitly
+   specifies such side-effects.  For example, this document explicitly
+   specifies that when this operation sets "printer-message-from-
+   operator", the Printer also MUST set the READ-ONLY "printer-message-
+   time" and READ-ONLY "printer-message-date-time" attributes to the
+   time of the operation as a side effect.  In particular, if this
+   operation changes an "xxx-default" attribute, the new value MUST be
+   in the "xxx-supported" attributes or the request MUST contain a new
+   value for "xxx-supported", which contains the new value for the
+   "xxx-default".  Otherwise, the Printer MUST reject the operation.  In
+   general, Printer attribute definitions that are settable will not
+
+
+
+Hastings, et. al.           Standards Track                     [Page 8]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   define side-effects on other attributes that are settable, only side
+   effects on READ-ONLY attributes, if any.
+
+4.1.1 Settable and READ-ONLY Printer Description attributes
+
+   If the Printer supports the Set-Printer-Attributes operation, then it
+   SHOULD support the setting of:
+
+      all Job Template Default ("xxx-default") attributes
+      all Job Template Supported ("xxx-supported") attributes
+      all Job Template Ready ("xxx-ready") attributes
+
+   that the implementation supports (see [RFC2911] section 4.2 and
+   extensions).
+
+   Some Printer Description attributes (see [RFC2911] section 4.4) MUST
+   NOT be settable, i.e., they are defined to be READ-ONLY.  An
+   attribute marked as "READ-ONLY" in the Printer Description attribute
+   table in Appendix A is such an attribute.  The Printer attributes
+   that are not marked as "READ-ONLY" MAY be settable using the Set-
+   Printer-Attributes operation, depending on implementation.
+
+   Note: From now on, all extensions that define new object attributes
+   will indicate whether or not the attributes are READ-ONLY, by
+   including the "READ-ONLY" adjective in their descriptions and/or
+   explicitly stating whether they MAY be settable.
+
+   The current values of each "xxx-supported" Printer attribute MUST
+   reflect the current policy for support of the corresponding "xxx"
+   attribute.  If an "xxx-supported" Printer attribute is settable in an
+   implementation, then its value(s) MUST affect the behavior of the
+   implementation.  If an "xxx-supported" Printer attribute is defined
+   to be READ-ONLY or is not-settable in an implementation, then its
+   values MUST NOT be settable using the Set-Printer-Attributes
+   operation.  Consider the following examples:
+
+      For example, if the "operations-supported" Printer Description
+      attribute (see [RFC2911] section 4.4.15) is settable in a
+      particular implementation, then changing its value with a Set-
+      Printer-Attributes operation MUST affect the operations that the
+      implementation accepts or rejects.  Such an implementation will
+      need to be able to reject values for operations that it contains
+      no code support for (see section 4.3).  If the "operations-
+      supported" Printer Description attribute is not settable in a
+      particular implementation, then that implementation MUST reject an
+      attempt to set it with a Set-Printer-Attributes operation, return
+      the 'client-error-attributes-not-settable' status code (see
+      section 7.1), and return the "operations-supported" attribute,
+
+
+
+Hastings, et. al.           Standards Track                     [Page 9]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      with the out-of-band 'not-settable' value in the Unsupported
+      Attributes Group.
+
+      As another example, consider an implementation in which the
+      "media-default" and "media-supported" are settable.  If a client
+      supplies a Set-Printer-Attributes request that contains the
+      "media-default" attribute with a value that is not a member of the
+      Printer's "media-supported" attribute, the Printer MUST reject the
+      request and return the "client-error-conflicting-attributes"
+      status code with the "media-default" and "media-supported"
+      attributes and their values (see [RFC2911] section 3.1.7).
+
+      As a third example, if a client supplies a Set-Printer-Attributes
+      request that contains both the "media-default" and the "media-
+      supported" attributes, but includes a value in the "media-default"
+      that is not a member of the supplied "media-supported" attribute,
+      the Printer MUST reject the request and return the "client-error-
+      conflicting-attributes" status code with the "media-default" and
+      "media-supported" attributes and their values (see [RFC2911]
+      section 3.1.7).
+
+   Access Rights: The authenticated user (see [RFC2911] section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911] Sections 1 and 8.5).  Most Printer
+   attributes will require administrator access rights to set, such as
+   "xxx-supported", while some will require operator access rights only,
+   such as "media-ready" and "printer-message-from-operator".  Which
+   attributes require which access rights depends on implementation, and
+   MAY depend on site policy.
+
+4.1.2 Set-Printer-Attributes Request
+
+   The following sets of attributes are part of the Set-Printer-
+   Attributes Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes, as described in [RFC2911], section 3.1.4.1.
+
+      Target:
+         The "printer-uri" (uri) operation attribute, which is the
+         target for this operation, as described in [RFC2911], section
+         3.1.5.
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 10]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client, as described in [RFC2911], section 8.3.
+
+      "document-format" (mimeMediaType):
+         The client OPTIONALLY supplies this attribute.  The Printer
+         object MUST support this attribute.  This attribute is useful
+         for a client to select the document-format to which the
+         attribute modification should be applied.  A Printer
+         implementation MAY allow some attributes to have different
+         values for each document format that it supports.  See
+         [RFC2911], section 3.2.5.1 "Get-Printer-Attributes Request".
+
+         If the client includes this attribute, the Printer MUST change
+         the supplied attributes for the document format specified by
+         this attribute.  If a supplied attribute is a member of the
+         "document-format-varying-attributes" (i.e., the attribute
+         varies by document format, see section 6.3), the Printer MUST
+         change the supplied attribute for the document format specified
+         by this attribute, but not for other document formats.  If a
+         supplied attribute isn't a member of the "document-format-
+         varying-attributes" (i.e., it doesn't vary by document format),
+         the Printer MUST change the supplied attribute for all document
+         formats.
+
+         If the client omits this attribute, the Printer MUST change the
+         supplied attributes for all document formats, whether or not
+         they vary by document-format.
+
+         If the client supplies a value for the "document-format"
+         Operation attribute, that is either 'application/octet-stream'
+         or not supported by the Printer, i.e., is not among the values
+         of the Printer object's "document-format-supported" attribute,
+         the Printer object MUST reject the operation and return the
+         'client-error-document-format-not-supported' status code.
+         Note: the document-format 'application/octet-stream' is the
+         union of several document-formats (see [RFC2911] section
+         3.2.5.1, Get-Printer-Attributes) and is not a true document-
+         format.
+
+   Group 2: Printer Attributes
+
+      The client MUST supply a set of Printer attributes with one or
+      more values (including explicitly allowed out-of-band values) as
+      defined in [RFC2911] section 4.2 Job Template Attributes ("xxx-
+      default", "xxx-supported", and "xxx-ready" attributes), section
+      4.4 Printer Description Attributes, and any attribute extensions
+      supported by the Printer.  The value(s) of each Printer attribute
+
+
+
+Hastings, et. al.           Standards Track                    [Page 11]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      supplied in Group 2 replaces the value(s) of the corresponding
+      Printer attribute on the target Printer object.  For attributes
+      that can have multiple values (1setOf), all values supplied by the
+      client replace all values of the corresponding Printer object
+      attribute.  If a Printer object attribute had not yet been
+      configured, and so assumed the 'no-value' out-of-band value (see
+      [RFC2911] section 4.1), the supplied value(s) replaces the 'no-
+      value' value.
+
+4.1.3 Set-Printer-Attributes Response
+
+   The Printer object returns the following sets of attributes as part
+   of the Get-Printer-Attributes Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+         In addition to the REQUIRED status code returned in every
+         response, the response OPTIONALLY includes a "status-message"
+         (text(255)) and/or a "detailed-status-message" (text(MAX))
+         operation attribute, as described in [RFC2911] sections 3.1.6
+         and 13.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes, as described in [RFC2911], section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911], section 3.1.7, for details on returning Unsupported
+      Attributes.
+
+      If some of the attributes in the operation fail to validate, the
+      Printer MUST reject the operation, MUST NOT change any Printer
+      attributes, and MUST return the indicated status code below.  In
+      this group, the Printer MUST also return all attributes that fail
+      to validate.  The following are the reasons that an attribute
+      fails to validate and the value returns for the attribute, along
+      with the indicated status code and order of detection:
+
+      1. The number of attributes supplied by the client exceeds the
+         maximum number that the Printer supports in a Set-Printer-
+         Attributes request: return the 'client-error-request-entity-
+         too-large' (see [RFC2911], section 13.1.4.9).
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 12]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      2. The Printer doesn't support the attribute: return the attribute
+         with the "out-of-band" value 'unsupported' (see [RFC2911]
+         section 3.1.7 and [RFC2910]) and the 'client-error-attributes-
+         or-values-not-supported (see [RFC2911], section 13.1.4.12).
+
+      3. The attribute is either READ-ONLY (in its definition) or is
+         not-settable in this implementation: return the attribute with
+         the "out-of-band" value 'not-settable' (see section 8.1) and
+         the 'client-error-attributes-not-settable' status code (see
+         section 7.1).
+
+      4. The Printer doesn't support the value: if the attribute in the
+         operation has a single value, return it.  If the attribute in
+         the operation is multi-valued, return only those values in a
+         1setOf that are not supported.  Return the 'client-error-
+         attributes-or-values-not-supported' status code (see [RFC2911],
+         section 13.1.4.12).
+
+      5. The values of some of the supplied attributes conflict with one
+         another and/or other Printer attribute values not being set: if
+         the conflicting attribute in the operation has a single value,
+         return the attribute and the value.  If the attribute in the
+         operation is multi-valued, return only the attribute and those
+         values in a 1setOf that are conflicting with other attributes.
+         Return the 'client-error-conflicting-attributes' status code
+         (see [RFC2911], section 13.1.4.15).
+
+4.2 Set-Job-Attributes Operation
+
+   This OPTIONAL operation allows a client to set the values of the
+   attributes of a Job object.  In the request, the client supplies the
+   set of Job keyword attribute names and values that are to be set.  In
+   the response, the IPP object returns success or rejects the entire
+   request with indications of which attribute or attributes could not
+   be set.
+
+   This operation is almost identical to the Set-Printer-Attributes
+   operation and follows the same rules for validation (see section
+   4.1).  The only differences are that the Set-Job-Attributes operation
+   is directed at a Job object rather than a Printer object, there is no
+   "document-format" operation attribute used when setting a Job object,
+   the operation can add an attribute to the (Job) object, the 'delete-
+   attributes' out-of-band value is permitted to remove an attribute,
+   and the validation is the same as the Job Creation operations
+   (Print-Job, Print-URI, and Create-Job), i.e., depends on the "xxx-
+   supported" Printer Description attributes (see [RFC2911] section
+   3.1).  Using the Set-Printer-Attributes operation, the administrator
+   can set arbitrary 'name' values to those "xxx-supported" Printer
+
+
+
+Hastings, et. al.           Standards Track                    [Page 13]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   attributes, that include the 'name' attribute syntax, if the
+   implementation supports the 'admin-define' out-of-band value for that
+   "xxx-supported" attribute (see section 8.3 and Appendix A).  However,
+   the Set-Job-Attributes cannot be used to add unsupported names to the
+   Job object.
+
+   If a client supplies a job attribute in a Set-Job-Attributes request
+   that the Printer supports, and the job was originally submitted
+   without supplying that attribute, the Printer adds the attribute to
+   the Job object.
+
+   If the client supplies a job attribute with the "out-of-band" value
+   'delete-attribute' (see section 8.2), then the Printer MUST remove
+   the attribute and all of its values from the Job object, if present.
+   The semantic effect of the client supplying the 'delete-attribute'
+   value in a Set-Job-Attributes operation MUST be the same as if the
+   attribute had not been supplied with the Job object in the Job
+   Creation operation, i.e., the Printer applies its default attribute
+   or behavior with lower precedence that the PDL (see the beginning of
+   [RFC2911] section 4.2 and [RFC2911] 3.2.1.1).  Any subsequent query
+   of the Job object using Get-Job-Attributes or Get-Jobs, MUST NOT
+   return any attribute that has been deleted using the 'delete-
+   attribute' out-of-band value.  However, a client can re-establish
+   such a deleted Job attribute with any supported value(s), using a
+   subsequent Set-Job-Attributes operation.
+
+   If the client supplies an attribute in a Set-Job-Attributes request
+   with the 'delete-attribute' value and that attribute is not present
+   on the Job object, the Printer ignores that supplied attribute in the
+   request, does not return the attribute in the Unsupported Attributes
+   group, and returns the 'successful-ok' status code, if there are no
+   other problems with the request.
+
+   The validation of the Set-Job-Attributes request is performed by the
+   Printer as if the job had been submitted originally with the new
+   attribute values (and the deleted attributes removed) and with "ipp-
+   attribute-fidelity" set to 'true', i.e., all modified attributes Job
+   attributes and values MUST be supported in combination with the Job
+   attributes not modified.  If such a Job Creation operation would have
+   been accepted, then the Set-Job-Attributes MUST be accepted.  If such
+   a Job Creation operation would have been rejected, then the Set-Job-
+   Attributes MUST be rejected and the Job MUST be unchanged.  In
+   addition, if any of the supplied attributes are not supported, are
+   not settable, or the values are not supported, the Printer object
+   MUST reject the entire operation; the Printer object MUST NOT
+   partially set some of the supplied attributes.  In other words, after
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 14]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   the operation, all the supplied attributes MUST be set or none of
+   them MUST be set, thus making the Set-Job-Attributes an atomic
+   operation.
+
+   The IPP object MUST accept or reject this operation when the Job's
+   READ-ONLY "job-state" attribute has the values shown in Table 2.  The
+   job's current state MUST affect whether the IPP object accepts or
+   rejects the request.  For example, in the case where the operation
+   creates a request for unavailable resources, the Job transitions to a
+   new state.  Table 2 shows the allowed behaviors in each job state and
+   the transitions.
+
+       Table 2 - Job State Transition Table for the Set-Job-Attributes
+                                  operation
+
+    Current          New             IPP object's response status code
+     "job-state"      "job-state"     and "action":
+
+
+    'pending'        'pending'       'successful-ok'
+
+    'pending'        'pending-held'  'successful-ok' - needed resources
+                                     are not ready
+
+    'pending-held'   'pending-held'  'successful-ok'
+
+    'pending-held'   'pending'       'successful-ok' - needed resources
+                                     are ready
+
+    'processing'     'processing'    'successful-ok'  or 'client-error-
+                                     not-possible' depending on
+                                     implementation, including the
+                                     attributes being set, whether the
+                                     job has started marking media,
+                                     etc.
+
+    'processing-     'processing-    'successful-ok'  or 'client-error-
+    stopped'         stopped'        not-possible' depending on
+                                     implementation, including the
+                                     attributes being set, whether the
+                                     job has started marking media,
+                                     etc.
+
+    'completed'      'completed'     'client-error-not-possible'
+
+    'canceled'       'canceled'      'client-error-not-possible'
+
+    'aborted'        'aborted'       'client-error-not-possible'
+
+
+
+Hastings, et. al.           Standards Track                    [Page 15]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   This operation MUST NOT change the value of attributes not specified
+   in the operation unless the definition of the attribute explicitly
+   specifies such side-effects.  In general, Job attribute definitions
+   that are settable will not define side-effects on other attributes
+   that are settable, only side effects on READ-ONLY attributes, if any.
+
+4.2.1 Settable and READ-ONLY Job Description attributes
+
+   If the Printer supports the "job-message-from-operator" Job
+   Description attribute (see [RFC2911] section 4.3.16) and the client
+   explicitly supplies a new value for the "job-message-from-operator"
+   Job Description attribute in Group 2 in the Set-Job-Attributes
+   request, then the Printer MUST set the "job-message-from-operator"
+   Job Description attribute to this new value.
+
+   If the Printer supports the Set-Job-Attributes operation, then it
+   SHOULD support the setting of:
+
+      all Job Template job ("xxx") attributes
+
+   that the implementation supports (see [RFC2911] section 4.2 and
+   extensions).
+
+   Some Job Description attributes (see [RFC2911] section 4.3) MUST NOT
+   be settable, i.e., they are defined to be READ-ONLY.  An attribute
+   marked as "READ-ONLY" in the Job Description attribute table in
+   Appendix A is such an attribute.  The Job attributes not marked as
+   "READ-ONLY" MAY be settable using the Set-Job-Attributes operation,
+   depending on implementation.
+
+   Note: From now on, all extensions that define new object attributes
+   will indicate whether or not the attributes are READ-ONLY, by
+   including the "READ-ONLY" adjective in their descriptions and/or
+   explicitly stating whether they MAY be settable.
+
+   Access Rights: The authenticated user (see [RFC2911] section 8.3)
+   performing this operation must either be the job owner (as determined
+   in the Job Creation operation) or an operator or administrator of the
+   Printer object (see [RFC2911] Sections 1 and 8.5).
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 16]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+4.2.2 Set-Job-Attributes Request
+
+   The following sets of attributes are part of the Set-Job-Attributes
+   Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in [RFC2911], section 3.1.4.1.
+
+      Target:
+         Either (1) the "printer-uri" (uri) plus "job-id"
+         (integer(1:MAX)) or (2) the "job-uri" (uri) operation
+         attribute(s), which defines the target for this operation as
+         described in [RFC2911], section 3.1.5.
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client, as described in [RFC2911], section 8.3.
+
+   Group 2: Job Attributes
+
+      The client MUST supply a set of Job attributes with one or more
+      values (including explicitly allowed out-of-band values) as
+      defined in [RFC2911], section 4.2, Job Template Attributes ("xxx"
+      attributes), section 4.3, Job Description Attributes, and any
+      attribute extensions supported by the Printer.  The value(s) of
+      each Job attribute supplied in Group 2 replaces the value(s) of
+      the corresponding Job attribute on the target Job object.  For
+      attributes that can have multiple values (1setOf), all values
+      supplied by the client replace all values of the corresponding Job
+      object attribute.
+
+      If the client supplies an "xxx" attribute with the 'delete-
+      attribute' out-of-band value (see section 8.2), the Printer MUST
+      remove the "xxx" attribute from the Job object, if present.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 17]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+4.2.3 Set-Job-Attributes Response
+
+   The IPP object returns the following sets of attributes as part of
+   the Set-Job-Attributes Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+         In addition to the REQUIRED status code returned in every
+         response, the response OPTIONALLY includes a "status-message"
+         (text(255)) and/or a "detailed-status-message" (text(MAX))
+         operation attribute as described in [RFC2911], sections 3.1.6
+         and 13.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes as described in [RFC2911], section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911], section 3.1.7, for details on returning Unsupported
+      Attributes.
+
+      If some of the attributes in the operation fail to validate, the
+      Printer MUST reject the operation, MUST NOT change any Job
+      attributes, and MUST return the indicated status code below.  In
+      this group, the Printer MUST also return all attributes that fail
+      to validate.  The following are the reasons that an attribute
+      fails to validate and the value returns for the attribute, along
+      with the indicated status code and order of detection:
+
+      1. The number of attributes supplied by the client exceeds the
+         maximum number that the Printer supports in a Set-Printer-
+         Attributes request: return the 'client-error-request-entity-
+         too-large' (see [RFC2911], section 13.1.4.9).
+
+      2. The Printer doesn't support the attribute: return the attribute
+         with the 'unsupported' out-of-band attribute value (see
+         [RFC2911], section 3.1.7 and [RFC2910]) and the 'client-error-
+         attributes-or-values-not-supported (see [RFC2911], section
+         13.1.4.12).
+
+      3. The attribute is READ-ONLY (in its definition) or is not-
+         settable in this implementation: return the attribute with the
+         'not-settable' out-of-band attribute value (see section 8.1)
+         and the 'client-error-attributes-not-settable' status code (see
+         section 7.1).
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 18]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      4. The Printer doesn't support the value: if the attribute in the
+         operation has a single value return it.  If the attribute in
+         the operation is multi-valued, return only those values in a
+         1setOf that are not supported.  Return the 'client-error-
+         attributes-or-values-not-supported' status code (see [RFC2911],
+         section 13.1.4.12).
+
+      5. The values of some of the supplied attributes conflict with one
+         another and/or other Job attribute values not being set:  if
+         the conflicting attribute in the operation has a single value,
+         return the attribute and the value.  If the attribute in the
+         operation is multi-valued, return only the attribute and those
+         values in a 1setOf that are conflicting with other attributes.
+         Return the 'client-error-conflicting-attributes' status code
+         (see [RFC2911],y section 13.1.4.15).
+
+4.3 Get-Printer-Supported-Values Operation
+
+   This OPTIONAL operation allows a client to request the values that
+   the Printer allows in the Set-Printer-Attributes operation for "xxx-
+   supported" attributes.  If the Printer supports the Set-Printer-
+   Attributes operation AND some of its "xxx-supported" Printer
+   attributes are settable, then the Printer MUST also support this
+   operation.
+
+   The Printer MUST return in the Get-Printer-Supported-Values response,
+   those, and only those, "xxx-supported" Printer attributes that it
+   supports setting with the Set-Printer-Attributes operation.
+   Furthermore, if a client requests the value of an attribute that is
+   not settable or is not supported (as in the Get-Printer-Attributes
+   response), the Unsupported Attributes Group of the response NEED NOT
+   contain the "requested-attributes" operation attribute with any such
+   requested (attribute keyword) values.
+
+   This operation has identical request/response attributes to the Get-
+   Printer-Attributes operation in IPP/1.1 [RFC2911].  The operation
+   also behaves identically to the Get-Printer-Attributes operation in
+   IPP/1.1 [RFC2911], with the following exceptions:
+
+   1. The Get-Printer-Supported-Values operation supports only "xxx-
+      supported" attributes.
+
+   2. The Get-Printer-Attributes operation returns the few "xxx-
+      supported" attributes that are defined to be single valued, such
+      as "page-ranges-supported" (boolean) or "pdl-override-supported"
+      (type2 keyword), as single values, while Get-Printer-Supported-
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 19]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Values returns the possible values that can be set as a 1setOf of
+      the same attribute syntax type (See Appendix B: Attributes
+      returned from Get-Printer-Supported-Values).
+
+   3. The Get-Printer-Attributes operation returns the current values of
+      requested attributes, while the Get-Printer-Supported-Values
+      operation returns the values that are inherently supported by the
+      implementation code, i.e., the values that an administrative
+      client can set in a Set-Printer-Attributes request.
+
+   4. The Get-Printer-Attributes operation returns the current values of
+      requested "xxx-supported" attributes that the Printer is
+      configured to accept in Job Creation operations, including
+      additional values defined by the administrator, while the Get-
+      Printer-Supported-Values operation returns only the values of
+      "xxx-supported" attributes that are inherently supported by the
+      implementation and does not return any additional values defined
+      by the administrator, where the implementation supports the
+      'admin-define' out-of-band value.
+
+   5. The Get-Printer-Attributes never returns the 'admin-define' out-
+      of-band attribute value, while the Get-Printer-Supported-
+      Attributes operation does, if the implementation allows the
+      administrator to define name values by setting that "xxx-
+      supported" attribute with any 'name' value(s).
+
+   6. The Get-Printer-Attributes operation only requires end-user access
+      rights, while the Get-Printer-Supported-Values requires
+      administrator access rights.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an administrator of the Printer
+   object (see [RFC2911], Sections 1 and 8.5).
+
+4.3.1 Definition of the usage of the 'admin-define' out-of-band
+      attribute value
+
+   If the Set-Printer-Attributes operation allows the System
+   Administrator to define arbitrary 'name' values for an "xxx-
+   supported" attribute, then the Get-Printer-Supported-Values operation
+   MUST return the 'admin-define' out-of-band attribute value (see
+   section 8.3) as one of the values of the "xxx-supported" attribute.
+   In other words, the 'admin-define' out-of-band attribute value
+   indicates that the Printer implementation supports clients setting
+   arbitrary 'name' attribute syntax values for that "xxx-supported"
+   attribute using the Set-Printer-Attributes operation, as long as the
+   attribute is defined with the 'name' attribute syntax.
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 20]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   For example, if the Get-Printer-Supported-Values operation returns
+   several keywords as the value of the "media-supported" attribute,
+   then the Set-Printer-Attributes operation MUST accept any of these
+   keywords as values for the "media-supported" attribute.  If the Get-
+   Printer-Supported-Values operation returns an 'admin-define' out-of-
+   band attribute value as one of the values of the "media-supported"
+   attribute, then the Set-Printer-Attributes operation MUST accept any
+   value whose attribute syntax is 'name', as a value for the "media-
+   supported" attribute (provided that the user is properly
+   authenticated to use the Set-Printer-Attributes operation, e.g., has
+   administrative access rights).
+
+   The Get-Printer-Supported-Values MAY return the 'admin-define' out-
+   of-band attribute value for any IPP/1.1 or extension Job Template
+   attribute if the implementation supports allowing the System
+   Administrator to add values to the "xxx-supported" attribute using
+   the Set-Printer-Attributes operation.  In this case, the Printer MUST
+   accept any 'name' value of the correct attribute syntax in a Set-
+   Printer-Attributes operation that is setting that attribute.  For
+   "xxx-supported" attributes that are defined with a choice of
+   attribute syntaxes, such as 'keyword | name', it is the 'name'
+   attribute syntax that the System Administrator can use to add new
+   values, not the 'keyword' attribute syntax.  For IPP/1.1, this
+   requirement includes the following Job Template attributes:
+
+      media-supported
+      job-hold-until-supported
+      job-sheets-supported
+
+   Implementations that support additional Job Template attributes that
+   include the 'name' attribute syntax, MAY use the 'admin-define' out-
+   of-band value with them.
+
+   If the 'admin-define' out-of-band attribute value is not one of the
+   values of an "xxx-supported" attribute returned in a Get-Printer-
+   Supported-Values response, then the Printer MUST NOT allow the Set-
+   Printer-Attributes operation for that attribute to contain a value
+   that is not one of the explicit 'keyword' or 'name' values returned
+   in a Get-Printer-Supported-Values response.
+
+   See Appendix B: Attributes returned from Get-Printer-Supported-Values
+   for a full list of values returned by this operation.
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 21]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+5 New Operation attributes
+
+   This section defines new operation attributes for use with the
+   IPP/1.1 operations indicated.  As new operations are defined, they
+   will also indicate explicitly whether these operation attributes are
+   defined for use with them.
+
+5.1 printer-message-from-operator (text(127))
+
+   The Printer SHOULD support this Operation attribute in following
+   operations if it supports the corresponding "printer-message-from-
+   operator" Printer Description attribute.
+
+      Pause-Printer
+      Resume-Printer
+      Purge-Jobs
+
+   The client OPTIONALLY supplies this Operation attribute in the above
+   operations.  The value of this attribute is a message from the
+   operator about the Printer object on which the operator is performing
+   the operation.  If this operation attribute is supported, the Printer
+   copies the value to its "printer-message-from-operator" Printer
+   Description attribute (see [RFC2911], section 4.4.25), even if this
+   Operation attribute is a zero-length text value or consists solely of
+   white space.
+
+   If the Printer supports this operation attribute, it MUST support
+   both a zero-length text value and the 'no-value' out-of-band value
+   (see [RFC2911] section 4.1) to indicate that the operator has sent no
+   message.  In this case, the Printer sets the value of the "printer-
+   message-from-operator" to the zero-length value or 'no-value' out-
+   of-band value, respectively.  If the client queries the "printer-
+   message-from-operator" Printer attribute, the Printer returns the
+   attribute with the zero-length value or the 'no-value' value,
+   respectively.
+
+   In addition, the Printer automatically copies:
+
+   1. the value of its "printer-up-time" attribute (see [RFC2911],
+      section 4.4.29) to its "printer-message-time" attribute,
+
+   2. the value of its printer-current-time" (dateTime) attribute (see
+      [RFC2911], section 4.4.30) to its "printer-message-date-time"
+      attribute, if supported.
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 22]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   If the client omits this operation attribute, the Printer does not
+   change the value of its "printer-message-from-operator", "printer-
+   message-time" and "printer-message-date-time" Printer Description
+   attributes.
+
+   The "printer-message-from-operator" operation attribute MUST NOT be
+   supported as an operation attribute for the Set-Printer-Attributes
+   operation.  If the operator wants to set the Printer's "printer-
+   message-from-operator" Printer Description attribute when issuing the
+   Set-Printer-Attributes operation, the client supplies the "printer-
+   message-from-operator" explicitly with its new value as one of the
+   Printer Description attributes in Group 2 in the request; the Printer
+   also updates its "printer-message-time" and "printer-message-date-
+   time" Printer Description attributes.  If the client does not
+   explicitly supply the "printer-message-from-operator" with its new
+   value in the Set-Printer-Attributes request, the Printer leaves the
+   value of the Printer's "printer-message-from-operator" Printer
+   Description attribute unchanged.
+
+5.2 job-message-from-operator (text(127))
+
+   The Printer SHOULD support this Operation attribute in following
+   operations if it supports the corresponding "job-message-from-
+   operator" Job Description attribute.
+
+      Cancel-Job
+      Hold-Job
+      Release-Job
+      Restart-Job
+
+   The client OPTIONALLY supplies this attribute in the above
+   operations.  The value of this attribute is a message from the
+   operator about the Job object on which the operator has just
+   performed an operation.  If supported, the Printer copies the value
+   to the Job's "job-message-from-operator" Job Description attribute
+   (see [RFC2911], section 4.3.16) (even if this Operation attribute is
+   a zero-length text value or consists solely of white space).
+
+   If the Printer supports this operation attribute, it MUST support
+   both a zero-length text value and the 'no-value' out-of-band value
+   (see [RFC2911], section 4.1), to indicate that the operator has sent
+   no message.  In this case, the Printer sets the value of the "job-
+   message-from-operator" to the zero-length value or 'no-value' out-
+   of-band value, respectively.  If the client queries the "job-
+   message-from-operator" Job attribute, the IPP object returns the
+   attribute with the zero-length value or the 'no-value' value,
+   respectively.
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 23]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   If the client omits this attribute, the Printer does not change the
+   value of its "job-message-from-operator" Job Description attribute.
+
+   Note: There are no corresponding 'job-message-time" and "job-
+   message-date-time" Job Description attributes, since the usual
+   lifetime of a job is limited.
+
+   The "job-message-from-operator" operation attribute MUST NOT be
+   supported as an operation attribute for the Set-Job-Attributes
+   operation.  If the operator wants to set the Job's "job-message-
+   from-operator" Job Description attribute when issuing the Set-Job-
+   Attributes operation, the client MUST supply the "job-message-from-
+   operator" with its new value as one of the Job Description attributes
+   in Group 2 in the request.  Otherwise, the Printer leaves the value
+   of the Job's "job-message-from-operator" Job Description attribute
+   unchanged by not explicitly setting the attribute.  If the client
+   does not explicitly supply the "job-message-from-operator" with its
+   new value in the Set-Job-Attributes request, the Printer leaves the
+   value of the Job's "job-message-from-operator" Job Description
+   attribute unchanged.
+
+6 New Printer Description Attributes
+
+   The following new Printer Description attributes are needed to
+   support the new operations defined in this document.
+
+6.1 printer-settable-attributes-supported (1setOf type2 keyword)
+
+   This REQUIRED READ-ONLY Printer Description attribute identifies the
+   Printer object attributes that are settable in this implementation,
+   i.e., that are settable using the Set-Printer-Attributes operations
+   (see section 4.1).  This attribute MUST be supported if the Set-
+   Printer-Attributes operations is supported.  The Printer MUST reject
+   attempts to set any Printer attributes that are not one of the values
+   of this attribute, returning the 'client-error-attributes-not-
+   settable' status code (see section 7.1).  The value of this attribute
+   MAY depend on the value of the "document-format" operation attribute
+   supplied in the Get-Printer-Attributes operation (see [RFC2911],
+   section 3.2.5.1).
+
+   Standard keyword values are:
+
+      'none': There are no settable Printer attributes.
+      'xxx':  Where 'xxx' is any of the keyword attribute names allowed
+        by section 4.1.1.
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 24]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+6.2 job-settable-attributes-supported (1setOf type2 keyword)
+
+   This REQUIRED READ-ONLY Printer Description attribute identifies the
+   Job object attributes that are settable in this implementation, i.e.,
+   that are settable using the Set-Job-Attributes operation (see section
+   4.2).  This attribute MUST be supported if the Set-Job-Attributes
+   operations are supported.  The Printer MUST reject attempts to set
+   any Job attributes that are not one of the values of this attribute,
+   returning the 'client-error-attributes-not-settable' status code (see
+   section 7.1).
+
+   Standard keyword values are:
+
+      'none': There are no settable Job attributes.
+      'xxx':  Where 'xxx' is any of the keyword attribute names allowed
+        by section 4.2.1.
+
+6.3 document-format-varying-attributes (1setOf type2 keyword)
+
+   This OPTIONAL READ-ONLY Printer Description attribute contains a set
+   of attribute name keywords.  This attribute SHOULD be supported by a
+   Printer object if the Printer object has Printer attributes whose
+   value vary depending on document format (see [RFC2911], Get-Printer-
+   Attributes operation).  This attribute specifies which attribute
+   values can vary by document-format.  If an attribute's name, "xxx",
+   is a member of this attribute and the value of attribute "xxx" is
+   changed with the Set-Printer-Attributes operation that included the
+   "document-format" operation attribute, then the Printer MUST change
+   the value for the specified document format and no other document
+   formats (see section 4.1.2).  If an attribute's name, "xxx", is not a
+   member of this attribute and the value of attribute "xxx" is changed
+   with the Set-Printer-Attributes operation, then the attribute is
+   changed for all document formats (whether or not the client supplied
+   the "document-format" operation attribute).
+
+6.4 printer-message-time (integer(MIN:MAX))
+
+   This OPTIONAL READ-ONLY Printer Description attribute contains the
+   time that the Printer's "printer-message-from-operator" was changed
+   by the operator using any operation where the client supplied the
+   "printer-message-from-operator" operation attribute (see section 5.1)
+   or was explicitly set using the Set-Printer-Attributes operation (see
+   section 4.1).  This attribute allows the users to know when the
+   "printer-message-from-operator" Printer Description attribute was
+   last set.
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 25]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   The Printer sets the value of this attribute by copying the value of
+   the Printer's "printer-up-time" attribute (see [RFC2911], section
+   4.3.14).  If the Printer resets its "printer-up-time" attribute to 1
+   on power-up, then it MUST change the value of the "printer-message-
+   time" to 0 or a negative number as specified in [RFC2911], section
+   4.3.14.
+
+   Note: This attribute helps users better understand the context for
+   the "printer-message-from-operator" message.
+
+6.5 printer-message-date-time (dateTime)
+
+   This OPTIONAL READ-ONLY Printer Description attribute contains the
+   date and time that the Printer's "printer-message-from-operator" was
+   changed by the operator, using any operation where the client
+   supplied the "printer-message-from-operator" operation attribute (see
+   section 5.1) or was explicitly set using the Set-Printer-Attributes
+   operation (see section 4.1).  This attribute allows the users to know
+   when the "printer-message-from-operator" Printer Description
+   attribute was last set.
+
+   This attribute MUST be supported if the Printer supports both the
+   "printer-message-time" and the "printer-current-time" (dateTime)
+   attributes (see [RFC2911], section 4.4.30).
+
+   Note: This attribute helps users better understand the context for
+   the "printer-message-from-operator" message.
+
+6.6 printer-xri-supported (1setOf collection)
+
+   This OPTIONAL Printer Description attribute is a multi-valued
+   attribute where each value has the 'collection' attribute syntax (see
+   [RFC3382]), containing member attributes with the same semantics as
+   the following IPP/1.1 READ-ONLY Printer Description attributes,
+   except for cardinality:
+
+      printer-uri-supported (1setOf uri)
+          - see [RFC2911], section 4.4.1
+      uri-authentication-supported (1setOf type2 keyword)
+          - see [RFC2911], section 4.4.2.
+      uri-security-supported (1setOf type2 keyword)
+          - see [RFC2911], section 4.4.3.
+
+   When setting the "printer-xri-supported" attribute with a Set-
+   Printer-Attributes request, the Printer MUST also set these three
+   IPP/1.1 READ-ONLY Printer Description attributes as a defined side
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 26]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   effect.  Thus, this collection attribute provides the means to set
+   these three IPP/1.1 READ-ONLY attributes atomically so that they are
+   never left in a partially inconsistent state.
+
+   An IPP Printer MUST NOT provide any other way, using IPP, to set
+   these three IPP/1.1 READ-ONLY Printer Description attributes, since
+   they are READ-ONLY and MUST have consistent values at all times.
+   Note:  The "printer-xri-supported" (1setOf collection) attribute can
+   be put into a directory schema that requires a single text string
+   value, such as could be used with SLPv2 [RFC2608], [RFC2609] or
+   LDAPv3 [RFC2251], [RFC2252], [RFC2926], by using suitable delimiting
+   characters to separate member attributes of the collection and/or
+   terminating collection values.
+
+   The member attributes of the "printer-xri-supported" (1setOf
+   collection) are given in Table 3.
+
+      Table 3 - Member attributes of "printer-xri-supported" (1setOf
+                                collection)
+
+      Member attribute                             client    Printer
+                                                   MUST      MUST
+                                                   supply    support
+
+      xri-uri (uri)                                yes       yes
+
+      xri-authentication (type2 keyword)           yes       yes
+
+      xri-security (type2 keyword)                 yes       yes
+
+   Other than the uniqueness and the cardinality requirements, the
+   semantics of these three member attributes is given in [RFC2911]
+   sections 4.4.1, 4.4.2, and 4.4.3, respectively.
+
+   A client can query the current values using the Get-Printer-
+   Attributes operation by supplying either:
+
+   1. the three IPP/1.1 attribute names: "printer-uri-supported", "uri-
+      authentication-supported", "uri-security-supported" and getting
+      back the parallel values OR
+
+   2. the single attribute name: "printer-xri-supported" and getting
+      back the 1setOf collection which contains the same information
+      semantically, but in a different form.
+
+   A client can query what member attribute values can be set by
+   supplying the three attribute names: "xri-uri-scheme-supported",
+   "xri-authentication-supported", and "xri-security-supported" in a
+
+
+
+Hastings, et. al.           Standards Track                    [Page 27]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   Get-Printer-Supported-Values request and getting back the uriScheme
+   and type2 keyword values that can be set.  Since the "printer-xri-
+   supported", "uri-authentication-supported", and "uri-security-
+   supported" attributes are READ-ONLY, they are not queriable with the
+   Get-Printer-Supported-Values operation (see section 4.3).  See Table
+   16.
+
+   For example:
+
+      "printer-xri-supported =
+          {  "xri-uri" = ipp://abc.com/p1
+             "xri-authentication" = basic
+             "xri-security" = tls
+          },
+          {  "xri-uri" = ipp://abc.com/p2
+             "xri-authentication" = digest
+             "xri-security" = tls
+          },
+          {  "xri-uri" = ipp://abc.com/p3
+             "xri-authentication" = none
+             "xri-security" = none
+          }
+
+   would cause the Printer to set the three corresponding IPP/1.1 READ-
+   ONLY attributes, each with three parallel values as follows:
+
+      "printer-uri-supported" = { ipp://abc.com/p1, ipp://abc.com/p2,
+                                  ipp://abc.com/p3 }
+      "uri-authentication-supported" = { basic, digest, none }
+      "uri-security-supported" = { tls, tls, none }
+
+6.7 xri-uri-scheme-supported (1setOf uriScheme)
+
+   This OPTIONAL READ-ONLY Printer Description attribute identifies the
+   URI schemes that the implementation supports for use in the
+   "printer-uri-supported" (1setOf uri) Printer Description attribute
+   (see [RFC2911] section 4.4.1) and the "xri-uri" member attribute of
+   the "printer-xri-supported" (1setOf collection) Printer Description
+   attribute (see section 6.6).
+
+   A Printer MUST support this attribute if it supports the setting of
+   the "printer-xri-supported" (1setOf collection) with the Set-
+   Printer-Attributes operation.
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 28]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+6.8 xri-authentication-supported (1setOf type2 keyword)
+
+   This OPTIONAL READ-ONLY Printer Description attribute identifies the
+   Client Authentication mechanisms that the implementation supports for
+   use in the "uri-authentication-supported" (1setOf type2 keyword)
+   Printer Description attribute (see [RFC2911], section 4.4.2) and the
+   "xri-authentication" member attribute of the "printer-xri-supported"
+   (1setOf collection) Printer Description attribute (see section 6.6).
+
+   A Printer MUST support this attribute if it supports setting the
+   "printer-xri-supported" (1setOf collection) with the Set-Printer-
+   Attributes operation.
+
+6.9 xri-security-supported (1setOf type2 keyword)
+
+   This OPTIONAL READ-ONLY Printer Description attribute identifies the
+   URI schemes that the implementation supports for use in the "uri-
+   security-supported" (1setOf type2 keyword) Printer Description
+   attribute (see [RFC2911], section 4.4.3) and the "xri-security"
+   member attribute of the "printer-xri-supported" (1setOf collection)
+   Printer Description attribute (see section 6.6).
+
+   A Printer MUST support this attribute if it supports setting the
+   "printer-xri-supported" (1setOf collection) with the Set-Printer-
+   Attributes operation.
+
+7 Additional status codes
+
+   This section defines new status codes used by the operations defined
+   in this document.
+
+7.1 client-error-attributes-not-settable (0x0413)
+
+   The Set-Printer-Attributes or Set-Job-Attributes operation failed
+   because one or more of the specified attributes cannot be set, either
+   because the attribute is defined to be READ-ONLY or the attribute is
+   not settable in this implementation (see sections 4.1.3 and 4.2.3).
+   The Printer MUST return this error code and the attribute keyword
+   name(s) and the 'not-settable' out-of-band value (see section 8.1) in
+   the Unsupported Attributes Group (see [RFC2911], section 3.1.7) for
+   all of the attributes that could not be set.  When the Printer
+   returns this status, it MUST NOT change any of the attributes
+   supplied in the operation.
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 29]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+8 Additional out-of-band values
+
+   This section defines additional out-of-band values.  As with all
+   out-of-band values, a client or a Printer MUST NOT use an out-of-band
+   value unless the definition of the attribute in an operation request
+   and/or response explicitly allows such usage.  See the beginning of
+   [RFC2911], section 4.1.
+
+8.1 'not-settable' out-of-band value
+
+   The 'not-settable' out-of-band attribute value is returned by the IPP
+   Printer in the Unsupported Attributes group of a response to indicate
+   that the attribute supplied by the client in the request is READ-ONLY
+   by definition or is not settable in this implementation.
+
+   The 'not-settable' out-of-band attribute value is defined for use
+   with the Set-Job-Attributes and Set-Printer-Attributes responses
+   only.  If a future additional "set" operation allows the 'not-
+   settable' out-of-band value, its definition document MUST indicate
+   such use explicitly, including with which attributes.
+
+   An IPP object MUST support the 'not-settable' out-of-band value in a
+   Set-Job-Attributes or Set-Printer-Attributes request if it supports
+   those operations.  A client MUST NOT supply the 'not-settable' out-
+   of-band value in any request.  An IPP object MUST NOT support the
+   'not-settable' out-of-band value in other operations, unless the
+   operations' definition document explicitly defines such usage.  If a
+   Printer receives this out-of-band value in any operation request, the
+   Printer MUST either (1) reject the entire request and return the
+   'client-error-bad-request' status code or (2) ignore the attribute
+   and return it with the 'unsupported' out-of-band value.
+
+   See sections 4.1.3 and 4.2.3 in this document for an example
+   definition of the usage of the 'not-settable' out-of-band value in
+   the Set-Printer-Attributes and Set-Job-Attributes responses.
+
+8.1.1 Encoding of the 'not-settable' out-of-band attribute value
+
+   The encoding of the 'not-settable' out-of-band value is 0x15 (see
+   [RFC2910]).  The value-length MUST be 0 and the value empty.
+
+8.2 'delete-attribute' out-of-band value
+
+   The 'delete-attribute' out-of-band attribute value is supplied by the
+   client in a request to indicate that the Printer is to remove the
+   supplied attribute and all of its values from the target object, if
+   present.
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 30]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   The 'delete-attribute' out-of-band attribute value is defined for use
+   with the Set-Job-Attributes request only.  If a future additional
+   "set" operation allows the 'delete-attribute' out-of-band value, its
+   definition document MUST indicate such use explicitly, including with
+   which attributes.
+
+   An IPP Printer MUST support the 'delete-attribute' out-of-band value
+   if it supports the Set-Job-Attributes operation.  A client MUST NOT
+   supply, and an IPP object MUST NOT support, the 'delete-attribute'
+   out-of-band value in other operations, unless the operations'
+   definition document explicitly defines such usage.  For example, the
+   'delete-attribute' out-of-band value MUST NOT be used in the Set-
+   Printer-Attributes operation, where the absence of an attribute from
+   an IPP object indicates that the attribute is not supported.  If a
+   Printer receives this out-of-band value in other operation requests,
+   the Printer MUST either (1) reject the entire request and return the
+   'client-error-bad-request' status code or (2) ignore the attribute
+   and return it with the 'unsupported' out-of-band value.
+
+   See section 4.2 in this document for the definition of the usage of
+   the 'delete-attribute' out-of-band value in the Set-Job-Attributes
+   request.
+
+8.2.1 Encoding of the 'delete-attribute' out-of-band value
+
+   The encoding of the 'delete-attribute' out-of-band value is 0x16 (see
+   [RFC2910]).  The value-length MUST be 0 and the value empty.
+
+8.3 'admin-define' out-of-band attribute value
+
+   Section 4.3 defines the Get-Printer-Supported-Values response to
+   contain the values of an "xxx-supported" attribute that are supported
+   by the implementation before any additional values are defined by the
+   administrator.  The 'admin-define' out-of-band attribute value is
+   returned as an additional value of an "xxx-supported" attribute in a
+   Get-Printer-Supported-Values response to indicate that the
+   implementation supports allowing an administrator to define
+   additional arbitrary 'name' values for that "xxx-supported"
+   attribute.
+
+   For example, if the "media-supported" (1setOf (type3 keyword | name))
+   attribute contains this value, then the Printer MUST permit an
+   administrator to add new media names to the Printer's "media-
+   supported" attribute.  In order for an administrator to add new
+   values to a Printer's "xxx-supported" attribute, the client supplies
+   the existing and new values in a Set-Printer-Attributes request for
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 31]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   that attribute.  The client MUST supply any such administratively
+   defined values in the Set-Printer-Attributes request, using the
+   'name' attribute syntax.
+
+   The 'admin-define' out-of-band attribute value is defined for use
+   with the Get-Printer-Supported-Values response only.  A Printer MUST
+   NOT return the 'admin-define' out-of-band value in a Get-Printer-
+   Attributes response, since such a response indicates what an end-user
+   client can supply in a Job Creation operation.  If a future
+   additional "get" operation allows the 'admin-define' out-of-band
+   value, its definition document MUST indicate such use explicitly,
+   including with which attributes.
+
+   An IPP Printer MUST support the 'admin-define' out-of-band value, if
+   it supports a client setting arbitrary 'name' values of an "xxx-
+   supported" Printer attribute using the Set-Printer-Attributes
+   operation.  A client MUST NOT supply the 'admin-define' out-of-band
+   value in any request.  An IPP object MUST NOT support the 'admin-
+   define' out-of-band value in other operations, unless the operations'
+   definition document explicitly defines such usage.  If a Printer
+   receives this out-of-band value in any operation request, the Printer
+   MUST either (1) reject the entire request and return the 'client-
+   error-bad-request' status code or (2) ignore the attribute and return
+   it with the 'unsupported' out-of-band value.
+
+   This document defines that the 'admin-define' out-of-band value MUST
+   be used only with "xxx-supported" attributes that are defined to
+   include the 'name' attribute syntax.  This out-of-band value is not
+   intended to be used with "xxx-supported" attributes of other
+   attribute syntaxes, such as 'uri', even though the administrator
+   defines arbitrary values for such attributes.  If other documents
+   extend the use of the 'admin-define' out-of-band value to other
+   attribute syntaxes, such a document MUST define such use explicitly,
+   including with which attributes.
+
+   See section 4.3 in this document for an example definition of the
+   usage of the 'admin-define' out-of-band attribute value in any "xxx-
+   supported" attribute returned in a Get-Printer-Supported-Values
+   response that is defined to include the 'name' attribute syntax.
+
+8.3.1 Encoding of the 'admin-define' out-of-band attribute value
+
+   The encoding of the 'admin-define' out-of-band attribute value is
+   0x17 (see [RFC2910]).  The value-length MUST be 0 and the value
+   empty.
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 32]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+9 New Values for Existing Printer Description Attributes
+
+   This section contains those attributes for which additional values
+   are added.
+
+9.1 operations-supported (1setOf type2 enum)
+
+   The following "operation-id" values are added in order to support the
+   new operations defined in this document:
+
+                Table 4 - Operation-id assignments
+
+                Value        Operation Name
+
+                0x0013       Set-Printer-Attributes
+
+                0x0014       Set-Job-Attributes
+
+                0x0015       Get-Printer-Supported-Values
+
+10 Conformance Requirements
+
+   This section specifies the conformance requirements for clients and
+   IPP objects.
+
+   Both the Set-Job-Attributes and the Set-Printer-Attributes operations
+   defined in the document are OPTIONAL for an IPP object to support.
+   Either one MAY be supported without the other or both MAY be
+   supported.  However, if the Set-Printer-Attributes operation is
+   supported, then the Get-Printer-Supported-Values operation MUST be
+   supported if any "xxx-supported" attributes are settable.  Otherwise,
+   the Get-Printer-Supported-Values operation is OPTIONAL for an IPP
+   Printer to support.
+
+   If the Set-Printer-Attributes operation is supported, then the
+   Printer MUST support the following additional items:
+
+      1. the Get-Printer-Supported-Values operation (see section 5), if
+         any "xxx-supported" attributes are settable.
+
+      2. the "printer-settable-attributes-supported" Printer Description
+         attribute (see section 6.1).
+
+      3. the 'not-settable' out-of-band value in responses (see section
+         8.1).
+
+      4. the 'client-error-not-settable' status code (see section 7.1).
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 33]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      5. if the "printer-message-from-operator" Printer Description
+         attribute is supported (see [RFC2911], section 4.4.25), then it
+         MUST be settable.
+
+      6. the Get-Printer-Supported-Values operation (see section 4.3),
+         if any "xxx-supported" attributes are settable.
+
+      7. If a client can set a value with the 'name' attribute syntax
+         for one or more "xxx-supported" attributes, then the 'admin-
+         define' out-of-band attribute value (see section 8.3) MUST be
+         supported in the Get-Printer-Supported-Values response for each
+         such settable attribute (see section 4.3)
+
+   If the Set-Job-Attributes operation is supported, then the Printer
+   MUST support the following additional items:
+
+      1. the "job-settable-attributes-supported" Printer Description
+         attribute (see section 6.2).
+
+      2. the 'not-settable' out-of-band value in responses (see section
+         8.1).
+
+      3. the 'delete-attribute' out-of-band value in requests (see
+         section 8.2).
+
+      4. the 'client-error-not-settable' status code (see section 7.1).
+
+      5. if the "job-message-from-operator" Printer Description
+         attribute is supported (see [RFC2911], 4.3.16), then it MUST be
+         settable.
+
+   It is OPTIONAL for the Printer object to support the "printer-
+   message-time" (integer) and "printer-message-date-time" (dateTime)
+   Printer Description attributes.  If both the "printer-message-time"
+   (integer) and the "printer-current-time" (dateTime) (see [RFC2911],
+   section 4.4.30) attributes are supported, then the "printer-message-
+   date-time" (dateTime) Printer Description attribute MUST be
+   supported.
+
+   As with all out-of-band values, a client or a Printer MUST NOT use an
+   out-of-band value, unless the definition document for the attribute
+   in an operation request and/or response explicitly allows such usage.
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 34]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+11 IANA Considerations
+
+   This section contains registration information for IANA to add to the
+   various IPP Registries according to the procedures defined in RFC
+   2911 [RFC2911], section 6.  The resulting registrations will be
+   published in the http://www.iana.org/assignments/ipp-registrations
+   registry.
+
+11.1 Operation Registrations
+
+   The following table lists all of the operations defined in this
+   document.  These are to be registered according to the procedures
+   defined in RFC 2911 [RFC2911], section 6.4.
+
+   Operations:                                       Ref.      Section:
+   Set-Printer-Attributes                            RFC 3380       4.1
+   Set-Job-Attributes                                RFC 3380       4.2
+   Get-Printer-Supported-Values                      RFC 3380       4.3
+
+11.2 Additional Enum Attribute Value Registrations for the
+     "operations-supported" Printer Attribute
+
+   The following table lists all the new enum attribute values defined
+   in this document as additional type2 enum values for use with the
+   "operations-supported" Printer Description attribute.  These are to
+   be registered according to the procedures defined in RFC 2911 [RFC
+   2911], section 6.1.
+
+   Enum Attribute Values:               Value        Ref.      Section:
+   Set-Printer-Attributes               0x0013       RFC 3380       4
+   Set-Job-Attributes                   0x0014       RFC 3380       4
+   Get-Printer-Supported-Values         0x0015       RFC 3380       4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 35]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+11.3 Keyword attribute value registrations
+
+   The following table lists all of the attributes defined in this
+   standard which have keywords values defined:
+
+   printer-settable-attributes-supported (1setOf type2 keyword)
+                                                     RFC 3380       6.1
+     none                                            RFC 3380       6.1
+     <Any other Printer attribute keyword name>
+   job-settable-attributes-supported (1setOf type2 keyword)
+                                                     RFC 3380       6.2
+     none                                            RFC 3380       6.2
+     <Any other Job attribute keyword name>
+   document-format-varying-attributes (1setOf type2 keyword)
+                                                     RFC 3380       6.3
+     none
+     <Any Printer attribute keyword name>
+   xri-security-supported (1setOf type2 keyword)     RFC 3380       6.9
+     none                                            RFC 2911     4.4.3
+     ssl3                                            RFC 2911     4.4.3
+     tls'                                            RFC 2911     4.4.3
+   xri-authentication-supported (1setOf type2 keyword)
+     none                                            RFC 2911     4.4.2
+     requesting-user-name                            RFC 2911     4.4.2
+     basic                                           RFC 2911     4.4.2
+     digest                                          RFC 2911     4.4.2
+     certificate                                     RFC 2911     4.4.2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 36]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+11.4 Attribute Registrations
+
+   The following table lists all of the attributes defined in this
+   document.  These are to be registered according to the procedures in
+   RFC 2911 [RFC2911], section 6.2.
+
+   Operation attributes:                             Ref.      Section:
+   printer-message-from-operator (text(127))         RFC 3380       5.1
+   job-message-from-operator (text(127))             RFC 3380       5.2
+
+   Printer Description attributes:                   Ref.       Section:
+   printer-settable-attributes-supported (1setOf type2 keyword)
+                                                     RFC 3380       6.1
+   job-settable-attributes-supported (1setOf type2 keyword)
+                                                     RFC 3380       6.2
+   document-format-varying-attributes (1setOf type2 keyword)
+                                                     RFC 3380       6.3
+   printer-message-time (integer(MIN:MAX))           RFC 3380       6.4
+   printer-message-date-time (dateTime)              RFC 3380       6.5
+   printer-xri-supported (1setOf collection)         RFC 3380       6.6
+     xri-uri (uri)                                   RFC 3380       6.6
+     xri-authentication (type2 keyword)              RFC 3380       6.6
+     xri-security (type2 keyword)                    RFC 3380       6.6
+   xri-uri-scheme-supported (1setOf uriScheme)       RFC 3380       6.7
+   xri-authentication-supported (1setOf type2 keyword)              6.8
+   xri-security-supported (1setOf type2 keyword)     RFC 3380       6.9
+
+11.5 Status code Registrations
+
+   The following table lists the status code defined in this document.
+   This is to be registered according to the procedures in RFC 2911
+   [RFC2911], section 6.6.
+
+   Status codes:                                     Ref.      Section:
+   client-error-attributes-not-settable (0x0413)     RFC 3380       7.1
+
+11.6 Out-of-band Attribute Value Registrations
+
+   The following table lists all of the out-of-band attribute values
+   defined in this document.  These are to be registered according to
+   the procedures in RFC 2911 [RFC2911] section 6.7.
+
+   Value:    Out-of-band Attribute value name:       Ref.      Section:
+   0x15      not-settable                            RFC 3380       8.1
+   0x16      delete-attribute                        RFC 3380       8.2
+   0x17      admin-define                            RFC 3380       8.3
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 37]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+12 Internationalization Considerations
+
+   This document has the same localization considerations as [RFC2911].
+
+13 Security Considerations
+
+   The IPP Model and Semantics document ([RFC2911], section 8) discusses
+   high level security requirements (Client Authentication, Server
+   Authentication and Operation Privacy).  Client Authentication is the
+   mechanism by which the client proves its identity to the server in a
+   secure manner.  Server Authentication is the mechanism by which the
+   server proves its identity to the client in a secure manner.
+   Operation Privacy is defined as a mechanism for protecting operations
+   from eavesdropping.
+
+   In addition, the introduction of the Set-Printer-Attributes and Set-
+   Job-Attributes operations creates another security threat, since the
+   client is able to modify the Printer and Job attributes stored in the
+   Printer.  Such modifications could lead to denial of service.
+
+   A malicious user could alter the policy established by the system
+   administrator and stored in the Printer attributes.  Such alteration
+   could either grant access to more resources or deny access to
+   resources that the system administrator has established.  For
+   example, the malicious user could remove all of the document-format
+   values from the "document-format-supported" Printer attribute so that
+   the Printer would refuse to accept all jobs.
+
+   The general remedy for such malicious user actions against Printer
+   attributes is to have strong Client Authentication coupled with
+   Printer access control, to limit the users who have System
+   Administrator or Operator privileges.
+
+   A malicious user could modify the Job Template attributes of another
+   user's Job, such as the "copies" attribute.  For example, setting the
+   number of copies to a large number.
+
+   The general remedy for such malicious user actions against another
+   user's job is to have strong Client Authentication coupled with
+   Printer access control to limit the users who have System
+   Administrator or Operator privileges who can modify any job and, in
+   addition, store the Client Authentication with each Job so that only
+   the job owner End User can modify his/her own job.
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 38]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+14 References
+
+14.1 Normative References
+
+   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
+              Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+              April 1999.
+
+   [RFC2566]  deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
+              Powell, "Internet Printing Protocol/1.0: Model and
+              Semantics", RFC 2566, April 1999.
+
+   [RFC2910]  Herriot, R., Butler, S., Moore, P. and R. Turner,
+              "Internet Printing Protocol/1.1: Encoding and Transport",
+              RFC 2910, September 2000.
+
+   [RFC2911]  Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
+              Powell, "Internet Printing Protocol/1.0: Model and
+              Semantics", RFC 2911, September 2000.
+
+   [RFC3382] deBry, R., Hastings, T., Herriot, R., Ocke, K. and P.
+              Zehler, "Internet Printing Protocol (IPP): The
+              'collection' attribute syntax", RFC 3382, September 2002.
+
+14.2 Informative References
+
+   [RFC2251]  Wahl, M., Howes, T. abd S. Kille, "Lightweight Directory
+              Access Protocol (v3)", RFC 2251, December 1997.
+
+   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+              "Lightweight Directory Access Protocol (v3): Attribute
+              Syntax Definitions", RFC 2252, December 1997.
+
+   [RFC2608]  Guttman, E., Perkins, C., Veizades, J. and M. Day,
+              "Service Location Protocol, Version 2", RFC 2608, June
+              1999.
+
+   [RFC2609]  Guttman, E., Perkins, C. and J. Kempf, "Service Templates
+              and service: Schemes", RFC 2609, June 1999.
+
+   [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C. and H.
+              Holst, "Internet Printing Protocol/1.1: Implementor's
+              Guide", RFC 3196, November 2001.
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 39]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+Appendix A: Allowed Values for Set-Printer-Attributes and
+            Set-Job-Attributes requests (Normative)
+
+   This appendix is a normative part of this document and contains a
+   table of all IPP/1.1 attributes.  Each row contains:
+
+      -  an attribute and
+
+      -  the values allowed in the Set-Printer-Attributes or Set-Job-
+         Attributes request for the attribute.  The entry in each cell
+         is the name (first few words) of each item below 1, 2, 3, 4a-g,
+         and 5.
+
+   The allowed values include the following cases:
+
+      1. READ-ONLY: the Set-Printer-Attributes or Set-Job-Attributes
+         operation MUST NOT change this attribute and MUST reject the
+         entire operation (see section 7.1).
+
+      2. Any of  "xxx-supported": the  Set-Printer-Attributes or Set-
+         Job-Attributes operation accepts values that are allowed
+         according to the IPP/1.1 rules for validating the value(s) of
+         an "xxx" Printer or Job attribute against the value(s) of the
+         corresponding "xxx-supported" Printer attribute.  Table 5
+         summarizes those validation rules depending on each attribute
+         syntax and value of an "xxx" attribute supplied in the request
+         and that of the corresponding "xxx-supported" Printer
+         attribute.  The "xxx-supported" attribute syntax type and
+         value(s) are obtained from a Get-Printer-Supported-Values
+         response (see the tables in this Appendix).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 40]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+          Table 5 - Validation rules for 'Any of "xxx-supported" '
+
+      Type of "xxx"  Type of "xxx-      Validates if:
+      value to be    supported" value
+      set
+
+      integer        rangeOfInteger     each value is in one of the
+                                        "xxx-supported" ranges
+
+      uri            uriScheme          each uri scheme matches one
+                                        of the "xxx-supported"
+                                        schemes
+
+      any            boolean            if the boolean "xxx-
+                                        supported" is 'true'
+
+      any            same type          each value matches an "xxx-
+                                        supported" value of the same
+                                        type
+
+   For additional non-normative explanatory information see section
+   3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's Guide"
+   [RFC3196].
+
+      3. From Get-Printer-Supported-Values: the  Set-Printer-Attributes
+         operation accepts values that are allowed according to the
+         IPP/1.1 rules for validating the value(s) of an "xxx" Printer
+         attribute against the value(s) of the corresponding "xxx-
+         supported" Printer attribute.  Table 6 summarizes those
+         validation rules depending on each attribute syntax and value
+         of an "xxx" attribute supplied in the request and that of the
+         corresponding "xxx-supported" Printer attribute.  The "xxx-
+         supported" attribute syntax type and attribute value(s) are
+         obtained from a Get-Printer-Supported-Values response (see
+         Appendix B: Attributes returned from Get-Printer-Supported-
+         Values below).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 41]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Table 6 - Validation rules for 'From Get-Printer-Supported-Values'
+
+       Type of                 -
+       "xxx"       supported" value  Validates if:
+       value to
+       be set      Type of "xxx
+
+
+       integer     rangeOfInteger    each 'integer' value is in one of
+                                     the "xxx-supported" ranges
+
+       uri         uriScheme         the uri scheme of each value
+                                     matches one of the "xxx-supported"
+                                     schemes
+
+       any         boolean           if the boolean "xxx-supported" is
+                                     'true'
+
+       name        'admin-define'    any 'name' value matches
+                   out-of-band
+                   value
+
+       any         same type         each value matches an "xxx-
+                                     supported" value of the same type
+
+   For additional non-normative explanatory information see section
+   3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's Guide"
+   [RFC3196].
+
+      4. Any value of the proper attribute syntax: the Set-Printer-
+         Attributes or Set-Job-Attributes operation accepts any value of
+         the specified attribute syntax.  The attribute syntaxes
+         supported are enumerated below.
+
+            a. Any text(127)
+            b. Any name(127)
+            c. Any uri
+            d. Any boolean
+            e. Any positive integer
+            f. Any dateTime
+            g. 1setOf any uri
+
+      5. Combination of 'Any of "xxx-supported"' or 'Any name'.  If a
+         Printer implementation doesn't want to allow setting values
+         indicated in this Appendix as "any xxx", it can make the value
+         be not-settable.
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 42]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+     Table 7 - Values allowed for Job Template Attributes in the
+                     Set-Job-Attributes Operation
+
+      Job Template Attributes                      Values allowed for
+                                                   Set
+
+      job-priority (integer(1:100))                Any of "xxx-
+                                                   supported"
+
+      job-hold-until (type3 keyword | name (MAX))  Any of "xxx-
+                                                   supported"
+
+      job-sheets (type3 keyword | name(MAX))       Any of "xxx-
+                                                   supported"
+
+      multiple-document-handling (type2 keyword)   Any of "xxx-
+                                                   supported"
+
+      copies (integer(1:MAX))                      Any of "xxx-
+                                                   supported"
+
+      finishings (1setOf type2 enum)               Any of "xxx-
+                                                   supported"
+
+      page-ranges (1setOf rangeOfInteger (1:MAX))  Any of "xxx-
+                                                   supported"
+
+      sides (type2 keyword)                        Any of "xxx-
+                                                   supported"
+
+      number-up (integer(1:MAX))                   Any of "xxx-
+                                                   supported"
+
+      orientation-requested (type2 enum)           Any of "xxx-
+                                                   supported"
+
+      media (type3 keyword | name(MAX))            Any of "xxx-
+                                                   supported"
+
+      printer-resolution (resolution)              Any of "xxx-
+                                                   supported"
+
+      print-quality (type2 enum)                   Any of "xxx-
+                                                   supported"
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 43]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Table 8 - Values allowed for Job Description Attributes in the
+                      Set-Job-Attributes Operation
+
+      Job Description Attributes                   Values allowed for
+                                                   Set
+
+      job-uri (uri)                                READ-ONLY
+
+      job-id (integer(1:MAX))                      READ-ONLY
+
+      job-printer-uri (uri)                        READ-ONLY
+
+      job-more-info (uri)                          READ-ONLY
+
+      job-name (name(MAX))                         Any name(MAX)
+
+      job-originating-user-name (name(MAX))        READ-ONLY
+
+      job-state (type1 enum)                       READ-ONLY
+
+      job-state-reasons (1setOf type2 keyword)     READ-ONLY
+
+      job-state-message (text(MAX))                READ-ONLY
+
+      job-detailed-status-messages (1setOf         READ-ONLY
+      text(MAX))
+
+      job-document-access-errors (1setOf           READ-ONLY
+      text(MAX))
+
+      number-of-documents (integer(0:MAX))         READ-ONLY
+
+      output-device-assigned (name(127))           READ-ONLY
+
+      time-at-creation (integer(MIN:MAX))          READ-ONLY
+
+      time-at-processing (integer(MIN:MAX))        READ-ONLY
+
+      time-at-completed (integer(MIN:MAX))         READ-ONLY
+
+      job-printer-up-time (integer(1:MAX))         READ-ONLY
+
+      date-time-at-creation (dateTime)             READ-ONLY
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 44]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Job Description Attributes                   Values allowed for
+                                                   Set
+
+      date-time-at-processing (dateTime)           READ-ONLY
+
+      date-time-at-completed (dateTime)            READ-ONLY
+
+      number-of-intervening-jobs (integer(0:MAX))  READ-ONLY
+
+      job-message-from-operator (text(127))        Any text(127)
+
+      job-k-octets (integer(0:MAX))                READ-ONLY
+
+      job-impressions (integer(0:MAX))             READ-ONLY
+
+      job-media-sheets (integer(0:MAX))            READ-ONLY
+
+      job-k-octets-processed (integer(0:MAX))      READ-ONLY
+
+      job-impressions-completed (integer(0:MAX))   READ-ONLY
+
+      job-media-sheets-completed (integer(0:MAX))  READ-ONLY
+
+      attributes-charset (charset)                 READ-ONLY
+
+      attributes-natural-language                  READ-ONLY
+      (naturalLanguage)
+
+      Table 9 - Values allowed for Printer Job Template Attributes in
+                      the Set-Printer-Attributes Operation
+
+      Printer Job Template Attributes                 Values allowed
+                                                      for Set
+
+      job-priority-default (integer(1:100))           Any of "xxx-
+                                                      supported"
+
+      job-hold-until-default (type3 keyword | name    Any of "xxx-
+      (MAX))                                          supported"
+
+      job-sheets-default (type3 keyword | name(MAX))  Any of "xxx-
+                                                      supported"
+
+      multiple-document-handling-default (type2       Any of "xxx-
+      keyword)                                        supported"
+
+      copies-default (integer(1:MAX))                 Any of "xxx-
+                                                      supported"
+
+
+
+Hastings, et. al.           Standards Track                    [Page 45]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Printer Job Template Attributes                 Values allowed
+                                                      for Set
+
+      finishings-default (1setOf type2 enum)          Any of "xxx-
+                                                      supported"
+
+      sides-default (type2 keyword)                   Any of "xxx-
+                                                      supported"
+
+      number-up-default (integer(1:MAX))              Any of "xxx-
+                                                      supported"
+
+      orientation-requested-default (type2 enum)      Any of "xxx-
+                                                      supported"
+
+      media-default (type3 keyword | name(MAX))       Any of "xxx-
+                                                      supported"
+
+      printer-resolution-default (resolution)         Any of "xxx-
+                                                      supported"
+
+      print-quality-default (type2 enum)              Any of "xxx-
+                                                      supported"
+
+      job-priority-supported (integer(1:100))         From Get-
+                                                      Printer-
+                                                      Supported-Values
+
+      job-hold-until-supported (1setOf(type3 keyword  From Get-
+      | name (MAX)))                                  Printer-
+                                                      Supported-Values
+
+      job-sheets-supported (1setOf(type3 keyword |    From Get-
+      name(MAX)))                                     Printer-
+                                                      Supported-Values
+
+      multiple-document-handling-supported (1setOf    From Get-
+      type2 keyword)                                  Printer-
+                                                      Supported-Values
+
+      copies-supported (rangeOfInteger(1:MAX))        From Get-
+                                                      Printer-
+                                                      Supported-Values
+
+      finishings-supported (1setOf type2 enum)        From Get-
+                                                      Printer-
+                                                      Supported-Values
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 46]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Printer Job Template Attributes                 Values allowed
+                                                      for Set
+
+      page-ranges-supported (boolean)                 From Get-
+                                                      Printer-
+                                                      Supported-Values
+
+      sides-supported (1setOf type2 keyword)          From Get-
+                                                      Printer-
+                                                      Supported-Values
+
+      number-up-supported (1setOf (integer(1:MAX) |   From Get-
+      rangeOfInteger(1:MAX)))                         Printer-
+                                                      Supported-Values
+
+      orientation-requested-supported (1setOf type2   From Get-
+      enum)                                           Printer-
+                                                      Supported-Values
+
+      media-supported (1setOf (type3 keyword |        From Get-
+      name(MAX)))                                     Printer-
+                                                      Supported-Values
+
+      printer-resolution-supported (1setOf            From Get-
+      resolution)                                     Printer-
+                                                      Supported-Values
+
+      print-quality-supported (1setOf type2 enum)     From Get-
+                                                      Printer-
+                                                      Supported-Values
+
+      media-ready (type3 keyword | name(MAX))         From Get-
+                                                      Printer-
+                                                      Supported-Values
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 47]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Table 10 - Values allowed for Printer Description Attributes in
+                     the Set-Printer-Attributes Operation
+
+      Printer Description Attributes               Values allowed for
+                                                   Set
+
+      printer-uri-supported (1setOf uri)           READ-ONLY
+
+      uri-authentication-supported (1setOf type2   READ-ONLY
+      keyword)
+
+      uri-security-supported (1setOf type2         READ-ONLY
+      keyword)
+
+      printer-xri-supported (1setOf collection)
+      member attributes:
+
+        xri-uri (uri)                              any uriScheme of
+                                                   "xri-uri-scheme-
+                                                   supported" from
+                                                   Get-Printer-
+                                                   Attributes
+
+        xri-authentication (type2 keyword)         any keyword of
+                                                   "xri-
+                                                   authentication-
+                                                   supported" from
+                                                   Get-Printer-
+                                                   Attributes
+
+        xri-security (type2 keyword)               any keyword of
+                                                   "xri-security-
+                                                   supported" from
+                                                   Get-Printer-
+                                                   Attributes
+
+      xri-uri-scheme-supported (1setOf uriScheme)  READ-ONLY
+
+      xri-authentication-supported (1setOf type2   READ-ONLY
+      keyword)
+
+      xri-security-supported (1setOf type2         READ-ONLY
+      keyword)
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 48]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Printer Description Attributes               Values allowed for
+                                                   Set
+
+      printer-name (name(127))                     Any name(127)
+
+      printer-location (text(127))                 Any text(127)
+
+      printer-info (text(127))                     Any text(127)
+
+      printer-more-info (uri)                      Any uri
+
+      printer-driver-installer (uri)               Any uri
+
+      printer-make-and-model (text(127))           Any text(127)
+
+      printer-more-info-manufacturer (uri)         Any uri
+
+      printer-state (type1 enum)                   READ-ONLY
+
+      printer-state-reasons (1setOf type2          READ-ONLY
+      keyword)
+
+      printer-state-message (text(MAX))            READ-ONLY
+
+      ipp-versions-supported (1setOf type2         From Get-Printer-
+      keyword)                                     Supported-Values
+
+      operations-supported (1setOf type2 enum)     From Get-Printer-
+                                                   Supported-Values
+
+      multiple-document-jobs-supported (boolean)   From Get-Printer-
+                                                   Supported-Values
+
+      charset-configured (charset)                 Any of "xxx-
+                                                   supported", use
+                                                   "charset-supported"
+
+      charset-supported (1setOf charset)           From Get-Printer-
+                                                   Supported-Values
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 49]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Printer Description Attributes               Values allowed for
+                                                   Set
+
+      natural-language-configured                  Any of "xxx-
+      (naturalLanguage)                            supported", use
+                                                   "generated-natural-
+                                                   language-supported"
+
+      generated-natural-language-supported         From Get-Printer-
+      (1setOf naturalLanguage)                     Supported-Values
+
+      document-format-default (mimeMediaType)      Any of "xxx-
+                                                   supported"
+
+      document-format-supported (1setOf            From Get-Printer-
+      mimeMediaType)                               Supported-Values
+
+      printer-is-accepting-jobs (boolean)          READ-ONLY
+
+      queued-job-count (integer(0:MAX))            READ-ONLY
+
+      printer-message-from-operator (text(127))    Any text(127)
+
+      color-supported (boolean)                    From Get-Printer-
+                                                   Supported-Values
+
+      reference-uri-schemes-supported (1setOf      From Get-Printer-
+      uriScheme)                                   Supported-Values
+
+      pdl-override-supported (type2 keyword)       From Get-Printer-
+                                                   Supported-Values
+
+      printer-up-time (integer(1:MAX))             READ-ONLY
+
+      printer-current-time (dateTime)              Any dateTime **
+
+      multiple-operation-time-out                  any positive
+      (integer(1:MAX))                             integer
+
+      compression-supported (1setOf type3          From Get-Printer-
+      keyword)                                     Supported-Values
+
+      job-k-octets-supported                       From Get-Printer-
+      (rangeOfInteger(0:MAX))                      Supported-Values
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 50]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Printer Description Attributes               Values allowed for
+                                                   Set
+
+      job-impressions-supported                    From-Get-Printer-
+      (rangeOfInteger(0:MAX))                      Supported-Values
+
+      job-media-sheets-supported                   From Get-Printer-
+      (rangeOfInteger(0:MAX))                      Supported-Values
+
+      pages-per-minute (integer(0:MAX))            READ-ONLY
+
+      pages-per-minute-color (integer(0:MAX))      READ-ONLY
+
+      printer-settable-attributes-supported        From Get-Printer-
+      (1setOf type2 keyword)                       Supported-Values
+
+      job-settable-attributes-supported (1setOf    From Get-Printer-
+      type2 keyword)                               Supported-Values
+
+      document-format-varying-attributes (1setOf   READ-ONLY
+      type2 keyword)
+
+      printer-message-time (integer(MIN:MAX))      READ-ONLY
+
+      printer-message-date-time(dateTime)          READ-ONLY
+
+   ** - The "printer-current-time" (dateTime) attribute is settable in
+   order to allow an administrator to correct an incorrect dateTime or
+   time zone.
+
+Appendix B: Attributes returned from Get-Printer-Supported-Values
+            (Normative)
+
+   This Appendix is a normative part of this document and lists all the
+   attributes that are possible for an implementation to return in a
+   Get-Printer-Supported-Values response, i.e., all the "xxx-supported"
+   attributes that can be supplied in a Set-Printer-Attributes request.
+   READ-ONLY attributes MUST NOT be returned in a Get-Printer-
+   Supported-Values response and are indicated in the tables as "READ-
+   ONLY - MUST NOT be returned."
+
+   For the following attributes, the value allowed by the Set-Printer-
+   Attributes operation MUST be a single integer value in the range
+   specified by the value returned by the Get-Printer-Supported-Values
+   operation.
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 51]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+     Table 11 - Printer Job Template Attributes returned from
+                      Get-Printer-Supported-Values
+
+      Printer Job Template Attributes            Values Returned
+
+      job-priority-supported (integer(1:100))    rangeOfInteger(1:100)
+
+   For the following attributes, the value allowed by the Set-Printer-
+   Attributes operation MUST be a single rangeOfInteger value whose
+   bounds do not exceed those of the range specified by the value
+   returned by the Get-Printer-Supported-Values operation.
+
+     Table 12 - Printer Job Template Attributes returned from
+                    Get-Printer-Supported-Values
+
+      Printer Job Template Attributes             Values Returned
+
+      copies-supported (rangeOfInteger(1:MAX))    rangeOfInteger(1:MAX)
+
+   The following table has the same criteria as the last, but is for
+   Printer Description attributes.
+
+     Table 13 - Printer Description Attributes returned from
+                  Get-Printer-Supported-Values
+
+      Printer Description Attributes            Values allowed for Set
+
+      job-k-octets-supported                    rangeOfInteger(0:MAX)
+      (rangeOfInteger(0:MAX))
+
+      job-impressions-supported
+      (rangeOfInteger(0:MAX))                   rangeOfInteger(0:MAX)
+
+      job-media-sheets-supported                rangeOfInteger(0:MAX)
+      (rangeOfInteger(0:MAX))
+
+   For the following attributes, the value allowed by the Set-Printer-
+   Attributes operation MUST be one or more integers and rangeOfInteger
+   values, such that the integer values described by these integers and
+   rangeOfInteger is the same as or a subset of the integers described
+   by the integers and rangeOf Integer of values returned by the Get-
+   Printer-Supported-Values operation.
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 52]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+     Table 14 - Printer Job Template Attributes returned from
+                  Get-Printer-Supported-Values
+
+      Printer Job Template Attributes              Values Returned
+
+      number-up-supported (1setOf (integer(1:MAX)  1setOf
+      | rangeOfInteger(1:MAX)))                    (integer(1:MAX) |
+                                                   rangeOfInteger(1:MA
+                                                   X))
+
+   For the following attributes, the value allowed by the Set-Printer-
+   Attributes operation MUST be one or more values, where each such
+   value matches a value returned by the Get-Printer-Supported-Values
+   operation.  A keyword, enum, boolean, charset, naturalLanguage,
+   uriScheme, mimeMediaType or resolution value matches if it is equal.
+   For Job Template attributes, with the attribute syntax 'type3 keyword
+   | name', any 'name' attribute syntax value matches the 'admin-define'
+   out-of-band value, if the implementation allows the administrator to
+   set any name values for the attribute.
+
+     Table 15 - Printer Job Template Attributes returned from
+                  Get-Printer-Supported-Values
+
+      Printer Job Template Attributes              Values Returned
+
+      job-hold-until-supported (1setOf(type3       1setOf (type3
+      keyword | name (MAX)))                       keyword | 'admin-
+                                                   define')
+
+      job-sheets-supported (1setOf(type3 keyword   1setOf (type3
+      | name(MAX)))                                keyword | 'admin-
+                                                   define')
+
+      multiple-document-handling-supported         1setOf type2
+      (1setOf type2 keyword)                       keyword
+
+      finishings-supported (1setOf type2 enum)     1setOf type2 enum
+
+      page-ranges-supported (boolean)              1setOf boolean **
+
+      sides-supported (1setOf type2 keyword)       1setOf type2
+                                                   keyword
+
+      orientation-requested-supported (1setOf      1setOf type2 enum
+      type2 enum)
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 53]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Printer Job Template Attributes              Values Returned
+
+      media-supported (1setOf (type3 keyword |     1setOf (type3
+      name(MAX)))                                  keyword | 'admin-
+                                                   define')
+
+      printer-resolution-supported (1setOf         1setOf resolution
+      resolution)
+
+      print-quality-supported (1setOf type2 enum)  1setOf type2 enum
+
+   ** Note: the Get-Printer-Supported-Values returns a '1setOf boolean'
+   so that all possible values are indicated, while ** Get-Printer-
+   Attributes returns only a single 'boolean' value.
+
+   The following table has the same criteria as the last, but is for
+   Printer Description attributes.
+
+     Table 16 - Printer Description Attributes returned from
+                  Get-Printer-Supported-Values
+
+      Printer Description Attributes               Values allowed for
+                                                   Set
+
+      printer-uri-supported (1setOf uri)           READ-ONLY - MUST
+                                                   NOT be returned
+
+      uri-authentication-supported (1setOf type2   READ-ONLY - MUST
+      keyword)                                     NOT be returned
+
+      uri-security-supported (1setOf type2         READ-ONLY - MUST
+      keyword)                                     NOT be returned
+
+      printer-xri-supported (1setOf collection)    MUST NOT be
+                                                   returned; see next
+                                                   three attributes
+                                                   returned with Get-
+                                                   Printer-Attributes:
+
+      xri-uri-scheme-supported (1setOf uriScheme)  READ-ONLY - MUST
+                                                   NOT be returned
+
+      xri-authentication-supported (1setOf type2   READ-ONLY - MUST
+      keyword)                                     NOT be returned
+
+      xri-security-supported (1setOf type2         READ-ONLY - MUST
+      keyword)                                     NOT be returned
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 54]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+      Printer Description Attributes               Values allowed for
+                                                   Set
+
+      ipp-versions-supported (1setOf type2         1setOf type2
+      keyword)                                     keyword
+
+      operations-supported (1setOf type2 enum)     1setOf type2
+                                                   keyword
+
+      multiple-document-jobs-supported (boolean)   1setOf boolean **
+
+      charset-supported (1setOf charset)           1setOf charset
+
+      generated-natural-language-supported         1setOf
+      (1setOf naturalLanguage)                     naturalLanguage
+
+      document-format-supported (1setOf            1setOf
+      mimeMediaType)                               mimeMediaType
+
+      color-supported (boolean)                    1setOf boolean **
+
+      reference-uri-schemes-supported (1setOf      1setOf uriScheme
+      uriScheme)
+
+      pdl-override-supported (type2 keyword)       1setOf type2
+                                                   keyword **
+
+      compression-supported (1setOf type3          1setOf type3
+      keyword)                                     keyword
+
+      printer-settable-attributes-supported        1setOf type2
+      (1setOf type2 keyword)                       keyword
+
+      job-settable-attributes-supported (1setOf    1setOf type2
+      type2 keyword)                               keyword
+
+   ** Note: the Get-Printer-Supported-Values returns a '1setOf X' so
+   that all possible values are indicated, while Get-Printer-Attributes
+   returns only a single 'X' value.
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 55]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+Appendix C: Description of the Base IPP Documents (Informative)
+
+   The base set of IPP documents includes:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+      Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+      Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
+   operations have been added to IPP/1.1 [RFC2911, RFC2910].
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF IPP working group's major decisions.
+
+   The "Internet Printing Protocol/1.1: Model and Semantics" document
+   describes a simplified model with abstract objects, their attributes,
+   and their operations.  The model introduces a Printer and a Job.  The
+   Job supports multiple documents per Job.  The model document also
+   addresses how security, internationalization, and directory issues
+   are addressed.
+
+   The "Internet Printing Protocol/1.1: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1 [RFC2616].  It also defines the
+   encoding rules for a new Internet MIME media type called
+   "application/ipp".  This document also defines the rules for
+   transporting over HTTP, a message body whose Content-Type is
+   "application/ipp".  This document defines the 'ipp' scheme for
+   identifying IPP printers and jobs.
+
+   The "Internet Printing Protocol/1.1: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.1 and some of
+   the considerations that may assist them in the design of their client
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 56]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions are also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+Authors' Addresses
+
+   Carl Kugler
+   IBM
+   P.O. Box 1900
+   Boulder, CO 80301-9191
+
+   Phone: (303) 924-5060
+   EMail: kugler@us.ibm.com
+
+
+   Tom Hastings
+   Xerox Corporation
+   737 Hawaii St.  ESAE 231
+   El Segundo, CA  90245
+
+   Phone: 310-333-6413
+   Fax: 310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Robert Herriot
+   Consultant
+   706 Colorado Ave
+   Palo Alto, CA 94303
+
+   Phone: 650-327-4466
+   Fax: 650-327-4466
+   EMail: bob@Herriot.com
+
+
+   Harry Lewis
+   IBM
+   6300 Diagonal Hwy.
+   Boulder, CO 80301-9191
+
+   Phone: (303) 924-5337
+   EMail: harryl@us.ibm.com
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 57]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+   IPP Web Page: http://www.pwg.org/ipp/
+   IPP Mailing List: ipp@pwg.org
+
+   To subscribe to the ipp mailing list, send the following email:
+
+     1) send it to majordomo@pwg.org
+     2) leave the subject line blank
+     3) put the following two lines in the message body:
+          subscribe ipp
+          end
+
+   Implementers of this specification document are encouraged to join
+   the IPP Mailing List in order to participate in any discussions of
+   clarification issues and review of registration proposals for
+   additional attributes and values.  In order to reduce spam the
+   mailing list rejects mail from non-subscribers, so you must subscribe
+   to the mailing list in order to send a question or comment to the
+   mailing list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 58]
+
+RFC 3380          IPP: Job and Printer Set Operations     September 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 59]
+
diff --git a/standards/rfc3381.txt b/standards/rfc3381.txt
new file mode 100644
index 000000000..d7fd60f81
--- /dev/null
+++ b/standards/rfc3381.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                        T. Hastings
+Request for Comments: 3381                             Xerox Corporation
+Updates: 2910                                                   H. Lewis
+Category: Standards Track                           IBM Printing Company
+                                                              R. Bergman
+                                          Hitachi Koki Imaging Solutions
+                                                          September 2002
+
+
+                   Internet Printing Protocol (IPP):
+                        Job Progress Attributes
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines four new Job Description attributes for
+   monitoring job progress to be registered as OPTIONAL extensions to
+   the Internet Printing Protocol (IPP/1.0 and IPP/1.1).  These
+   attributes are drawn from the PWG Job Monitoring MIB.  This document
+   also defines a new "sheet-collate" Job Template attribute to control
+   sheet collation and to help with the interpretation of the job
+   progress attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 1]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+Table of Contents
+
+   1 Introduction.....................................................2
+   2 Terminology......................................................2
+   2.1 Conformance Terminology........................................4
+   2.2 Other terminology..............................................4
+   3 Job Template attributes..........................................4
+   3.1 sheet-collate (type2 keyword)..................................4
+   4 IPP Job Description attributes for monitoring Job Progress.......6
+   4.1 job-collation-type (type2 enum)................................9
+   4.2 sheet-completed-copy-number (integer(0:MAX))..................11
+   4.3 sheet-completed-document-number (integer(0:MAX))..............11
+   4.4 impressions-completed-current-copy (integer(0:MAX))...........11
+   5 Conformance Requirements........................................11
+   6 IANA Considerations.............................................12
+   6.1 Attributes....................................................
+   6.2 Keyword Attribute Values......................................
+   6.3 Enum Attribute Values.........................................
+   7 Internationalization Considerations.............................12
+   8 Security Considerations.........................................12
+   9 References......................................................12
+   10 Description of the Base IPP Documents..........................13
+   11 Authors' Addresses.............................................15
+   12 Full Copyright Statement.......................................16
+
+1 Introduction
+
+   This document defines four new Job Description attributes for
+   monitoring job progress to be registered as OPTIONAL extensions to
+   IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911].  These attributes are drawn
+   from the PWG Job Monitoring MIB [RFC2707].  See section 10 for a
+   description of the base IPP documents.  The new Job Description
+   attributes are:
+
+      "job-collation-type" (type2 enum)
+      "sheet-completed-copy-number" (integer(0:MAX))
+      "sheet-completed-document-number" (integer(0:MAX))
+      "impressions-completed-current-copy" (integer(0:MAX))
+
+   This document also defines a new "sheet-collate" Job Template
+   attribute to control sheet collation and to help with the
+   interpretation of the job progress attributes.  These new attributes
+   may also be used by themselves in combination with the IPP/1.1 "job-
+   impressions-completed" attribute, as useful job progress monitoring
+   attributes and/or may be passed in an IPP Notification (see [ipp-
+   ntfy]).
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 2]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+2 Terminology
+
+   This section defines terminology used throughout this document.
+
+2.1 Conformance Terminology
+
+   Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+   NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+   conformance, as defined in RFC 2119 [RFC2119] and [RFC2911] section
+   12.1.  If an implementation supports the extension defined in this
+   document, then these terms apply; otherwise, they do not.  These
+   terms define conformance to this document only; they do not affect
+   conformance to other documents, unless explicitly stated otherwise.
+
+2.2 Other terminology
+
+   This document uses terms such as Job object (or Job), IPP Printer
+   object (or Printer), "operation", "attribute", "keyword", "support",
+   and "impression".  These terms have special meaning and are defined
+   in the model terminology [RFC2911], section 12.2.
+
+3 Job Template attributes
+
+3.1 sheet-collate (type2 keyword)
+
+   +===================+======================+=====================+
+   | Job Attribute     |Printer: Default Value|  Printer: Supported |
+   |                   |   Attribute          |   Values Attribute  |
+   +===================+======================+=====================+
+   | sheet-collate     | sheet-collate-default| sheet-collate-      |
+   | (type2 keyword)   | (type2 keyword)      |  supported (1setOf  |
+   |                   |                      |      type2 keyword) |
+   +-------------------+----------------------+---------------------+
+
+   This attribute specifies whether or not the media sheets of each copy
+   of each printed document in a job are to be in sequence, when
+   multiple copies of the document are specified by the 'copies'
+   attribute.
+
+   Standard keyword values are:
+
+      'uncollated':  each print-stream sheet is printed a number of
+         times in succession equal to the value of the 'copies'
+         attribute, followed by the next print-stream sheet.
+
+      'collated':  each copy of each document is printed with the
+         print-stream sheets in sequence, followed by the next document
+         copy.
+
+
+
+Hastings, et. al.           Standards Track                     [Page 3]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+   For example, suppose a document produces two media sheets as output,
+   and "copies" is equal to '6'.  For the 'uncollated' case, six copies
+   of the first media sheet are printed, followed by six copies of the
+   second media sheet.  For the 'collated' case, one copy of each of the
+   six sheets is printed, followed by another copy of each of the six
+   media sheets.
+
+   Whether the effect of sheet collation is achieved by placing copies
+   of a document in multiple output bins, or in the same output bin with
+   implementation defined document separation, is implementation
+   dependent.  Also whether it is achieved by making multiple passes
+   over the job or by using an output sorter, is implementation
+   dependent.
+
+   Note: IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911] are silent on whether
+   or not sheets within documents are collated.  The "sheet-collate-
+   supported" Printer attribute permits a Printer object to indicate
+   whether or not it collates sheets with each document and whether it
+   allows the client to control sheet collation.  An implementation is
+   able to indicate that it supports uncollated sheets, collated sheets,
+   or both, using the 'uncollated', 'collated', or both 'uncollated' and
+   'collated' values, respectively.
+
+   This attribute is affected by "multiple-document-handling".  The
+   "multiple-document-handling" attribute describes the collation of
+   documents, and the "sheet-collate" attribute describes the semantics
+   of collating individual pages within a document.  To better explain
+   the interaction between these two attributes, the term "set" is
+   introduced.  A "set" is a logical boundary between the delivered
+   media sheets of a printed job.  For example, in the case of a ten
+   page single document with collated pages and a request for 50 copies,
+   each of the 50 printed copies of the document constitutes a "set".
+   In the above example if the pages were uncollated, then 50 copies of
+   each of the individual pages within the document would represent each
+   "set".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 4]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+   The following table describes the interaction of "sheet-collate" with
+   multiple document handling.
+
+      "sheet-        "multiple-       Semantics
+      collate"       document-
+                     handling"
+
+      'collated'     'single-         Each copy of the concatenated
+                     document'        documents, with their pages in
+                                      sequence, represents a "set".
+
+      'collated'     'single-         Each copy of the concatenated
+                     document-new-    documents, with their pages in
+                     sheet'           sequence, represents a "set".
+
+      'collated'     'separate-       Each copy of each separate
+                     documents-       document, with its pages in
+                     collated-        sequence, represents a "set".
+                     copies'
+
+      'collated'     'separate-       Each copy of each separate
+                     documents-       document, with its pages in
+                     uncollated-      sequence, represents a "set".
+                     copies
+
+      'uncollated'   'single-         Each media sheet of the document
+                     document'        is printed a number of times equal
+                                      to the "copies" attribute; which
+                                      constitutes a "set".
+
+      'uncollated'   'single-         Each media sheet of the
+                     document-new-    concatenated documents is printed
+                     sheet'           a number of times equal to the
+                                      "copies" attribute; which
+                                      constitutes a "set".
+
+      'uncollated'   'separate-       This is a degenerate case, and the
+                     documents-       printer object MUST reject the job
+                     collated-        and return the status, "client-
+                     copies'          error-conflicting-attributes".
+
+      'uncollated'   'separate-       This is a degenerate case, and the
+                     documents-       printer object MUST reject the job
+                     uncollated-      and return the status "client-
+                     copies           error-conflicting-attributes".
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 5]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+      From the above table it is obvious that the implicit value of the
+      "sheet-collate" attribute in a printer that does not support the
+      "sheet-collate" attribute, is 'collated.'  The semantics of
+      "multiple-document-handling" are otherwise nonsensical in the case
+      of separate documents.
+
+4 IPP Job Description attributes for monitoring Job Progress
+
+   The following IPP Job Description attributes are proposed to be added
+   to IPP through the type2 registration procedures.  They are useful
+   for monitoring the progress of a job.  They are also used as
+   attributes in the notification content in a notification report
+   [ipp-ntfy].
+
+   There are a number of Job Description attributes for monitoring the
+   progress of a job.  These objects and attributes count the number of
+   K octets, impressions, sheets, and pages requested or completed.  For
+   impressions and sheets, "completed" means stacked, unless the
+   implementation is unable to detect when each sheet is stacked, in
+   which case, stacked is approximated when the processing of each sheet
+   is completed.  There are objects and attributes for the overall job
+   and for the current copy of the document currently being stacked.
+   For the latter, the rate at which the various objects and attributes
+   count, depends on the sheet and document collation of the job.
+
+   Consider the following four Job Description attributes that are used
+   to monitor the progress of a job's impressions:
+
+      1. "job-impressions-completed" - counts the total number of
+         impressions stacked for the job (see [RFC2911] section
+         4.3.18.2).
+
+      2. "impressions-completed-current-copy" - counts the number of
+         impressions stacked for the current document copy.
+
+      3. "sheet-completed-copy-number" - identifies the number of the
+         copy for the current document being stacked, where the first
+         copy is 1.
+
+      4. "sheet-completed-document-number" - identifies the current
+         document within the job that is being stacked, where the first
+         document in a job is 1.  NOTE: this attribute SHOULD NOT be
+         implemented for implementations that only support one document
+         per job.
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 6]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+   For each of the three types of job collation, a job with three copies
+   of two documents (1, 2), where each document consists of 3
+   impressions, the four variables have the following values, as each
+   sheet is stacked for one-sided printing:
+
+   "job-collation-type" = 'uncollated-sheets(3)'
+
+   "job-            "impressions-     "sheet-         "sheet-
+   impressions-     completed-        completed-      completed-
+   completed"       current-copy"     copy-number"    document-
+                                                      number"
+
+        0                0                0               0
+        1                1                1               1
+        2                1                2               1
+        3                1                3               1
+        4                2                1               1
+        5                2                2               1
+        6                2                3               1
+        7                3                1               1
+        8                3                2               1
+        9                3                3               1
+       10                1                1               2
+       11                1                2               2
+       12                1                3               2
+       13                2                1               2
+       14                2                2               2
+       15                2                3               2
+       16                3                1               2
+       17                3                2               2
+       18                3                3               2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 7]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+   "job-collation-type" = 'collated-documents(4)'
+
+   "job-            "impressions-     "sheet-         "sheet-
+   impressions-     completed-        completed-      completed-
+   completed"       current-copy"     copy-           document-
+                                      number"         number"
+
+        0                0                0               0
+        1                1                1               1
+        2                2                1               1
+        3                3                1               1
+        4                1                1               2
+        5                2                1               2
+        6                3                1               2
+        7                1                2               1
+        8                2                2               1
+        9                3                2               1
+       10                1                2               2
+       11                2                2               2
+       12                3                2               2
+       13                1                3               1
+       14                2                3               1
+       15                3                3               1
+       16                1                3               2
+       17                2                3               2
+       18                3                3               2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                     [Page 8]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+   "job-collation-type" = 'uncollated-documents(5)'
+
+   "job-            "impressions-     "sheet-         "sheet-
+   impressions-     completed-        completed-      completed-
+   completed"       current-copy"     copy-t          document-
+                                      number"         number"
+
+        0                0                0               0
+        1                1                1               1
+        2                2                1               1
+        3                3                1               1
+        4                1                2               1
+        5                2                2               1
+        6                3                2               1
+        7                1                3               1
+        8                2                3               1
+        9                3                3               1
+       10                1                1               2
+       11                2                1               2
+       12                3                1               2
+       13                1                2               2
+       14                2                2               2
+       15                3                2               2
+       16                1                3               2
+       17                2                3               2
+       18                3                3               2
+
+4.1 job-collation-type (type2 enum)
+
+   Job Collation includes sheet collation and document collation.  Sheet
+   collation is defined to be the ordering of sheets within a document
+   copy.  Document collation is defined to be the ordering of document
+   copies within a multi-document job.  The value of the "job-
+   collation-type" is affected by the value of the "sheet-collate" Job
+   Template attribute (see section 3.1), if supplied and supported.
+
+   The Standard enum values are:
+
+      '1' 'other':  not one of the defined values
+
+      '2' 'unknown':  the collation type is unknown
+
+      '3' 'uncollated-sheets':  No collation of the sheets within each
+                    document copy, i.e., each sheet of a document that
+                    is to produce multiple copies, is replicated before
+                    the next sheet in the document is processed and
+                    stacked.  If the device has an output bin collator,
+                    the 'uncollated-sheets(3)' value may actually
+
+
+
+Hastings, et. al.           Standards Track                     [Page 9]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+                    produce collated sheets as far as the user is
+                    concerned (in the output bins).  However, when the
+                    job collation is the 'uncollated-sheets(3)' value,
+                    job progress is indistinguishable from a monitoring
+                    application between a device that has an output bin
+                    collator and one that does not.
+
+      '4' 'collated-documents':  Collation of the sheets within each
+                    document copy is performed within the printing
+                    device by making multiple passes over, either the
+                    source or an intermediate representation of the
+                    document.  In addition, when there are multiple
+                    documents per job, the i'th copy of each document is
+                    stacked before the j'th copy of each document, i.e.,
+                    the documents are collated within each job copy.
+                    For example, if a job is submitted with documents, A
+                    and B, the job is made available to the end user as:
+                    A, B, A, B, ....  The 'collated-documents(4)' value
+                    corresponds to the IPP [RFC2911] 'separate-
+                    documents-collated-copies' keyword value of the
+                    "multiple-document-handling" attribute.
+
+                    If the job's "copies" attribute is '1' (or not
+                    supplied), then the "job-collation-type" attribute
+                    is defined to be '4'.
+
+      '5' 'uncollated-documents':  Collation of the sheets within each
+                    document copy is performed within the printing
+                    device by making multiple passes over either the
+                    source or an intermediate representation of the
+                    document.  In addition, when there are multiple
+                    documents per job, all copies of the first document
+                    in the job are stacked before any copied of the next
+                    document in the job, i.e., the documents are
+                    uncollated within the job.  For example, if a job is
+                    submitted with documents, A and B, the job is made
+                    available to the end user as:  A, A, ..., B, B, ....
+                    The 'uncollated-documents(5)' value corresponds to
+                    the IPP [RFC2911] 'separate-documents-uncollated-
+                    copies' keyword value of the "multiple-document-
+                    handling" attribute.
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 10]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+4.2 sheet-completed-copy-number (integer(0:MAX))
+
+   The number of the copy being stacked for the current document.  This
+   number starts at 0, is set to 1 when the first sheet of the first
+   copy for each document is being stacked and is equal to n where n is
+   the nth sheet stacked in the current document copy.  If the value is
+   unknown, the Printer MUST return the 'unknown' out-of-band value (see
+   [RFC2911] section 4.1), rather than the -2 value used in some MIBs
+   [RFC2707].
+
+4.3 sheet-completed-document-number (integer(0:MAX))
+
+   The ordinal number of the document in the job that is currently being
+   stacked.  This number starts at 0, increments to 1 when the first
+   sheet of the first document in the job is being stacked, and is equal
+   to n where n is the nth document in the job, starting with 1. If the
+   value is unknown, the Printer MUST return the 'unknown' out-of-band
+   value (see [RFC2911] section 4.1), rather than the -2 value used in
+   some MIBs [RFC2707].
+
+   Implementations that only support one document job SHOULD NOT
+   implement this attribute.
+
+4.4 impressions-completed-current-copy (integer(0:MAX))
+
+   The number of impressions completed by the device for the current
+   copy of the current document so far.  For printing, the impressions
+   completed includes interpreting, marking, and stacking the output.
+   For other types of job services, the number of impressions completed
+   includes the number of impressions processed.  If the value is
+   unknown, the Printer MUST return the 'unknown' out-of-band value (see
+   [RFC2911] section 4.1), rather than the -2 value used in some MIBs
+   [RFC2707].
+
+   This value MUST be reset to 0 for each document in the job and for
+   each document copy.
+
+5 Conformance Requirements
+
+   This section summarizes the Conformance Requirements detailed in the
+   definitions in this document.  In general each of the attributes
+   defined in this document are OPTIONAL for a client and/or a Printer
+   to support, so that client and Printer implementers MAY implement any
+   combination of these attributes.
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 11]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+6 IANA Considerations
+
+   This section contains registration information for IANA to add to the
+   IPP Registry according to the procedures defined in RFC 2911
+   [RFC2911], section 6.  The resulting registrations will be published
+   in the http://www.iana.org/assignments/ipp-registrations registry.
+
+6.1 Attributes
+
+   Job Template attributes:                        Ref.      Section:
+   sheet-collate (type2 keyword)                   RFC 3381       3.1
+   sheet-default (type2 keyword)                   RFC 3381       3.1
+   sheet-supported (1setOf type2 keyword)          RFC 3381       3.1
+
+   Job Description attributes:                     Ref.      Section:
+   job-collation-type (type2 enum)                 RFC 3381       4.1
+   sheet-completed-copy-number (integer(0:MAX))    RFC 3381       4.2
+   sheet-completed-document-number (integer(0:MAX))RFC 3381       4.3
+   impressions-completed-current-copy (integer(0:MAX))
+                                                   RFC 3381       4.4
+6.2 Keyword Attribute Values
+
+   The following table provides registration information for all of the
+   attributes defined in this document that have keyword values.  These
+   keywords are to be registered according to the procedures defined in
+   RFC 2911 [RFC2911] section 6.1.
+
+   sheet-collate (type2 keyword)                   RFC 3381       3.1
+     'uncollated'                                  RFC 3381       3.1
+     'collated'                                    RFC 3381       3.1
+   sheet-collate-default (type2 keyword)           RFC 3381       3.1
+     See "sheet-collate" attribute
+   sheet-collate-supported (1setOf type2 keyword)  RFC 3381       3.1
+     See "sheet-collate" attribute
+
+6.3 Enum Attribute Values
+
+   The following table provides registration information for all of the
+   attributes defined in this document that have enum values.  These
+   enums are to be registered according to the procedures defined in RFC
+   2911 [RFC2911] section 6.1.
+
+   job-collation-type (type2 enum)                 RFC 3381       4.1
+     '1'   'other'                                 RFC 3381       4.1
+     '2'   'unknown'                               RFC 3381       4.1
+     '3'   'uncollated-sheets'                     RFC 3381       4.1
+     '4'   'collated-documents'                    RFC 3381       4.1
+     '5'   'uncollated-documents'                  RFC 3381       4.1
+
+
+
+Hastings, et. al.           Standards Track                    [Page 12]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+7 Internationalization Considerations
+
+   The IPP extensions defined in this document require the same
+   internationalization considerations as any of the Job Template and
+   Job Description attributes defined in IPP/1.1 [RFC2911].
+
+8 Security Considerations
+
+   The IPP extensions defined in this document require the same security
+   considerations as any of the Job Template attributes and Job
+   Description attributes defined in IPP/1.1 [RFC2911].
+
+9 References
+
+9.1 Normative References
+
+   [RFC2910]  Herriot, R., Butler, S., Moore, P. and R. Turner,
+              "Internet Printing Protocol/1.1: Encoding and Transport",
+              RFC 2910, September 2000.
+
+   [RFC2911]  Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
+              Powell, "Internet Printing Protocol/1.1: Model and
+              Semantics", RFC 2911, September 2000.
+
+9.2 Informative References
+
+   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Turner,
+              "Internet Printing Protocol/1.0: Encoding and Transport",
+              RFC 2565, April 1999.
+
+   [RFC2566]  deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
+              Powell, "Internet Printing Protocol/1.0: Model and
+              Semantics", RFC 2566, April 1999.
+
+   [RFC2567]  Wright, F.D., "Design Goals for an Internet Printing
+              Protocol", RFC 2567, April 1999.
+
+   [RFC2568]  Zilles, S., "Rationale for the Structure and Model and
+              Protocol for the Internet Printing Protocol", RFC 2568,
+              April 1999.
+
+   [RFC2569]  Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+              "Mapping between LPD and IPP Protocols", RFC 2569, April
+              1999.
+
+   [RFC2707]  Bergman, R., Hastings, T., Isaacson, S. and H. Lewis, "PWG
+              Job Monitoring MIB - V1", RFC 2707,  November 1999.
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 13]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+   [RFC3196]  Hastings, T., Manros, C., Zehler, P., Kugler, C. and H.
+              Holst, "Internet Printing Protocol/1.1: Implementor's
+              Guide", RFC 3196, November 2001.
+
+   [ipp-ntfy] Herriot, R., Hastings, T., et. al., "Internet Printing
+              Protocol (IPP): Event Notification and Subscriptions",
+              Work in Progress.
+
+10 Description of the Base IPP Documents
+
+   The base set of IPP documents includes:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+      Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+      Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
+   operations have been added to IPP/1.1 [RFC2911, RFC2910].
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF IPP working group's major decisions.
+
+   The "Internet Printing Protocol/1.1: Model and Semantics" document
+   describes a simplified model with abstract objects, their attributes,
+   and their operations.  The model introduces a Printer and a Job.  The
+   Job supports multiple documents per Job.  The model document also
+   addresses how security, internationalization, and directory issues
+   are addressed.
+
+   The "Internet Printing Protocol/1.1: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1 [RFC2616].  It also defines the
+   encoding rules for a new Internet MIME media type called
+   "application/ipp".  This document also defines the rules for
+   transporting over HTTP a message body whose Content-Type is
+
+
+
+Hastings, et. al.           Standards Track                    [Page 14]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+   "application/ipp".  This document defines the 'ipp' scheme for
+   identifying IPP printers and jobs.
+
+   The "Internet Printing Protocol/1.1: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.1 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+   In addition to the base IPP documents, the "Event Notification
+   Specification" document [ipp-ntfy] defines OPTIONAL operations that
+   allow a client to subscribe to printing related events.
+   Subscriptions include "Per-Job subscriptions" and "Per-Printer
+   subscriptions".  Subscriptions are modeled as Subscription objects.
+   Four other operations are defined for subscription objects:  get
+   attributes, get subscriptions, renew a subscription, and cancel a
+   subscription.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 15]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+11 Authors' Addresses
+
+   Tom Hastings
+   Xerox Corporation
+   737 Hawaii St.  ESAE 231
+   El Segundo, CA  90245
+
+   Phone: 310-333-6413
+   Fax: 310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+   Harry Lewis
+   IBM
+   6300 Diagonal Hwy
+   Boulder, CO 80301-9191
+
+   Phone: (303) 924-5337
+   EMail:  harryl@us.ibm.com
+
+   Ron Bergman (Editor)
+   Hitachi Koki Imaging Solutions
+   1757 Tapo Canyon Road
+   Simi Valley, CA 93063-3394
+
+   Phone: 805-578-4421
+   Fax:  805-578-4001
+   EMail: rbergma@hitachi-hkis.com
+
+   IPP Web Page:  http://www.pwg.org/ipp/
+   IPP Mailing List:  ipp@pwg.org
+
+   To subscribe to the ipp mailing list, send the following email:
+
+      1) send it to majordomo@pwg.org
+      2) leave the subject line blank
+      3) put the following two lines in the message body:
+            subscribe ipp
+            end
+
+   Implementers of this specification document are encouraged to join
+   the IPP Mailing List in order to participate in any discussions of
+   clarification issues and review of registration proposals for
+   additional attributes and values.  In order to reduce spam, the
+   mailing list rejects mail from non-subscribers, so you must subscribe
+   to the mailing list in order to send a question or comment to the
+   mailing list.
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 16]
+
+RFC 3381              IPP: Job Progress Attributes        September 2002
+
+
+12 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al.           Standards Track                    [Page 17]
+
diff --git a/standards/rfc3382.txt b/standards/rfc3382.txt
new file mode 100644
index 000000000..4181c5bc5
--- /dev/null
+++ b/standards/rfc3382.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Network Working Group                                           R. deBry
+Request for Comments: 3382                     Utah Valley State College
+Updates: 2910, 2911                                           R. Herriot
+Category: Standards Track                                     Consultant
+                                                             T. Hastings
+                                                                 K. Ocke
+                                                               P. Zehler
+                                                       Xerox Corporation
+                                                          September 2002
+
+
+                   Internet Printing Protocol (IPP):
+                   The 'collection' attribute syntax
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document specifies an OPTIONAL attribute syntax called
+   'collection' for use with the Internet Printing Protocol (IPP/1.0 and
+   IPP/1.1).  A 'collection' is a container holding one or more named
+   values, which are called "member" attributes.  A collection allows
+   data to be grouped like a PostScript dictionary or a Java Map.  This
+   document also specifies the conformance requirements for a definition
+   document that defines a collection attribute.  Finally, this document
+   gives some illustrative example collection attribute definitions that
+   are not intended as actual attribute specifications.
+
+Table of Contents
+
+   1 Introduction.....................................................3
+   1.1 Problem Statement..............................................3
+   1.2 Solution.......................................................3
+   2 Terminology......................................................4
+   2.1 Conformance Terminology........................................4
+   2.2 Other terminology..............................................5
+   3 Definition of a Collection Attribute.............................5
+   3.1 Information to Include.........................................5
+
+
+
+deBry, et. al.              Standards Track                     [Page 1]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   3.2 Nested Collections.............................................9
+   4 Collection Attributes as Attributes in Operations................9
+   4.1 General Rules..................................................9
+   4.2 Unsupported Values.............................................9
+   5 Example definition of a collection attribute.....................9
+   5.1 media-col (collection)........................................10
+   5.1.1 media-color (type3 keyword | name(MAX)......................10
+   5.1.2 media-size (collection).....................................11
+   5.2 media-col-default (collection)................................11
+   5.3 media-col-ready (1setOf collection)...........................12
+   5.4 media-col-supported (1setOf type2 keyword)....................12
+   6 A Second Example Definition Of A Collection Attribute...........12
+   7 Encoding........................................................13
+   7.1 Additional tags defined for representing a collection
+       attribute value...............................................13
+   7.2 Example encoding: "media-col" (collection)....................14
+   8 Legacy issues...................................................20
+   9 IANA Considerations.............................................20
+   10 Internationalization Considerations............................20
+   11 Security Considerations........................................21
+   12 References.....................................................21
+   Appendix A: Encoding Example of a Simple Collection (Informative).22
+   Appendix B: Encoding Example of 1setOf Collection (Informative)...25
+   Appendix C: Encoding Example of Collection containing 1setOf XXX
+               attribute (Informative)...............................31
+   Appendix D: Description of the Base IPP Documents (Informative)...35
+   Authors' Addresses................................................36
+   Full Copyright Statement..........................................38
+
+Table of Tables
+
+   Table 1 - "media-col" member attributes...........................10
+   Table 2 - "media-size" collection member attributes...............11
+   Table 3 - Tags defined for encoding the 'collection' attribute
+             syntax .................................................13
+   Table 4 - Overview Encoding of "media-col" collection.............15
+   Table 5 - Example Encoding of "media-col" collection..............16
+   Table 6 - Overview Encoding of simple collection..................22
+   Table 7 - Example Encoding of simple collection...................22
+   Table 8 - Overview Encoding of 1setOf collection..................25
+   Table 9 - Example Encoding of 1setOf collection...................26
+   Table 10 - Overview Encoding of collection with 1setOf value......31
+   Table 11 - Example Encoding of collection with 1setOf value.......32
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                     [Page 2]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+1 Introduction
+
+   This document is an OPTIONAL extension to IPP/1.0 [RFC2565, RFC2566]
+   and IPP/1.1 [RFC2911, RFC2910].  For a description of the base IPP
+   documents see Appendix D.
+
+1.1 Problem Statement
+
+   The IPP Model and Semantics [RFC2911] supports most of the common
+   data structures that are available in programming languages.  It
+   lacks a mechanism for grouping several attributes of different types.
+   The Java language uses the Map to solve this problem and PostScript
+   has a dictionary.  The new mechanism for grouping attributes together
+   (called 'collection' mechanism) must allow for optional members and
+   the subsequent addition of new members.
+
+   The 'collection' mechanism must be encoded in a manner consistent
+   with existing 1.0 and 1.1 parsing rules (see [RFC2910]).  Current 1.0
+   and 1.1 parsers that don't support the 'collection' mechanism must
+   not confuse collections or parts of a collection they receive with
+   other attributes.
+
+1.2 Solution
+
+   The new mechanism is a new IPP attribute syntax called a
+   'collection'.  As such, each collection value is a value of an
+   attribute whose attribute syntax type is defined to be a
+   'collection'.  Such an attribute is called a collection attribute.
+   The name of the collection attribute serves to identify the
+   collection value in an operation request or response, as with any
+   attribute value.
+
+   The 'collection' attribute syntax is a container holding one or more
+   named values (i.e., attributes), which are called member attributes.
+   Each collection attribute definition document lists the mandatory and
+   optional member attributes of each collection value.  A collection
+   value is similar to an IPP attribute group in a request or a
+   response, such as the operation attributes group.  They both consist
+   of a set of attributes.
+
+   As with any attribute syntax, the document that defines a collection
+   attribute specifies whether the attribute is single-valued
+   (collection) or multi-valued (1setOf collection).  If the attribute
+   is multi-valued (1setOf collection), each collection value MUST be a
+   separate instance of a single definition of a collection, i.e., it
+   MUST have the same member attributes except for OPTIONAL member
+   attributes.  If we view each collection definition as a separate
+   syntax type, this rule continues the IPP/1.1 notion that each
+
+
+
+deBry, et. al.              Standards Track                     [Page 3]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   attribute has a single type or pattern (e.g., "keyword | name" is a
+   pattern).  Without this rule, the supported values would be more
+   difficult to describe and the mechanism defined in item 4 of section
+   3.1 would not be sufficient.
+
+   The name of each member attribute MUST be unique for a collection
+   attribute, but MAY be the same as the name of a member attribute in
+   another collection attribute and/or MAY be the same as the name of an
+   attribute that is not a member of a collection.  The rules for naming
+   member attributes are given in section 3.1.
+
+   Each member attribute can have any attribute syntax type, including
+   'collection', and can be either single-valued or multi-valued.  The
+   length of a collection value is not limited.  However, the length of
+   each member attribute MUST NOT exceed the limit of its attribute
+   syntax.
+
+   The member attributes in a collection MAY be in any order in a
+   request or response.  When a client sends a collection attribute to
+   the Printer, the order that the Printer stores the member attributes
+   of the collection value and the order returned in a response MAY be
+   different from the order sent by the client.
+
+   A collection value MUST NOT contain two or more member attributes
+   with the same attribute name.  Such a collection is mal-formed.
+   Clients MUST NOT submit such malformed requests and Printers MUST NOT
+   return such malformed responses.  If such a malformed request is
+   submitted to a Printer, the Printer MUST (depending on
+   implementation) either (1) reject the request with the 'client-
+   error-bad-request' status code (see [RFC2911] section 13.1.4.1), or
+   (2) accept the request and use only one of each duplicate member
+   attributes.
+
+2 Terminology
+
+   This section defines terminology used throughout this document.
+
+2.1 Conformance Terminology
+
+   Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+   NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+   conformance as defined in BCP 14, RFC 2119 [RFC2119] and [RFC2911],
+   section 12.1.  If an implementation supports the extension defined in
+   this document, then these terms apply; otherwise, they do not.  These
+   terms define conformance to this document only; they do not affect
+   conformance to other documents, unless explicitly stated otherwise.
+
+
+
+
+
+deBry, et. al.              Standards Track                     [Page 4]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+2.2 Other terminology
+
+   This document uses terms such as Job object (or Job), IPP Printer
+   object (or Printer), "operation", "request", response", "attributes",
+   "keywords", and "support".  These terms have special meaning and are
+   defined in the model terminology [RFC2911] section 12.2.  The
+   following additional terms are introduced in this document:
+
+      collection: an attribute syntax in which each attribute value is a
+         set of attributes, called member attributes.
+
+      member attribute: an attribute that is defined to be used as one
+         of the attributes in a collection.
+
+      collection attribute: an attribute whose definition specifies the
+         'collection' attribute syntax and each of the member attributes
+         that MAY occur in a collection attribute value.
+
+3 Definition of a Collection Attribute
+
+   This section describes the requirements for any collection attribute
+   definition.
+
+3.1 Information to Include
+
+   When a specification document defines an "xxx" collection attribute,
+   i.e., an attribute whose attribute syntax type is 'collection' or
+   '1setOf collection'; the definition document MUST include the
+   following aspects of the attribute semantics.  Suppose the "xxx"
+   collection attribute contains N member attributes named  "aaa1",
+   "aaa2", ..., "aaaN" ("aaaI" represents any one of these N member
+   attributes).
+
+   1. The name of the collection attribute MUST be specified  (e.g.,
+      "xxx").  The selection of the name "xxx" MUST follow the same
+      rules for uniqueness as for attributes of any other syntax type,
+      (as defined by IPP/1.1) unless "xxx" is a member attribute of
+      another collection.  Then the selection of the name "xxx" MUST
+      follow the rules for uniqueness defined in item 5a) of this list.
+
+   2. The collection attribute syntax MUST be of type 'collection' or
+      '1setOf collection'.
+
+   3. The context of the collection attribute MUST be specified, i.e.,
+      whether the attribute is an operation attribute, a Job Template
+      attribute, a Job Description attribute, a Printer Description
+      attribute, a member attribute of a particular collection
+      attribute, etc.
+
+
+
+deBry, et. al.              Standards Track                     [Page 5]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   4. An "xxx-supported" attribute MUST be specified and it has one of
+      the following two forms:
+
+      a) "xxx-supported" is a "1setOf collection", which enumerates all
+         of the supported collection values of "xxx".  If a collection
+         of this form contains a nested collection, it MUST be of the
+         same form.
+
+         For example, "media-size-supported" might have the values {{x-
+         dimension:210, y-dimension:297},{x-dimension:297, y-
+         dimension:420}} to show that it supports two values of "media
+         size": A4 (210x297) and A3 (297x420).  It does not support
+         other combinations of "x-dimension" and "y-dimension" member
+         attributes, such as 210x420 or 297x297, and it does not support
+         non-enumerated values, such as 420x595.
+
+      b) "xxx-supported" is a "1setOf type2 keyword", which enumerates
+         the names of all of the member attributes of "xxx": "aaa1",
+         "aaa2", ..., "aaaN".  If a collection of this form contains a
+         nested collection, it MAY be of either form.  See item 5f)
+         below for details on supported values of member attributes.
+
+         For example, "media-col-supported" might have the keyword
+         values: "media-size" and "media-color".
+
+   5. The member attributes MUST be defined.  For each member attribute,
+      the definition document MUST provide the following information:
+
+      a) The member attribute's name (e.g., "aaa") MUST be unique within
+         the collection being defined and MUST either:
+
+           i) reuse the attribute name of another attribute (that is
+              unique across the entire IPP attribute name space) and
+              have the same syntax and semantics as the reused attribute
+              (if the condition of item 4b) above is met).  For example,
+              a member attribute definition could reuse the IPP/1.1
+              "media" attribute.
+
+          ii) potentially occur elsewhere in the entire IPP attribute
+              name space.  (if the condition of item 4a) above is met).
+              For example, a member attribute could be "x-dimension",
+              which could potentially occur in another collection or as
+              an attribute outside of a collection.
+
+         iii) be unique across the entire IPP attribute name space (if
+              the condition of item 4b) above is met).  For example, a
+              member attribute could be "media-color" which must be
+              unique across the entire IPP attribute name space.
+
+
+
+deBry, et. al.              Standards Track                     [Page 6]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      b) Whether the member attribute is REQUIRED or OPTIONAL for the
+         Printer to support.
+
+      c) Whether the member attribute is REQUIRED or OPTIONAL for the
+         client to supply in a request.
+
+      d) The member attribute's syntax type, which can be any attribute
+         syntax, including '1setOf X', 'collection', and '1setOf
+         collection'.  If this attribute name reuses the name of another
+         attribute (case of item a1 above), it MUST have the same
+         attribute syntax, including cardinality (whether or not
+         1setOf).
+
+      e) The semantics of the "aaa" member attribute.  The semantic
+         definition MUST include a description of any constraint or
+         boundary conditions the member attribute places on the
+         associated attribute, especially if the attribute reuses the
+         name of another attribute (case of item a1 above).
+
+      f) The supported values for each "aaaI" member attribute (of the
+         member attributes  "aaa1", "aaa2", ..., "aaaN") is specified by
+         one of two mechanisms.
+
+           i) If "xxx-supported" is a "1setOf collection" (see item 4a)
+              above), the value for each "aaaI" is specified in each
+              collection value of "xxx-supported", in the context of
+              other member attributes.  That is, "xxx-supported"
+              enumerates all supported values of "xxx".
+
+          ii) If the value of "xxx-supported" is a "1setOf type2
+              keyword" (see item 4b) above), the supported values of
+              "aaaI" are the values specified by either i) the "aaaI-
+              supported" attribute or ii) the definition of the member
+              attribute "aaaI" within the document defining the "xxx"
+              attribute.  The values of each member attribute "aaaI" are
+              specified independently of other member attributes, though
+              a Printer is not required to support all combinations of
+              supported values.
+
+              For example, "media-col-supported" might have the keyword
+              values: "media-size" and "media-color".  Using the first
+              method for defining supported values (an "aaaI-supported"
+              attribute), the collection values of "media-col" are
+              combinations of values of "media-size-supported" and
+              "media-color-supported".  If "media-size-supported" has
+              the values of '210x297' and '297x420' and "media-color-
+              supported" has the values of 'white' and 'pink', the
+
+
+
+
+deBry, et. al.              Standards Track                     [Page 7]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+              Printer might support only the combinations 'white-
+              210x297', 'pink-210x297' and 'white-297x420', and not
+              'pink-297x420'.
+
+              If a collection contains a member "aaaI", whose syntax
+              type is "text", the supported values would probably be
+              defined by the definition of "xxx" rather than by the
+              attribute "aaaI-supported".
+
+      g) the default value of each "aaaI" member attribute if it is
+         OPTIONAL for a client to supply the "aaa" member attribute in a
+         request.  The default value is specified by the attribute's
+         definition within a document and MUST be one of the following:
+
+           i) a fixed default
+
+          ii) a mechanism by which the Printer determines default
+
+         iii) an indefinite default that is left to the implementation.
+
+          iv) an attribute that the Printer uses to determine the
+              default
+
+   6. The default value of "xxx", if a client does not supply it.  The
+      default value is specified by the attribute's definition within a
+      document and MUST be one of the following:
+
+      a) a fixed default
+
+      b) a mechanism by which the Printer determines default
+
+      c) an indefinite default that is left to the implementation
+
+      d) a Printer attribute "xxx-default" which is a collection with
+         the same member attributes as "xxx".  If optional member
+         attributes are absent, the Printer uses the defaulting rules of
+         item 5g) above.
+
+   7. The "xxx-ready (1setOf collection)" attribute, if human
+      intervention is required to make many of the supported values
+      available.  For example, "media-col" is an attribute which has a
+      "ready" attribute.  Most attributes do not have a "ready"
+      attribute.
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                     [Page 8]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+3.2 Nested Collections
+
+   A member attribute may have a syntax type of 'collection' or '1setOf
+   collection', in which case it is called a nested collection
+   attribute.  The rules for a nested collection attribute are the same
+   as for a collection attribute as specified in section 3.1.
+
+4 Collection Attributes as Attributes in Operations
+
+4.1 General Rules
+
+   A collection value is like any other IPP/1.1 value, except that it is
+   structured.  The rules for attributes with collection values are the
+   same as for attributes of any other syntax type (see IPP/1.1), be
+   they in any group of a request of a response.
+
+4.2 Unsupported Values
+
+   The rules for returning an unsupported collection attribute are an
+   extension to the current rules:
+
+   1. If the entire collection attribute is unsupported, then the
+      Printer returns just the collection attribute name with the
+      'unsupported' out-of-band value (see the beginning of [RFC2911]
+      section 4.1) in the Unsupported Attributes Group.
+
+   2. If a collection contains unrecognized, unsupported member
+      attributes and/or conflicting values, the attribute returned in
+      the Unsupported Group is a collection containing the unrecognized,
+      unsupported member attributes, and/or conflicting values.  The
+      unrecognized member attributes have an out-of-band value of
+      'unsupported' (see the beginning of [RFC2911] section 4.1).  The
+      unsupported member attributes and conflicting values have their
+      unsupported or conflicting values.
+
+5 Example definition of a collection attribute
+
+   In some printing environments, it is desirable to allow the client to
+   select the media by its properties, e.g., weight, color, size, etc.,
+   instead of by name.  In IPP/1.1 (see [RFC2911]), the "media (type3
+   keyword | name) Job Template attribute allows selection by name.  It
+   is tempting to extend the "media" attribute syntax to include
+   "collection", but then existing clients could not understand default
+   or supported media values that use the collection value.  To preserve
+   interoperability, a new attribute MUST BE added, e.g., "media-col
+   (collection)".  The following subsections contain a sample definition
+   of a simplified "media-col" attribute.  The definition follows the
+   rules in section 3.
+
+
+
+deBry, et. al.              Standards Track                     [Page 9]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   All of the example attribute definitions in this document are
+   illustrative examples, rather than actual definitions.  These
+   examples are intended to illustrate how to define collection
+   attributes.  Other documents MUST define collection attributes for
+   use in actual interchange.  Such definitions may be very similar to
+   the examples in this document, since we attempted to pick useful
+   examples.
+
+   Note: we picked the name "media-col" because the name "media" is
+   already in use.  Ordinarily the collection attribute would have a
+   name like any other attribute and would not end in "col".
+
+   The member attributes of "media-col" attribute ("media-color (type 3
+   keyword)" and "media-size (collection)") both follow the naming rules
+   of item 4a3 of section 3, i.e., the names are unique across the
+   entire IPP attribute name space.  The member attributes of the
+   "media-size (collection)" member attribute ("x-dimension
+   (integer(0:MAX))" and "y-dimension (integer(0:MAX))") both follow the
+   naming rules of item 4a2 of section 3, i.e., they potentially occur
+   elsewhere in the IPP attribute name space.
+
+5.1 media-col (collection)
+
+   The "media-col" (collection) attribute augments the IPP/1.1 [RFC2911]
+   "media" attribute.  This collection attribute enables a client end
+   user to submit a list of media characteristics to the Printer.  When
+   the client specifies media using the "media-col" collection
+   attribute, the Printer object MUST match the requested media exactly.
+   The 'collection' consists of the following member attributes:
+
+                  Table 1 - "media-col" member attributes
+
+        Attribute name  attribute syntax             request  Printer
+                                                              Support
+
+        media-color     type3 keyword | name (MAX)   MAY      MUST
+
+        media-size      collection                   MUST     MUST
+
+   The definitions for the member attributes is given in the following
+   sub-sections:
+
+5.1.1 media-color (type3 keyword | name(MAX)
+
+   This member attribute identifies the color of the media.  Valid
+   values are 'red', 'white' and 'blue'.
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 10]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   The "media-color-supported" (1setOf (type3 keyword | name(MAX)))
+   Printer attribute identifies the values of this "media-color" member
+   attribute that the Printer supports, i.e., the colors supported.
+
+   If the client omits this member attribute, the Printer determines the
+   value in an implementation dependent manner.
+
+5.1.2 media-size (collection)
+
+   This member attribute identifies the size of the media.  The
+   'collection' consists of the member attributes shown in Table 2:
+
+            Table 2 - "media-size" collection member attributes
+
+        Attribute name    attribute syntax      request   Printer
+                                                          Support
+
+        x-dimension       integer (0:MAX)       MUST      MUST
+
+        y-dimension       integer (0:MAX)       MUST      MUST
+
+   The definitions for the member attributes are given in the following
+   sub-sections:
+
+5.1.2.1  x-dimension (integer(0:MAX))
+
+   This attribute identifies the width of the media in inch units along
+   the X axis.
+
+5.1.2.2  y-dimension (integer(0:MAX))
+
+   This attribute identifies the height of the media in inch units along
+   the Y axis.
+
+   The "media-size-supported" (1setOf collection) Printer attribute
+   identifies the values of this "media-size" member attribute that the
+   Printer supports, i.e., the size combinations supported.  The names
+   of the member attributes are the same as the member attributes of the
+   "media-size" collection attribute, namely "x-dimension", and "y-
+   dimension", since they have the same attribute syntax and the same
+   semantics.
+
+5.2 media-col-default (collection)
+
+   The "media-col-default" Printer attribute specifies the media that
+   the Printer uses, if any, if the client omits the "media-col" and
+   "media".  Job Template attributes in the Job Creation operation and
+   the PDL do not include a media specification.  The member attributes
+
+
+
+deBry, et. al.              Standards Track                    [Page 11]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   are defined in Table 1.  A Printer MUST support the same member
+   attributes for this default collection attribute as it supports for
+   the corresponding "media-col" Job Template attribute.
+
+5.3 media-col-ready (1setOf collection)
+
+   The "media-col-ready" Printer attribute identifies the media that are
+   available for use without human intervention, i.e., the media that
+   are ready to be used without human intervention.  The collection
+   value MUST have all of the member attributes that are supported in
+   Table 1.
+
+5.4 media-col-supported (1setOf type2 keyword)
+
+   The "media-col-supported" Printer attribute identifies the keyword
+   names of the member attributes supported in the "media-col"
+   collection Job Template attribute, i.e., the keyword names of the
+   member attributes in Table 1 that the Printer supports.
+
+6 A Second Example Definition Of A Collection Attribute
+
+   All of the example attribute definitions in this document are
+   illustrative examples, rather than actual definitions.  These
+   examples are intended to illustrate how to define collection
+   attributes.  Other documents MUST define collection attributes for
+   use in actual interchange.  Such definitions may be very similar to
+   the examples in this document, since we attempted to pick useful
+   examples.
+
+   In some printing environments, it is desirable to allow the client to
+   select the media for the job start sheet.  The reason for not adding
+   the 'collection' attribute syntax to the existing "job-sheets" Job
+   Template attribute is the same as for "media".  Instead, a new Job
+   Template attribute is introduced, e.g., "job-sheet-col (collection)".
+
+   The member attributes of "job-sheet-col" attribute ("job-sheets (type
+   3 keyword)" and "media (type3 keyword | name)") both follow the
+   naming rules of item 4a1 of section 3, i.e., they reuse existing IPP
+   attributes.  According to the rules, their supported values come from
+   the existing IPP attributes: "job-sheets-supported" and "media-
+   supported".  However, their default values do not come from "job-
+   sheets-default" and "media-default", respectively.  Rather, the
+   definition of "job-sheet-col" says that "job-sheets (type 3 keyword)"
+   is required and if "media (type3 keyword | name)" is absent, the
+   Printer uses the same media as the rest of the job uses.
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 12]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   If "job-sheet-col" attribute was defined to contain the member
+   attribute "job-sheet-media (type3 keyword | name)" instead of "media
+   (type3 keyword | name)", then the definition would also have to
+   specify a "job-sheet-media-supported (1setOf (type3 keyword | name))"
+   whose values would be independent of "media-supported (1setOf (type3
+   keyword | name))" and would be set separately by a System
+   Administrator.
+
+   The actual text for the definition of the attribute is left as an
+   exercise for the reader.
+
+7 Encoding
+
+   This section defines the additional encoding tags used according to
+   [RFC2910] and gives an example of their use.  The encoding tags
+   defined in this document MUST be used by all collection attributes
+   defined in other documents.  However, the example of their use is
+   illustrative only.
+
+7.1 Additional tags defined for representing a collection attribute
+    value
+
+   The 'collection' attribute syntax uses the tags defined in Table 3.
+
+   Table 3 - Tags defined for encoding the 'collection' attribute syntax
+
+        Tag name         Tag
+                         value     Meaning
+
+        begCollection    0x34      Begin the collection attribute value.
+
+        endCollection    0x37      End the collection attribute value.
+
+        memberAttrName   0x4A      The value is the name of the
+                                   collection member attribute
+
+   When encoding a collection attribute "xxx" that contains an attribute
+   "aaa" and is not inside another collection, the encoding follows
+   these rules:
+
+   1. The beginning of the collection is indicated with a value tag that
+      MUST be syntax type 'begCollection' (0x34) with a name length and
+      Name field that represent the name of the collection attribute
+      ("xxx") as with any attribute, followed by a value.  The Printer
+      MAY ignore the value and its length MAY be 0.  In the future,
+      however, this field MAY contain useful information, such as the
+      collection name (cf. the name of a C struct).
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 13]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   2. Each member attribute is encoded as a sequence of two or more
+      values that appear to be part of a single multi-valued attribute,
+      i.e., 1setOf.  The first value after the 'begCollection' value has
+      the attribute syntax, 'memberAttrName' (0x4A), and its value holds
+      the name of the first member attribute (e.g., "aaa").  The second
+      value holds the first member's attribute value, which can be of
+      any attribute syntax, except 'memberAttrName' or 'endCollection'.
+      If the first member's attribute value is multi-valued, the third
+      value holds the second value of the first member's value.
+      Otherwise, the third value holds the name of second member
+      attribute (e.g., "bbb"), and its attribute syntax is
+      'memberAttrName'.  In this case, the fourth member's value is the
+      value of "bbb".
+
+      Note that the technique of encoding a 'collection' as a '1setOf'
+      makes it easy for a Printer that doesn't support a particular
+      collection attribute (or the collection attribute syntax at all)
+      to simply skip over the entire collection value.
+
+   3. The end of the collection is indicated with a value tag that MUST
+      be syntax type 'endCollection' (e.g., 0x37) and MAY have a zero
+      name length and a zero value length.  In the future, this field
+      MAY contain useful information, such as the collection name that
+      matches the one in the 'begCollection' .
+
+   4. It is valid to have a member attribute that is itself, a
+      collection attribute, i.e., collections can be nested within
+      collections.  This is represented by the occurrence of a member
+      attribute that is of attribute syntax type 'begCollection'.  Such
+      a collection is terminated by a matching 'endCollection'.  The
+      name of such a member attribute is in the immediately preceding
+      value, whose syntax type is 'memberAttrName'.
+
+   5. It is valid for a collection attribute to be multi-valued, i.e.,
+      have more than one collection value.  If the next attribute
+      immediately following the 'endCollection' has a zero name length
+      and a tag of 'begCollection', then the collection attribute is a
+      multi-valued collection, as with any attribute.  This statement
+      applies to collections within collections and collections that are
+      not in collections.
+
+7.2 Example encoding: "media-col" (collection)
+
+   The collection specified in section 5 is used for the encoding
+   example shown in Table 5.  The example also shows nested collections,
+   since the "media-size" member attribute is a 'collection.  The
+   encoding example represents a blue 4x6-index card and takes 216
+   octets.  The Appendices contain more complex examples.
+
+
+
+deBry, et. al.              Standards Track                    [Page 14]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   Additional examples have been included in the appendices.
+
+   The overall structure of the two collection values can be pictorially
+   represented as:
+
+      "media-col" =
+        {  "media-color" =  'blue';
+           "media-size" =
+           {    "x-dimension" = 6;
+                "y-dimension" = 4
+             }
+        },
+
+   The full encoding is in table 5.  A simplified view of the encoding
+   looks like this:
+
+           Table 4 - Overview Encoding of "media-col" collection
+
+      Tag Value             Name                  Value
+
+      begCollection         media-col             ""
+
+      memberAttrName        ""                    media-color
+
+      keyword               ""                    blue
+
+      memberAttrName        ""                    media-size
+
+      begCollection         ""                    ""
+
+      memberAttrName        ""                    x-dimension
+
+      integer               ""                    6
+
+      memberAttrName        ""                    y-dimension
+
+      integer               ""                    4
+
+      endCollection         ""                    ""
+
+      endCollection         ""                    ""
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 15]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+           Table 5 - Example Encoding of "media-col" collection
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x34         begCollection   value-tag  beginning of the "media-
+                                              col" collection attribute
+
+      0x0009                       name-      length of (collection)
+                                   length     attribute name
+
+      media-col    media-col       name       name of (collection)
+                                              attribute
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x4A         memberAttrName  value-tag  starts a new member
+                                              attribute: "media-color"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of "media-color"
+                                   length     keyword
+
+      media-color  media-color     value      value is name of 1st
+                                              member attribute
+
+
+      0x44         keyword type    value-tag  keyword type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 16]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x0004                       value-
+                                   length
+
+      blue         blue            value      value of 1st member
+                                              attribute
+
+
+      0x4A         memberAttrName  value-tag  starts a new member
+                                              attribute: "media-size"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000A                       value-     length of "media-size"
+                                   length     keyword
+
+      media-size   media-size      value      Name of 2nd member
+                                              attribute
+
+      0x34         begCollection   value-tag  Beginning of the "media-
+                                              size" collection attribute
+                                              which is a sub-collection
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0000                       value-     collection attribute names
+                                   length     have no value
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x4A         memberAttrName  value-tag  starts a new member
+                                              attribute: "x-dimension"
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 17]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of "x-dimension"
+                                   length     keyword
+
+      x-dimension  x-dimension     value      name of  1st sub-
+                                              collection member
+                                              attribute
+
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0006                       value      value of  1st sub-
+                                              collection member
+                                              attribute
+
+      0x4A         memberAttrName  value-tag  starts a new member
+                                              attribute: "y-dimension"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of the "y-
+                                   length     dimension" keyword
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 18]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      y-dimension  y-dimension     value      name of  2nd sub-
+                                              collection member
+                                              attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0004                       value      value of  2nd sub-
+                                              collection member
+                                              attribute
+
+      0x37         endCollection   value-tag  end of the sub-collection
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x37         endCollection   value-tag  end of the 1st collection
+                                              value in 1setOf
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 19]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+8 Legacy issues
+
+   IPP 1.x Printers and Clients will gracefully ignore collections and
+   its member attributes if it does not understand the collection.  The
+   begCollection and endCollection elements each look like an attribute
+   with an attribute syntax that the recipient doesn't support and so
+   should ignore the entire attribute.  The individual member attributes
+   and their values will look like a 1setOf values of the collection
+   attribute, so that the Printer simply ignores the entire attribute
+   and all of its values.  Returning unsupported attributes is also
+   simple, since only the name of the collection attribute is returned
+   with the 'unsupported' out-of-band value (see section 4.2).
+
+9 IANA Considerations
+
+   The following table provides registration for the 'collection'
+   attribute syntax defined in this document.  This is to be registered
+   according to the procedures in RFC 2911 [RFC2911] section 6.3.
+
+   Tag value:      Attribute Syntaxes:            Ref.      Section:
+   collection                                     RFC 3382         3
+     0x34          begCollection                  RFC 3382       7.1
+     0x37          endCollection                  RFC 3382       7.1
+     0x4A          memberAttrName                 RFC 3382       7.1
+
+   The resulting attribute syntax registration will be published in the
+   http://www.iana.org/assignments/ipp-registrations registry.
+
+10 Internationalization Considerations
+
+   This attribute syntax by itself has no impact on
+   internationalization.  However, the member attributes that are
+   subsequently defined for use in a collection may have
+   internationalization considerations, as may any attribute, according
+   to [RFC2911].
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 20]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+11 Security Considerations
+
+   This attribute syntax causes no more security concerns than any other
+   attribute syntax.  It is only the attributes that are subsequently
+   defined, to use this or any other attribute syntax, that may have
+   security concerns, depending on the semantics of the attribute,
+   according to [RFC2911].
+
+12 References
+
+12.1 Normative References
+
+   [RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
+             Printing Protocol/1.1: Encoding and Transport", RFC 2910,
+             September 2000.
+
+   [RFC2911] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P.
+             Powell, "Internet Printing Protocol/1.1: Model and
+             Semantics", RFC 2911, September 2000.
+
+12.2 Informative References
+
+   [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
+             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+             April 1999.
+
+   [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
+             Powell, "Internet Printing Protocol/1.0: Model and
+             Semantics", RFC 2566, April 1999.
+
+   [RFC2567] Wright, D., "Design Goals for an Internet Printing
+             Protocol", RFC 2567, April 1999.
+
+   [RFC2568] Zilles, S., "Rationale for the Structure and Model and
+             Protocol for the Internet Printing Protocol", RFC 2568,
+             April 1999.
+
+   [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+             "Mapping between LPD and IPP Protocols", RFC 2569, April
+             1999.
+
+   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
+             L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
+             Protocol - HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C. and H.
+             Holst, "Internet Printing Protocol/1.1: Implementor's
+             Guide", RFC 3196, November 2001.
+
+
+
+deBry, et. al.              Standards Track                    [Page 21]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+Appendix A: Encoding Example of a Simple Collection (Informative)
+
+   The overall structure of the collection value can be pictorially
+   represented as:
+
+      "media-size" =
+        {  "x-dimension" = 6;
+           "y-dimension" = 4
+        }
+
+   A simplified view of the encoding would look like this:
+
+             Table 6 - Overview Encoding of simple collection
+
+      Tag Value             Name                  Value
+
+      begCollection         media-size            ""
+
+      memberAttrName        ""                    x-dimension
+
+      integer               ""                    6
+
+      memberAttrName        ""                    y-dimension
+
+      integer               ""                    4
+
+      endCollection         ""                    ""
+
+      Note: "" represents a name or value whose length is 0.
+
+              Table 7 - Example Encoding of simple collection
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x34         begCollection   value-tag  beginning of the "media-
+                                              size" collection attribute
+
+      0x000A                       name-      length of (collection)
+                                   length     attribute name
+
+      media-size   media-size      name       name of (collection)
+                                              attribute
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 22]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x4A         memberAttrName  value-tag  starts member attribute:
+                                              "x-dimension"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of "x-dimension"
+                                   length     keyword
+
+      x-dimension  x-dimension     value      name of  1st collection
+                                              member attribute
+
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0006                       value      value of  1st collection
+                                              member attribute
+
+      0x4A         memberAttrName  value-tag  starts a new member
+                                              attribute: "y-dimension"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 23]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x000B                       value-     length of the "y-
+                                   length     dimension" keyword
+
+      y-dimension  y-dimension     value      name of  2nd collection
+                                              member attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf for
+                                   length     media-size
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0004                       value      value of  2nd collection
+                                              member attribute
+
+      0x37         endCollection   value-tag  end of the collection
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 24]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+Appendix B: Encoding Example of 1setOf Collection (Informative)
+
+   The overall structure of the collection value can be pictorially
+   represented as:
+
+      "media-size-supported" =
+        {  "x-dimension" = 6;
+           "y-dimension" = 4
+        },
+        {  "x-dimension" = 3;
+           "y-dimension" = 5
+        };
+
+   A simplified view of the encoding would look like this:
+
+             Table 8 - Overview Encoding of 1setOf collection
+
+      Tag Value              Name                 Value
+
+      begCollection          media-size-          ""
+                             supported
+
+      memberAttrName         ""                   x-dimension
+
+      integer                ""                   6
+
+      memberAttrName         ""                   y-dimension
+
+      integer                ""                   4
+
+      endCollection          ""                   ""
+
+      begCollection          ""                   ""
+
+      memberAttrName         ""                   x-dimension
+
+      integer                ""                   3
+
+      memberAttrName         ""                   y-dimension
+
+      integer                ""                   5
+
+      endCollection          ""                   ""
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 25]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+              Table 9 - Example Encoding of 1setOf collection
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x34         begCollection   value-tag  beginning of the "media-
+                                              size-supported (1setOf
+                                              collection" attribute
+
+      0x00014                      name-      length of (collection)
+                                   length     attribute name
+
+      media-size-  media-size-     name       name of (collection)
+      supported    supported                  attribute
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x4A         memberAttrName  value-tag  starts member attribute:
+                                              "x-dimension"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of "x-dimension"
+                                   length     keyword
+
+      x-dimension  x-dimension     value      name of  1st collection
+                                              member attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 26]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0006                       value      value of  1st collection
+                                              member attribute
+
+      0x4A         memberAttrName  value-tag  starts member attribute:
+                                              "y-dimension"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of the "y-
+                                   length     dimension" keyword
+
+      y-dimension  y-dimension     value      name of  2nd collection
+                                              member attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0004                       value      value of  2nd collection
+                                              member attribute
+
+      0x37         endCollection   value-tag  end of the collection
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 27]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x34         begCollection   value-tag  beginning of the 2nd
+                                              member of the 1setOf
+                                              "sizes-avail " collection
+                                              attribute
+
+      0x0000                       name-      Zero length name indicates
+                                   length     this is member of previous
+                                              attribute
+
+                                   name       no name (since name-length
+                                              was 0)
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x4A         memberAttrName  value-tag  starts member attribute:
+                                              "x-dimension"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of "x-dimension"
+                                   length     keyword
+
+      x-dimension  x-dimension     value      name of  1st collection
+                                              member attribute
+
+      0x21         integer type    value-tag  attribute type
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 28]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0003                       value      value of  1st collection
+                                              member attribute
+
+      0x4A         memberAttrName  value-tag  starts member attribute:
+                                              "y-dimension"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x000B                       value-     length of the "y-
+                                   length     dimension" keyword
+
+      y-dimension  y-dimension     value      name of  2nd collection
+                                              member attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0005                       value      value of  2nd collection
+                                              member attribute
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 29]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x37         endCollection   value-tag  end of the 1setOf
+                                              collection value
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 30]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+Appendix C: Encoding Example of Collection containing 1setOf XXX
+            attribute (Informative)
+
+   The overall structure of the collection value can be pictorially
+   represented as:
+
+      "wagons" =
+        {  "colors" = red, blue;
+           "sizes" = 4, 6, 8
+        }
+
+   A simplified view of the encoding would look like this:
+
+       Table 10 - Overview Encoding of collection with 1setOf value
+
+            Tag Value                Name                Value
+
+            begCollection            wagons              ""
+
+            memberAttrName           ""                  colors
+
+            keyword                  ""                  red
+
+            keyword                  ""                  blue
+
+            memberAttrName           ""                  sizes
+
+            integer                  ""                  4
+
+            integer                  ""                  6
+
+            integer                  ""                  8
+
+            endCollection            ""                  ""
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 31]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+        Table 11 - Example Encoding of collection with 1setOf value
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x34         begCollection   value-tag  beginning of the "wagons"
+                                              collection attribute
+
+      0x0005                       name-      length of (collection)
+                                   length     attribute name
+
+      wagons       wagons          name       name of (collection)
+                                              attribute
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+                                              no value (since value-
+                                              length was 0)
+
+      0x4A         memberAttrName  value-tag  starts a new member
+                                              attribute: "colors"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0006                       value-     length of "colors" keyword
+                                   length
+
+      colors       colors          value      value is name of 1st
+                                              member attribute
+
+      0x44         keyword type    value-tag  keyword type
+
+      0x0000                       name-      0 indicates 1setOf wagons
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-
+                                   length
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 32]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      blue         blue            value      value of 1st member
+                                              attribute
+
+      0x44         keyword type    value-tag  keyword type
+
+      0x0000                       name-      0 indicates 1setOf wagons
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0003                       value-
+                                   length
+
+      red          red             value      value of 1st member
+                                              attribute
+
+      0x4A         memberAttrName  value-tag  starts a new member
+                                              attribute: "sizes"
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0005                       value-     length of "length-avail"
+                                   length     keyword
+
+      sizes        sizes           value      Name of 2nd member
+                                              attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf wagons
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 33]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+      0x0004                       value      1st value for 1setOf
+                                              integer attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-
+                                   length     length of an integer = 4
+
+      0x0006                       value      2nd value for 1setOf
+                                              integer attribute
+
+      0x21         integer type    value-tag  attribute type
+
+      0x0000                       name-      0 indicates 1setOf
+                                   length
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0004                       value-     length of an integer = 4
+                                   length
+
+      0x0008                       value      3rd  value for 1setOf
+                                              integer attribute
+
+      0x37         endCollection   value-tag  end of the collection
+
+      0x0000                       name-      defined to be 0 for this
+                                   length     type, so part of 1setOf
+
+                                              no name (since name-length
+                                              was 0)
+
+      0x0000                       value-     defined to be 0 for this
+                                   length     type
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 34]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+      Octets       Symbolic Value  Protocol   comments
+                                   field
+
+                                              no value (since value-
+                                              length was 0)
+
+Appendix D: Description of the Base IPP Documents (Informative)
+
+   The base set of IPP documents includes:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+      Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+      Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
+   operations have been added to IPP/1.1 [RFC2911, RFC2910].
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF IPP working group's major decisions.
+
+   The "Internet Printing Protocol/1.1: Model and Semantics" document
+   describes a simplified model with abstract objects, their attributes,
+   and their operations.  The model introduces a Printer and a Job.  The
+   Job supports multiple documents per Job.  The model document also
+   addresses how security, internationalization, and directory issues
+   are addressed.
+
+   The "Internet Printing Protocol/1.1: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1 [RFC2616].  It also defines the
+   encoding rules for a new Internet MIME media type called
+   "application/ipp".  This document also defines the rules for
+   transporting over HTTP a message body whose Content-Type is
+   "application/ipp".  This document defines the 'ipp' scheme for
+   identifying IPP printers and jobs.
+
+
+
+deBry, et. al.              Standards Track                    [Page 35]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   The "Internet Printing Protocol/1.1: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.1 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+Authors' Addresses
+
+   Roger deBry
+   Utah Valley State College
+   Orem, UT 84058
+
+   Phone: (801) 222-8000
+   EMail: debryro@uvsc.edu
+
+
+   Tom Hastings
+   Xerox Corporation
+   737 Hawaii St.  ESAE 231
+   El Segundo, CA  90245
+
+   Phone: 310-333-6413
+   Fax: 310-333-5514
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Robert Herriot
+   Consultant
+   706 Colorado Ave
+   Palo Alto, CA 94303
+
+   Phone: 650-327-4466
+   Fax: 650-327-4466
+   EMail: bob@herriot.com
+
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 36]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+   Kirk Ocke
+   Xerox Corp.
+   800 Phillips Rd
+   M/S 128-30E
+   Webster, NY 14580
+
+   Phone: (585) 442-4832
+   EMail: KOcke@crt.xerox.com
+
+
+   Peter Zehler
+   Xerox Corp.
+   800 Phillips Rd
+   M/S 128-30E
+   Webster, NY 14580
+
+   Phone: (585) 265-8755
+   EMail: PZehler@crt.xerox.com
+
+   IPP Web Page:  http://www.pwg.org/ipp/
+   IPP Mailing List:  ipp@pwg.org
+
+   To subscribe to the ipp mailing list, send the following email:
+
+     1) send it to majordomo@pwg.org
+     2) leave the subject line blank
+     3) put the following two lines in the message body:
+          subscribe ipp
+          end
+
+   Implementers of this specification document are encouraged to join
+   the IPP Mailing List in order to participate in any discussions of
+   clarification issues and review of registration proposals for
+   additional attributes and values.  In order to reduce spam the
+   mailing list rejects mail from non-subscribers, so you must subscribe
+   to the mailing list in order to send a question or comment to the
+   mailing list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 37]
+
+RFC 3382         IPP: The 'collection' attribute syntax   September 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et. al.              Standards Track                    [Page 38]
+
diff --git a/standards/rfc3510.txt b/standards/rfc3510.txt
new file mode 100644
index 000000000..c61ce5f2b
--- /dev/null
+++ b/standards/rfc3510.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                         R. Herriot
+Request for Comments: 3510                                   I. McDonald
+Updates: 2910                                            High North Inc.
+Category: Standards Track                                     April 2003
+
+
+                    Internet Printing Protocol/1.1:
+                             IPP URL Scheme
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This memo defines the "ipp" URL (Uniform Resource Locator) scheme.
+   This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by
+   expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910.
+   An "ipp" URL is used to specify the network location of a print
+   service that supports the IPP Protocol (RFC 2910), or of a network
+   resource (for example, a print job) managed by such a print service.
+
+Table of Contents
+
+   1.  Introduction ...............................................  2
+   2.  Terminology ................................................  3
+       2.1.  Conformance Terminology ..............................  3
+       2.2.  Model Terminology ....................................  3
+   3.  IPP Model for Printers and Jobs ............................  3
+   4.  IPP URL Scheme .............................................  4
+       4.1.  IPP URL Scheme Applicability .........................  4
+       4.2.  IPP URL Scheme Associated Port .......................  4
+       4.3.  IPP URL Scheme Associated MIME Type ..................  5
+       4.4.  IPP URL Scheme Character Encoding ....................  5
+       4.5.  IPP URL Scheme Syntax ................................  5
+       4.6.  IPP URL Examples .....................................  6
+             4.6.1.  IPP Printer URL Examples .....................  6
+             4.6.2.  IPP Job URL Examples .........................  6
+       4.7.  IPP URL Comparisons ..................................  7
+
+
+
+
+Herriot & McDonald          Standards Track                     [Page 1]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+   5.  Conformance Requirements ...................................  8
+       5.1.  IPP Client Conformance Requirements ..................  8
+       5.2.  IPP Printer Conformance Requirements .................  8
+   6.  IANA Considerations ........................................  9
+   7.  Internationalization Considerations ........................  9
+   8.  Security Considerations ....................................  9
+   9.  Intellectual Property Rights ............................... 10
+   10. Normative References ....................................... 11
+   11. Informative References ..................................... 11
+   12. Acknowledgments ............................................ 12
+   Appendix A - Registration of "ipp" URL Scheme .................. 13
+   Authors' Addresses ............................................. 15
+   Full Copyright Statement ....................................... 16
+
+1.  Introduction
+
+   This memo conforms to all of the requirements in Registration
+   Procedures for URL Scheme Names [RFC2717].  This memo also follows
+   all of the recommendations in Guidelines for new URL Schemes
+   [RFC2718].
+
+   See section 1, "Introduction", of [RFC2911] and section 1,
+   "Introduction", of [RFC3196] for overview information about IPP.  See
+   section 10, "Description of the Base IPP Documents", of [RFC3196] for
+   a full description of the IPP document set.
+
+   This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by
+   expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910,
+   but does not define any new parameters or other new extensions to the
+   syntax of IPP URLs.
+
+   The IPP URL scheme defined in this document is based on the ABNF for
+   the HTTP URL scheme defined in HTTP [RFC2616], which in turn is
+   derived from the URI Generic Syntax [RFC2396] and further updated for
+   IPv6 by [RFC2732].  An IPP URL is transformed into an HTTP URL
+   according to the rules specified in section 5 of IPP Protocol
+   [RFC2910].
+
+   This document defines IPP URL scheme applicability, associated port
+   (631), associated MIME type ("application/ipp"), character encoding,
+   and syntax.
+
+   This document is laid out as follows:
+
+   -  Section 2 defines the terminology used throughout the document.
+
+   -  Section 3 supplies references to the IPP Printer and IPP Job
+      object model defined in IPP Model [RFC2911].
+
+
+
+Herriot & McDonald          Standards Track                     [Page 2]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+   -  Section 4 specifies the IPP URL scheme.
+
+   -  Section 5 specifies the conformance requirements for IPP Clients
+      and IPP Printers that claim conformance to this document.
+
+   -  Sections 6, 7, and 8 specify IANA, internationalization, and
+      security considerations.
+
+   -  Sections 9, 10, 11, 12, and 13 specify normative references,
+      informative references, acknowledgements, authors' addresses, and
+      full IETF copyright statement.
+
+   -  Section 14 (Appendix A) is a completed registration template for
+      the IPP URL Scheme (see section 6.0 of [RFC2717]).
+
+2.  Terminology
+
+      This specification document uses the terminology defined in this
+      section.
+
+2.1.  Conformance Terminology
+
+      The uppercase terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
+      "SHALL NOT" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in
+      [RFC2119].  These terms are used to specify conformance
+      requirements for all implementations (both print clients and print
+      services) of this specification.
+
+2.2.  Model Terminology
+
+      See section 12.2, "Model Terminology", in IPP Model [RFC2911].
+
+3.  IPP Model for Printers and Jobs
+
+      See section 2, "IPP Objects", section 2.1, "Printer Object", and
+      section 2.2, "Job Object", in [RFC2911] for a full description of
+      the IPP object model and terminology.
+
+      In this document, "IPP Client" means the software (on some
+      hardware platform) that submits, monitors, and/or manages print
+      jobs via the IPP Protocol [RFC2910] to a print spooler, print
+      gateway, or physical printing device.
+
+
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                     [Page 3]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+      In this document, "IPP Printer object" means the software (on some
+      hardware platform) that receives print jobs and/or printer/job
+      operations via the IPP Protocol [RFC2910] from an "IPP Client".
+
+      In this document, "IPP Printer" is a synonym for "IPP Printer
+      object".
+
+      In this document, "IPP Job object" means the set of attributes and
+      documents for one print job instantiated on an "IPP Printer".
+
+      In this document, "IPP Job" is a synonym for "IPP Job object".
+
+      In this document, "IPP URL" means a URL with the "ipp" scheme.
+
+      Note:  In this document, "IPP URL" is a synonym for "ipp-URL" (in
+      section 4, "IPP URL Scheme", of this document) and "ipp-URL" (in
+      section 5, "IPP URL Scheme", of [RFC2910]).
+
+4.  IPP URL Scheme
+
+4.1.  IPP URL Scheme Applicability
+
+      The "ipp" URL scheme MUST only be used to specify absolute URLs
+      (relative IPP URLs are not allowed) for IPP print services and
+      their associated network resources.  The "ipp" URL scheme MUST
+      only be used to specify the use of the abstract protocol defined
+      in IPP Model [RFC2911] over an HTTP [RFC2616] transport, as
+      defined in IPP Protocol [RFC2910].  Any other transport binding
+      for the abstract protocol defined in IPP Model [RFC2911] would
+      require a different URL scheme.
+
+      The "ipp" URL scheme allows an IPP client to choose an appropriate
+      IPP print service (for example, from a directory).  The IPP client
+      can establish an HTTP connection to the specified IPP print
+      service.  The IPP client can send IPP protocol requests (for
+      example, a "Print-Job" request) and receive IPP protocol responses
+      over that HTTP connection.
+
+4.2.  IPP URL Scheme Associated Port
+
+      All IPP URLs which do NOT explicitly specify a port MUST be
+      resolved to IANA-assigned well-known port 631, as registered in
+      [IANA-PORTREG].
+
+      See:  IANA Port Numbers Registry [IANA-PORTREG].
+      See:  IPP Protocol [RFC2910].
+
+
+
+
+
+Herriot & McDonald          Standards Track                     [Page 4]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+4.3.  IPP URL Scheme Associated MIME Type
+
+      All IPP URLs MUST be used to specify network print services which
+      support the "application/ipp" MIME media type as registered in
+      [IANA-MIMEREG] for IPP protocol requests and responses.
+
+      See:  IANA MIME Media Types Registry [IANA-MIMEREG].
+      See:  IPP Protocol [RFC2910].
+
+4.4.  IPP URL Scheme Character Encoding
+
+      IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP
+      URLs.  Characters other than those in the "reserved" and "unsafe"
+      sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.
+
+4.5.  IPP URL Scheme Syntax
+
+      The abstract protocol defined in IPP Model [RFC2911] places a
+      limit of 1023 octets (NOT characters) on the length of a URI (see
+      section 4.1.5, "uri", in [RFC2911]).
+
+      Note:  IPP Printers ought to be cautious about depending on URI
+      lengths above 255 bytes, because some older client implementations
+      might not properly support these lengths.
+
+   IPP URLs MUST be represented in absolute form.  Absolute URLs MUST
+   always begin with a scheme name followed by a colon.  For definitive
+   information on URL syntax and semantics, see "Uniform Resource
+   Identifiers (URI): Generic Syntax and Semantics" [RFC2396].  This
+   specification adopts the definitions of "host", "port", "abs_path",
+   and "query" from [RFC2396], as updated for IPv6 by [RFC2732].
+
+   The IPP URL scheme syntax in ABNF is as follows:
+
+   ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+
+   If the port is empty or not given, port 631 is assumed.  The
+   semantics are that the identified resource (see section 5.1.2 of
+   [RFC2616]) is located at the IPP print service listening for HTTP
+   connections on that port of that host, and the Request-URI for the
+   identified resource is 'abs_path'.
+
+   If the 'abs_path' is not present in the URL, it MUST be given as "/"
+   when used as a Request-URI for a resource (see section 5.1.2 of
+   [RFC2616]).
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                     [Page 5]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+4.6.  IPP URL Examples
+
+   Note:  Literal IPv4 or IPv6 addresses SHOULD NOT be used in IPP URLs.
+
+4.6.1.  IPP Printer URL Examples
+
+   The following are examples of well-formed IPP URLs for IPP Printers
+   (for example, to be used as protocol elements in 'printer-uri'
+   operation attributes of 'Print-Job' request messages):
+
+      ipp://example.com
+      ipp://example.com/printer
+      ipp://example.com/printer/tiger
+      ipp://example.com/printer/fox
+      ipp://example.com/printer/tiger/bob
+      ipp://example.com/printer/tiger/ira
+
+   Each of the above URLs are well-formed URLs for IPP Printers and each
+   would reference a logically different IPP Printer, even though some
+   of those IPP Printers might share the same host system.  The 'bob' or
+   'ira' last path components might represent two different physical
+   printer devices, while 'tiger' might represent some grouping of IPP
+   Printers (for example, a load-balancing spooler).  Or the 'bob' and
+   'ira' last path components might represent separate human recipients
+   on the same physical printer device (for example, a physical printer
+   supporting two job queues).  In either case, both 'bob' and 'ira'
+   would behave as different and independent IPP Printers.
+
+   The following are examples of well-formed IPP URLs for IPP Printers
+   with (optional) ports and paths:
+
+      ipp://example.com
+      ipp://example.com/~smith/printer
+      ipp://example.com:631/~smith/printer
+
+   The first and second IPP URLs above MUST be resolved to port 631
+   (IANA assigned well-known port for IPP).  The second and third IPP
+   URLs above are equivalent (see section 4.7 below).
+
+4.6.2.  IPP Job URL Examples
+
+   The following are examples of well-formed IPP URLs for IPP Jobs (for
+   example, to be used as protocol elements in 'job-uri' attributes of
+   'Print-Job' response messages):
+
+      ipp://example.com/printer/123
+      ipp://example.com/printer/tiger/job123
+
+
+
+
+Herriot & McDonald          Standards Track                     [Page 6]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+   IPP Job URLs are valid and meaningful only until Job completion and
+   possibly an implementation defined optional period of persistence
+   after Job completion (see IPP Model [RFC2911]).
+
+   Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states
+   that:
+
+      "the precise format of a Job URI is implementation dependent."
+
+   Thus, the relationship between the value of the "printer-uri"
+   operation attribute used in a 'Print-Job' request and the value of
+   the "job-uri" attribute returned in the corresponding 'Print-Job'
+   response is implementation dependent.  Also, section 4.3.3 'job-
+   printer-uri' of IPP Model [RFC2911] states that the 'job-printer-uri'
+   attribute of a Job object:
+
+      "permits a client to identify the Printer object that created this
+      Job object when only the Job object's URI is available to the
+      client."
+
+   However, the above statement is false, because the transform from an
+   IPP Job URL to the corresponding IPP Printer URL is unspecified in
+   either IPP Model [RFC2911] or IPP Protocol [RFC2910].
+
+   IPP Printers that conform to this specification SHOULD only generate
+   IPP Job URLs (for example, in the "job-uri" attribute in a 'Print-
+   Job' response) by appending exactly one path component to the
+   corresponding IPP Printer URL (for interoperability).
+
+4.7.  IPP URL Comparisons
+
+   When comparing two IPP URLs to decide if they match or not, an IPP
+   Client MUST use the same rules as those defined for HTTP URI
+   comparisons in [RFC2616], with the sole following exception:
+
+   -  A port that is empty or not given MUST be treated as equivalent to
+      the well-known port for that IPP URL (port 631);
+
+      See:  Section 3.2.3, "URI Comparison", in [RFC2616].
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                     [Page 7]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+5.  Conformance Requirements
+
+5.1.  IPP Client Conformance Requirements
+
+      IPP Clients that conform to this specification:
+
+   a) MUST only send IPP protocol connections to the port specified in
+      each given IPP URL (if present) or otherwise to IANA assigned
+      well-known port 631;
+
+   b) MUST only send IPP URLs used as protocol elements in outgoing IPP
+      protocol request messages (for example, in the "printer-uri"
+      operation attribute in a 'Print-Job' request) that conform to the
+      ABNF specified in section 4.5, "IPP URL Scheme Syntax, of this
+      document;
+
+   c) MUST only convert IPP URLs to their corresponding HTTP URL forms
+      according to the rules in section 5, "IPP URL Scheme", in
+      [RFC2910].
+
+5.2.  IPP Printer Conformance Requirements
+
+   IPP Printers that conform to this specification:
+
+   a) MUST listen for incoming IPP protocol connections on IANA-assigned
+      well-known port 631, unless explicitly configured by system
+      administrators or site policies;
+
+   b) SHOULD NOT listen for incoming IPP protocol connections on any
+      other port, unless explicitly configured by system administrators
+      or site policies;
+
+   c) SHOULD only accept IPP URLs used as protocol elements in incoming
+      IPP protocol request messages (for example, in the "printer-uri"
+      operation attribute in a 'Print-Job' request) that conform to the
+      ABNF specified in section 4.5, "IPP URL Scheme Syntax", of this
+      document;
+
+   d) SHOULD only send IPP URLs used as protocol elements in outgoing
+      IPP protocol response messages (for example, in the "job-uri"
+      attribute in a 'Print-Job' response) that conform to the ABNF
+      specified in section 4.5, "IPP URL Scheme Syntax", of this
+      document;
+
+   e) SHOULD only generate IPP Job URLs (for example, in the "job-uri"
+      attribute in a 'Print-Job' response) by appending exactly one path
+      component to the corresponding IPP Printer URL (for
+      interoperability);
+
+
+
+Herriot & McDonald          Standards Track                     [Page 8]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+   f) SHOULD NOT use literal IPv6 or IPv4 addresses in configured or
+      locally generated IPP URLs.
+
+6.  IANA Considerations
+
+   This IPP URL Scheme specification does not introduce any additional
+   IANA considerations, beyond those described in [RFC2910] and
+   [RFC2911].
+
+   See:  Section 6, "IANA Considerations" in [RFC2910]
+   See:  Section 6, "IANA Considerations" in [RFC2911].
+
+7.  Internationalization Considerations
+
+   This IPP URL Scheme specification does not introduce any additional
+   internationalization considerations, beyond those described in
+   [RFC2910] and [RFC2911].
+
+   See:  Section 7, "Internationalization Considerations", in [RFC2910].
+   See:  Section 7, "Internationalization Considerations", in [RFC2911].
+
+8.  Security Considerations
+
+   This IPP URL Scheme specification does not introduce any additional
+   security considerations, beyond those described in [RFC2910] and
+   [RFC2911], except the following:
+
+   a) An IPP URL might be faked to point to a rogue IPP print service,
+      thus collecting confidential document contents from IPP clients.
+      Server authentication mechanisms and security mechanisms specified
+      in the IPP Protocol [RFC2910] are sufficient to address this
+      threat.
+
+   b) An IPP URL might be used to access an IPP print service by an
+      unauthorized IPP client.  Client authentication mechanisms and
+      security mechanisms specified in the IPP Protocol [RFC2910] are
+      sufficient to address this threat.
+
+   c) An IPP URL might be used to access an IPP print service at a print
+      protocol application layer gateway (for example, an IPP to LPD
+      gateway [RFC2569]) causing silent compromise of IPP security
+      mechanisms.  There is no practical defense against this threat by
+      a client system.  System administrators should avoid such
+      compromising configurations.
+
+   d) An IPP URL does not have parameters to specify the required client
+      authentication mechanism (for example, 'certificate' as defined in
+      section 4.4.2, "uri-authentication-supported", of IPP Model
+
+
+
+Herriot & McDonald          Standards Track                     [Page 9]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+      [RFC2911]) and required security mechanism (for example, 'tls' as
+      defined in section 4.4.3, "uri-security-supported", of IPP Model
+      [RFC2911]).  Service discovery or directory protocols might be
+      used to discover the required client authentication and security
+      mechanisms associated with given IPP URLs.
+
+   Historical Note:  During the development of this document,
+   consideration was given to the addition of standard IPP URL
+   parameters for the client authentication and security mechanisms.
+   However, based on a strong IETF IPP Working Group consensus, no
+   parameters were added to the "ipp" URL scheme as originally defined
+   in IPP Protocol [RFC2910] in September 2000, for reasons of backwards
+   compatibility with the many currently shipping implementations of
+   IPP/1.1.
+
+   See:  Section 8, "Security Considerations", in [RFC2910].
+   See:  Section 8, "Security Considerations", in [RFC2911].
+
+9.  Intellectual Property Rights
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                    [Page 10]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+10.  Normative References
+
+   [RFC2234]      Crocker, D. and  P. Overell, "Augmented BNF for Syntax
+                  Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
+                  "Uniform Resource Identifiers (URI): Generic Syntax",
+                  RFC 2396, August 1998.
+
+   [RFC2616]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                  Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+                  Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2732]      Hinden, R., Carpenter, B. and L. Masinter, "Format for
+                  Literal IPv6 Addresses in URL's", RFC 2732, December
+                  1999.
+
+   [RFC2910]      Herriot, R., Butler, S., Moore, P., Turner, R. and J.
+                  Wenn, "IPP/1.1 Encoding and Transport [IPP Protocol]",
+                  RFC 2910, September 2000.
+
+   [RFC2911]      Hastings, T., Herriot, R., deBry, R., Isaacson, S. and
+                  P. Powell, "IPP/1.1 Model and Semantics [IPP Model]",
+                  RFC 2911, September 2000.
+
+   [US-ASCII]     Coded Character Set -- 7-bit American Standard Code
+                  for Information Interchange, ANSI X3.4-1986.
+
+11.  Informative References
+
+   [IANA-MIMEREG] IANA MIME Media Types Registry.
+                  ftp://ftp.iana.org/in-notes/iana/assignments/media-
+                  types/...
+
+   [IANA-PORTREG] IANA Port Numbers Registry. ftp://ftp.iana.org/in-
+                  notes/iana/assignments/port-numbers
+
+   [RFC2569]      Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
+                  "Mapping between LPD and IPP Protocols", RFC 2569,
+                  April 1999.
+
+   [RFC2717]      Petke, R. and I. King, "Registration Procedures for
+                  URL Scheme Names", RFC 2717, November 1999.
+
+   [RFC2718]      Masinter, L., Alvestrand, H., Zigmond, D. and R.
+                  Petke, "Guidelines for new URL Schemes", RFC 2718,
+                  November 1999.
+
+
+
+
+Herriot & McDonald          Standards Track                    [Page 11]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+   [RFC3196]      Hastings, T., Manros, C., Zehler, P., Kugler, C. and
+                  H. Holst, "Internet Printing Protocol/1.1:
+                  Implementor's Guide", RFC 3196, November 2001.
+
+12.  Acknowledgments
+
+   This document is a product of the Internet Printing Protocol Working
+   Group of the Internet Engineering Task Force (IETF).
+
+   Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM),
+   Hugo Parra (Novell), Don Wright (Lexmark), and all the members of the
+   IETF IPP WG.
+
+   Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910] was the
+   primary input to this IPP URL Scheme specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                    [Page 12]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+Appendix A - Registration of "ipp" URL Scheme
+
+   Note:  The following registration obsoletes section 5, "IPP URL
+   Scheme", of IPP Protocol [RFC2911].
+
+   URL Scheme Name:  ipp
+
+   URL Scheme Syntax:
+
+      ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+
+   Character Encoding Considerations:
+
+      IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP
+      URLs.  Characters other than those in the "reserved" and "unsafe"
+      sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.
+
+   Intended Usage:
+
+      The intended usage of the "ipp" URL scheme is COMMON.
+
+      An "ipp" URL is used to specify the network location of a print
+      service that supports the IPP Protocol [RFC2910], or of a network
+      resource (for example, a print job) managed by such a print
+      service.  An IPP client can choose to establish an HTTP connection
+      to the specified print service for transmission of IPP protocol
+      requests (for example, IPP print job submission requests).
+
+   Applications or Protocols which use this URL scheme:
+
+      See:  Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910].
+
+   Interoperability Considerations:
+
+      See:  Section 9, "Interoperability with IPP/1.0 Implementations",
+      in IPP Protocol [RFC2910].
+
+   Security Considerations:
+
+      See:  Section 8, "Security Considerations", in IPP Protocol
+      [RFC2910].
+
+   Relevant Publications:
+
+   [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn,
+             "IPP/1.1 Encoding and Transport [IPP Protocol]", RFC 2910,
+             September 2000.
+
+
+
+
+Herriot & McDonald          Standards Track                    [Page 13]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
+             L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
+             Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC3510] Herriot, R. and I. McDonald, "IPP/1.1: IPP URL Scheme", RFC
+             3510, April 2003.
+
+   Person & email address to contact for further information:
+
+   Robert Herriot
+   Consultant
+   706 Colorado Ave
+   Palo Alto, CA  94303
+
+   Phone: +1 650-327-4466
+   EMail: bob@herriot.com
+
+   Ira McDonald
+   High North Inc
+   221 Ridge Ave
+   Grand Marais, MI  49839
+
+   Phone: +1 906-494-2434
+   EMail: imcdonald@sharplabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                    [Page 14]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+Authors' Addresses
+
+   Robert Herriot
+   Consultant
+   706 Colorado Ave
+   Palo Alto, CA  94303
+
+   Phone: +1 650-327-4466
+   EMail: bob@herriot.com
+
+
+   Ira McDonald
+   High North Inc
+   221 Ridge Ave
+   Grand Marais, MI  49839
+
+   Phone: +1 906-494-2434
+   EMail: imcdonald@sharplabs.com
+
+   Usage questions and comments on this IPP URL Scheme should be sent
+   directly to the editors at their above addresses (and to the IPP
+   mailing list, if you are a subscriber - see below).
+
+   IPP Web Page:      http://www.pwg.org/ipp/
+   IPP Mailing List:  ipp@pwg.org
+
+   To subscribe to the IPP mailing list, send the following email:
+
+   1) send it to majordomo@pwg.org
+
+   2) leave the subject line blank
+
+   3) put the following two lines in the message body:  subscribe ipp
+
+   Implementers of this specification are encouraged to join the IPP
+   Mailing List in order to participate in any discussions of
+   clarification issues and comments.  In order to reduce spam the
+   mailing list rejects mail from non-subscribers, so you must subscribe
+   to the mailing list in order to send a question or comment to the IPP
+   mailing list.
+
+
+
+
+
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                    [Page 15]
+
+RFC 3510                     IPP URL Scheme                   April 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & McDonald          Standards Track                    [Page 16]
+
diff --git a/standards/rfc3986.txt b/standards/rfc3986.txt
new file mode 100644
index 000000000..c56ed4eb7
--- /dev/null
+++ b/standards/rfc3986.txt
@@ -0,0 +1,3419 @@
+
+
+
+
+
+
+Network Working Group                                     T. Berners-Lee
+Request for Comments: 3986                                       W3C/MIT
+STD: 66                                                      R. Fielding
+Updates: 1738                                               Day Software
+Obsoletes: 2732, 2396, 1808                                  L. Masinter
+Category: Standards Track                                  Adobe Systems
+                                                            January 2005
+
+
+           Uniform Resource Identifier (URI): Generic Syntax
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   A Uniform Resource Identifier (URI) is a compact sequence of
+   characters that identifies an abstract or physical resource.  This
+   specification defines the generic URI syntax and a process for
+   resolving URI references that might be in relative form, along with
+   guidelines and security considerations for the use of URIs on the
+   Internet.  The URI syntax defines a grammar that is a superset of all
+   valid URIs, allowing an implementation to parse the common components
+   of a URI reference without knowing the scheme-specific requirements
+   of every possible identifier.  This specification does not define a
+   generative grammar for URIs; that task is performed by the individual
+   specifications of each URI scheme.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 1]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+       1.1.  Overview of URIs . . . . . . . . . . . . . . . . . . . .  4
+             1.1.1.  Generic Syntax . . . . . . . . . . . . . . . . .  6
+             1.1.2.  Examples . . . . . . . . . . . . . . . . . . . .  7
+             1.1.3.  URI, URL, and URN  . . . . . . . . . . . . . . .  7
+       1.2.  Design Considerations  . . . . . . . . . . . . . . . . .  8
+             1.2.1.  Transcription  . . . . . . . . . . . . . . . . .  8
+             1.2.2.  Separating Identification from Interaction . . .  9
+             1.2.3.  Hierarchical Identifiers . . . . . . . . . . . . 10
+       1.3.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . 11
+   2.  Characters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+       2.1.  Percent-Encoding . . . . . . . . . . . . . . . . . . . . 12
+       2.2.  Reserved Characters  . . . . . . . . . . . . . . . . . . 12
+       2.3.  Unreserved Characters  . . . . . . . . . . . . . . . . . 13
+       2.4.  When to Encode or Decode . . . . . . . . . . . . . . . . 14
+       2.5.  Identifying Data . . . . . . . . . . . . . . . . . . . . 14
+   3.  Syntax Components  . . . . . . . . . . . . . . . . . . . . . . 16
+       3.1.  Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 17
+       3.2.  Authority  . . . . . . . . . . . . . . . . . . . . . . . 17
+             3.2.1.  User Information . . . . . . . . . . . . . . . . 18
+             3.2.2.  Host . . . . . . . . . . . . . . . . . . . . . . 18
+             3.2.3.  Port . . . . . . . . . . . . . . . . . . . . . . 22
+       3.3.  Path . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+       3.4.  Query  . . . . . . . . . . . . . . . . . . . . . . . . . 23
+       3.5.  Fragment . . . . . . . . . . . . . . . . . . . . . . . . 24
+   4.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+       4.1.  URI Reference  . . . . . . . . . . . . . . . . . . . . . 25
+       4.2.  Relative Reference . . . . . . . . . . . . . . . . . . . 26
+       4.3.  Absolute URI . . . . . . . . . . . . . . . . . . . . . . 27
+       4.4.  Same-Document Reference  . . . . . . . . . . . . . . . . 27
+       4.5.  Suffix Reference . . . . . . . . . . . . . . . . . . . . 27
+   5.  Reference Resolution . . . . . . . . . . . . . . . . . . . . . 28
+       5.1.  Establishing a Base URI  . . . . . . . . . . . . . . . . 28
+             5.1.1.  Base URI Embedded in Content . . . . . . . . . . 29
+             5.1.2.  Base URI from the Encapsulating Entity . . . . . 29
+             5.1.3.  Base URI from the Retrieval URI  . . . . . . . . 30
+             5.1.4.  Default Base URI . . . . . . . . . . . . . . . . 30
+       5.2.  Relative Resolution  . . . . . . . . . . . . . . . . . . 30
+             5.2.1.  Pre-parse the Base URI . . . . . . . . . . . . . 31
+             5.2.2.  Transform References . . . . . . . . . . . . . . 31
+             5.2.3.  Merge Paths  . . . . . . . . . . . . . . . . . . 32
+             5.2.4.  Remove Dot Segments  . . . . . . . . . . . . . . 33
+       5.3.  Component Recomposition  . . . . . . . . . . . . . . . . 35
+       5.4.  Reference Resolution Examples  . . . . . . . . . . . . . 35
+             5.4.1.  Normal Examples  . . . . . . . . . . . . . . . . 36
+             5.4.2.  Abnormal Examples  . . . . . . . . . . . . . . . 36
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 2]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   6.  Normalization and Comparison . . . . . . . . . . . . . . . . . 38
+       6.1.  Equivalence  . . . . . . . . . . . . . . . . . . . . . . 38
+       6.2.  Comparison Ladder  . . . . . . . . . . . . . . . . . . . 39
+             6.2.1.  Simple String Comparison . . . . . . . . . . . . 39
+             6.2.2.  Syntax-Based Normalization . . . . . . . . . . . 40
+             6.2.3.  Scheme-Based Normalization . . . . . . . . . . . 41
+             6.2.4.  Protocol-Based Normalization . . . . . . . . . . 42
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 43
+       7.1.  Reliability and Consistency  . . . . . . . . . . . . . . 43
+       7.2.  Malicious Construction . . . . . . . . . . . . . . . . . 43
+       7.3.  Back-End Transcoding . . . . . . . . . . . . . . . . . . 44
+       7.4.  Rare IP Address Formats  . . . . . . . . . . . . . . . . 45
+       7.5.  Sensitive Information  . . . . . . . . . . . . . . . . . 45
+       7.6.  Semantic Attacks . . . . . . . . . . . . . . . . . . . . 45
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 46
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
+       10.1. Normative References . . . . . . . . . . . . . . . . . . 46
+       10.2. Informative References . . . . . . . . . . . . . . . . . 47
+   A.  Collected ABNF for URI . . . . . . . . . . . . . . . . . . . . 49
+   B.  Parsing a URI Reference with a Regular Expression  . . . . . . 50
+   C.  Delimiting a URI in Context  . . . . . . . . . . . . . . . . . 51
+   D.  Changes from RFC 2396  . . . . . . . . . . . . . . . . . . . . 53
+       D.1.  Additions  . . . . . . . . . . . . . . . . . . . . . . . 53
+       D.2.  Modifications  . . . . . . . . . . . . . . . . . . . . . 53
+   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 61
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 3]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+1.  Introduction
+
+   A Uniform Resource Identifier (URI) provides a simple and extensible
+   means for identifying a resource.  This specification of URI syntax
+   and semantics is derived from concepts introduced by the World Wide
+   Web global information initiative, whose use of these identifiers
+   dates from 1990 and is described in "Universal Resource Identifiers
+   in WWW" [RFC1630].  The syntax is designed to meet the
+   recommendations laid out in "Functional Recommendations for Internet
+   Resource Locators" [RFC1736] and "Functional Requirements for Uniform
+   Resource Names" [RFC1737].
+
+   This document obsoletes [RFC2396], which merged "Uniform Resource
+   Locators" [RFC1738] and "Relative Uniform Resource Locators"
+   [RFC1808] in order to define a single, generic syntax for all URIs.
+   It obsoletes [RFC2732], which introduced syntax for an IPv6 address.
+   It excludes portions of RFC 1738 that defined the specific syntax of
+   individual URI schemes; those portions will be updated as separate
+   documents.  The process for registration of new URI schemes is
+   defined separately by [BCP35].  Advice for designers of new URI
+   schemes can be found in [RFC2718].  All significant changes from RFC
+   2396 are noted in Appendix D.
+
+   This specification uses the terms "character" and "coded character
+   set" in accordance with the definitions provided in [BCP19], and
+   "character encoding" in place of what [BCP19] refers to as a
+   "charset".
+
+1.1.  Overview of URIs
+
+   URIs are characterized as follows:
+
+   Uniform
+
+      Uniformity provides several benefits.  It allows different types
+      of resource identifiers to be used in the same context, even when
+      the mechanisms used to access those resources may differ.  It
+      allows uniform semantic interpretation of common syntactic
+      conventions across different types of resource identifiers.  It
+      allows introduction of new types of resource identifiers without
+      interfering with the way that existing identifiers are used.  It
+      allows the identifiers to be reused in many different contexts,
+      thus permitting new applications or protocols to leverage a pre-
+      existing, large, and widely used set of resource identifiers.
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 4]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   Resource
+
+      This specification does not limit the scope of what might be a
+      resource; rather, the term "resource" is used in a general sense
+      for whatever might be identified by a URI.  Familiar examples
+      include an electronic document, an image, a source of information
+      with a consistent purpose (e.g., "today's weather report for Los
+      Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a
+      collection of other resources.  A resource is not necessarily
+      accessible via the Internet; e.g., human beings, corporations, and
+      bound books in a library can also be resources.  Likewise,
+      abstract concepts can be resources, such as the operators and
+      operands of a mathematical equation, the types of a relationship
+      (e.g., "parent" or "employee"), or numeric values (e.g., zero,
+      one, and infinity).
+
+   Identifier
+
+      An identifier embodies the information required to distinguish
+      what is being identified from all other things within its scope of
+      identification.  Our use of the terms "identify" and "identifying"
+      refer to this purpose of distinguishing one resource from all
+      other resources, regardless of how that purpose is accomplished
+      (e.g., by name, address, or context).  These terms should not be
+      mistaken as an assumption that an identifier defines or embodies
+      the identity of what is referenced, though that may be the case
+      for some identifiers.  Nor should it be assumed that a system
+      using URIs will access the resource identified: in many cases,
+      URIs are used to denote resources without any intention that they
+      be accessed.  Likewise, the "one" resource identified might not be
+      singular in nature (e.g., a resource might be a named set or a
+      mapping that varies over time).
+
+   A URI is an identifier consisting of a sequence of characters
+   matching the syntax rule named <URI> in Section 3.  It enables
+   uniform identification of resources via a separately defined
+   extensible set of naming schemes (Section 3.1).  How that
+   identification is accomplished, assigned, or enabled is delegated to
+   each scheme specification.
+
+   This specification does not place any limits on the nature of a
+   resource, the reasons why an application might seek to refer to a
+   resource, or the kinds of systems that might use URIs for the sake of
+   identifying resources.  This specification does not require that a
+   URI persists in identifying the same resource over time, though that
+   is a common goal of all URI schemes.  Nevertheless, nothing in this
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 5]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   specification prevents an application from limiting itself to
+   particular types of resources, or to a subset of URIs that maintains
+   characteristics desired by that application.
+
+   URIs have a global scope and are interpreted consistently regardless
+   of context, though the result of that interpretation may be in
+   relation to the end-user's context.  For example, "http://localhost/"
+   has the same interpretation for every user of that reference, even
+   though the network interface corresponding to "localhost" may be
+   different for each end-user: interpretation is independent of access.
+   However, an action made on the basis of that reference will take
+   place in relation to the end-user's context, which implies that an
+   action intended to refer to a globally unique thing must use a URI
+   that distinguishes that resource from all other things.  URIs that
+   identify in relation to the end-user's local context should only be
+   used when the context itself is a defining aspect of the resource,
+   such as when an on-line help manual refers to a file on the end-
+   user's file system (e.g., "file:///etc/hosts").
+
+1.1.1.  Generic Syntax
+
+   Each URI begins with a scheme name, as defined in Section 3.1, that
+   refers to a specification for assigning identifiers within that
+   scheme.  As such, the URI syntax is a federated and extensible naming
+   system wherein each scheme's specification may further restrict the
+   syntax and semantics of identifiers using that scheme.
+
+   This specification defines those elements of the URI syntax that are
+   required of all URI schemes or are common to many URI schemes.  It
+   thus defines the syntax and semantics needed to implement a scheme-
+   independent parsing mechanism for URI references, by which the
+   scheme-dependent handling of a URI can be postponed until the
+   scheme-dependent semantics are needed.  Likewise, protocols and data
+   formats that make use of URI references can refer to this
+   specification as a definition for the range of syntax allowed for all
+   URIs, including those schemes that have yet to be defined.  This
+   decouples the evolution of identification schemes from the evolution
+   of protocols, data formats, and implementations that make use of
+   URIs.
+
+   A parser of the generic URI syntax can parse any URI reference into
+   its major components.  Once the scheme is determined, further
+   scheme-specific parsing can be performed on the components.  In other
+   words, the URI generic syntax is a superset of the syntax of all URI
+   schemes.
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 6]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+1.1.2.  Examples
+
+   The following example URIs illustrate several URI schemes and
+   variations in their common syntax components:
+
+      ftp://ftp.is.co.za/rfc/rfc1808.txt
+
+      http://www.ietf.org/rfc/rfc2396.txt
+
+      ldap://[2001:db8::7]/c=GB?objectClass?one
+
+      mailto:John.Doe@example.com
+
+      news:comp.infosystems.www.servers.unix
+
+      tel:+1-816-555-1212
+
+      telnet://192.0.2.16:80/
+
+      urn:oasis:names:specification:docbook:dtd:xml:4.1.2
+
+
+1.1.3.  URI, URL, and URN
+
+   A URI can be further classified as a locator, a name, or both.  The
+   term "Uniform Resource Locator" (URL) refers to the subset of URIs
+   that, in addition to identifying a resource, provide a means of
+   locating the resource by describing its primary access mechanism
+   (e.g., its network "location").  The term "Uniform Resource Name"
+   (URN) has been used historically to refer to both URIs under the
+   "urn" scheme [RFC2141], which are required to remain globally unique
+   and persistent even when the resource ceases to exist or becomes
+   unavailable, and to any other URI with the properties of a name.
+
+   An individual scheme does not have to be classified as being just one
+   of "name" or "locator".  Instances of URIs from any given scheme may
+   have the characteristics of names or locators or both, often
+   depending on the persistence and care in the assignment of
+   identifiers by the naming authority, rather than on any quality of
+   the scheme.  Future specifications and related documentation should
+   use the general term "URI" rather than the more restrictive terms
+   "URL" and "URN" [RFC3305].
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 7]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+1.2.  Design Considerations
+
+1.2.1.  Transcription
+
+   The URI syntax has been designed with global transcription as one of
+   its main considerations.  A URI is a sequence of characters from a
+   very limited set: the letters of the basic Latin alphabet, digits,
+   and a few special characters.  A URI may be represented in a variety
+   of ways; e.g., ink on paper, pixels on a screen, or a sequence of
+   character encoding octets.  The interpretation of a URI depends only
+   on the characters used and not on how those characters are
+   represented in a network protocol.
+
+   The goal of transcription can be described by a simple scenario.
+   Imagine two colleagues, Sam and Kim, sitting in a pub at an
+   international conference and exchanging research ideas.  Sam asks Kim
+   for a location to get more information, so Kim writes the URI for the
+   research site on a napkin.  Upon returning home, Sam takes out the
+   napkin and types the URI into a computer, which then retrieves the
+   information to which Kim referred.
+
+   There are several design considerations revealed by the scenario:
+
+   o  A URI is a sequence of characters that is not always represented
+      as a sequence of octets.
+
+   o  A URI might be transcribed from a non-network source and thus
+      should consist of characters that are most likely able to be
+      entered into a computer, within the constraints imposed by
+      keyboards (and related input devices) across languages and
+      locales.
+
+   o  A URI often has to be remembered by people, and it is easier for
+      people to remember a URI when it consists of meaningful or
+      familiar components.
+
+   These design considerations are not always in alignment.  For
+   example, it is often the case that the most meaningful name for a URI
+   component would require characters that cannot be typed into some
+   systems.  The ability to transcribe a resource identifier from one
+   medium to another has been considered more important than having a
+   URI consist of the most meaningful of components.
+
+   In local or regional contexts and with improving technology, users
+   might benefit from being able to use a wider range of characters;
+   such use is not defined by this specification.  Percent-encoded
+   octets (Section 2.1) may be used within a URI to represent characters
+   outside the range of the US-ASCII coded character set if this
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 8]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   representation is allowed by the scheme or by the protocol element in
+   which the URI is referenced.  Such a definition should specify the
+   character encoding used to map those characters to octets prior to
+   being percent-encoded for the URI.
+
+1.2.2.  Separating Identification from Interaction
+
+   A common misunderstanding of URIs is that they are only used to refer
+   to accessible resources.  The URI itself only provides
+   identification; access to the resource is neither guaranteed nor
+   implied by the presence of a URI.  Instead, any operation associated
+   with a URI reference is defined by the protocol element, data format
+   attribute, or natural language text in which it appears.
+
+   Given a URI, a system may attempt to perform a variety of operations
+   on the resource, as might be characterized by words such as "access",
+   "update", "replace", or "find attributes".  Such operations are
+   defined by the protocols that make use of URIs, not by this
+   specification.  However, we do use a few general terms for describing
+   common operations on URIs.  URI "resolution" is the process of
+   determining an access mechanism and the appropriate parameters
+   necessary to dereference a URI; this resolution may require several
+   iterations.  To use that access mechanism to perform an action on the
+   URI's resource is to "dereference" the URI.
+
+   When URIs are used within information retrieval systems to identify
+   sources of information, the most common form of URI dereference is
+   "retrieval": making use of a URI in order to retrieve a
+   representation of its associated resource.  A "representation" is a
+   sequence of octets, along with representation metadata describing
+   those octets, that constitutes a record of the state of the resource
+   at the time when the representation is generated.  Retrieval is
+   achieved by a process that might include using the URI as a cache key
+   to check for a locally cached representation, resolution of the URI
+   to determine an appropriate access mechanism (if any), and
+   dereference of the URI for the sake of applying a retrieval
+   operation.  Depending on the protocols used to perform the retrieval,
+   additional information might be supplied about the resource (resource
+   metadata) and its relation to other resources.
+
+   URI references in information retrieval systems are designed to be
+   late-binding: the result of an access is generally determined when it
+   is accessed and may vary over time or due to other aspects of the
+   interaction.  These references are created in order to be used in the
+   future: what is being identified is not some specific result that was
+   obtained in the past, but rather some characteristic that is expected
+   to be true for future results.  In such cases, the resource referred
+   to by the URI is actually a sameness of characteristics as observed
+
+
+
+Berners-Lee, et al.         Standards Track                     [Page 9]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   over time, perhaps elucidated by additional comments or assertions
+   made by the resource provider.
+
+   Although many URI schemes are named after protocols, this does not
+   imply that use of these URIs will result in access to the resource
+   via the named protocol.  URIs are often used simply for the sake of
+   identification.  Even when a URI is used to retrieve a representation
+   of a resource, that access might be through gateways, proxies,
+   caches, and name resolution services that are independent of the
+   protocol associated with the scheme name.  The resolution of some
+   URIs may require the use of more than one protocol (e.g., both DNS
+   and HTTP are typically used to access an "http" URI's origin server
+   when a representation isn't found in a local cache).
+
+1.2.3.  Hierarchical Identifiers
+
+   The URI syntax is organized hierarchically, with components listed in
+   order of decreasing significance from left to right.  For some URI
+   schemes, the visible hierarchy is limited to the scheme itself:
+   everything after the scheme component delimiter (":") is considered
+   opaque to URI processing.  Other URI schemes make the hierarchy
+   explicit and visible to generic parsing algorithms.
+
+   The generic syntax uses the slash ("/"), question mark ("?"), and
+   number sign ("#") characters to delimit components that are
+   significant to the generic parser's hierarchical interpretation of an
+   identifier.  In addition to aiding the readability of such
+   identifiers through the consistent use of familiar syntax, this
+   uniform representation of hierarchy across naming schemes allows
+   scheme-independent references to be made relative to that hierarchy.
+
+   It is often the case that a group or "tree" of documents has been
+   constructed to serve a common purpose, wherein the vast majority of
+   URI references in these documents point to resources within the tree
+   rather than outside it.  Similarly, documents located at a particular
+   site are much more likely to refer to other resources at that site
+   than to resources at remote sites.  Relative referencing of URIs
+   allows document trees to be partially independent of their location
+   and access scheme.  For instance, it is possible for a single set of
+   hypertext documents to be simultaneously accessible and traversable
+   via each of the "file", "http", and "ftp" schemes if the documents
+   refer to each other with relative references.  Furthermore, such
+   document trees can be moved, as a whole, without changing any of the
+   relative references.
+
+   A relative reference (Section 4.2) refers to a resource by describing
+   the difference within a hierarchical name space between the reference
+   context and the target URI.  The reference resolution algorithm,
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 10]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   presented in Section 5, defines how such a reference is transformed
+   to the target URI.  As relative references can only be used within
+   the context of a hierarchical URI, designers of new URI schemes
+   should use a syntax consistent with the generic syntax's hierarchical
+   components unless there are compelling reasons to forbid relative
+   referencing within that scheme.
+
+      NOTE: Previous specifications used the terms "partial URI" and
+      "relative URI" to denote a relative reference to a URI.  As some
+      readers misunderstood those terms to mean that relative URIs are a
+      subset of URIs rather than a method of referencing URIs, this
+      specification simply refers to them as relative references.
+
+   All URI references are parsed by generic syntax parsers when used.
+   However, because hierarchical processing has no effect on an absolute
+   URI used in a reference unless it contains one or more dot-segments
+   (complete path segments of "." or "..", as described in Section 3.3),
+   URI scheme specifications can define opaque identifiers by
+   disallowing use of slash characters, question mark characters, and
+   the URIs "scheme:." and "scheme:..".
+
+1.3.  Syntax Notation
+
+   This specification uses the Augmented Backus-Naur Form (ABNF)
+   notation of [RFC2234], including the following core ABNF syntax rules
+   defined by that specification: ALPHA (letters), CR (carriage return),
+   DIGIT (decimal digits), DQUOTE (double quote), HEXDIG (hexadecimal
+   digits), LF (line feed), and SP (space).  The complete URI syntax is
+   collected in Appendix A.
+
+2.  Characters
+
+   The URI syntax provides a method of encoding data, presumably for the
+   sake of identifying a resource, as a sequence of characters.  The URI
+   characters are, in turn, frequently encoded as octets for transport
+   or presentation.  This specification does not mandate any particular
+   character encoding for mapping between URI characters and the octets
+   used to store or transmit those characters.  When a URI appears in a
+   protocol element, the character encoding is defined by that protocol;
+   without such a definition, a URI is assumed to be in the same
+   character encoding as the surrounding text.
+
+   The ABNF notation defines its terminal values to be non-negative
+   integers (codepoints) based on the US-ASCII coded character set
+   [ASCII].  Because a URI is a sequence of characters, we must invert
+   that relation in order to understand the URI syntax.  Therefore, the
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 11]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   integer values used by the ABNF must be mapped back to their
+   corresponding characters via US-ASCII in order to complete the syntax
+   rules.
+
+   A URI is composed from a limited set of characters consisting of
+   digits, letters, and a few graphic symbols.  A reserved subset of
+   those characters may be used to delimit syntax components within a
+   URI while the remaining characters, including both the unreserved set
+   and those reserved characters not acting as delimiters, define each
+   component's identifying data.
+
+2.1.  Percent-Encoding
+
+   A percent-encoding mechanism is used to represent a data octet in a
+   component when that octet's corresponding character is outside the
+   allowed set or is being used as a delimiter of, or within, the
+   component.  A percent-encoded octet is encoded as a character
+   triplet, consisting of the percent character "%" followed by the two
+   hexadecimal digits representing that octet's numeric value.  For
+   example, "%20" is the percent-encoding for the binary octet
+   "00100000" (ABNF: %x20), which in US-ASCII corresponds to the space
+   character (SP).  Section 2.4 describes when percent-encoding and
+   decoding is applied.
+
+      pct-encoded = "%" HEXDIG HEXDIG
+
+   The uppercase hexadecimal digits 'A' through 'F' are equivalent to
+   the lowercase digits 'a' through 'f', respectively.  If two URIs
+   differ only in the case of hexadecimal digits used in percent-encoded
+   octets, they are equivalent.  For consistency, URI producers and
+   normalizers should use uppercase hexadecimal digits for all percent-
+   encodings.
+
+2.2.  Reserved Characters
+
+   URIs include components and subcomponents that are delimited by
+   characters in the "reserved" set.  These characters are called
+   "reserved" because they may (or may not) be defined as delimiters by
+   the generic syntax, by each scheme-specific syntax, or by the
+   implementation-specific syntax of a URI's dereferencing algorithm.
+   If data for a URI component would conflict with a reserved
+   character's purpose as a delimiter, then the conflicting data must be
+   percent-encoded before the URI is formed.
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 12]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      reserved    = gen-delims / sub-delims
+
+      gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
+
+      sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
+                  / "*" / "+" / "," / ";" / "="
+
+   The purpose of reserved characters is to provide a set of delimiting
+   characters that are distinguishable from other data within a URI.
+   URIs that differ in the replacement of a reserved character with its
+   corresponding percent-encoded octet are not equivalent.  Percent-
+   encoding a reserved character, or decoding a percent-encoded octet
+   that corresponds to a reserved character, will change how the URI is
+   interpreted by most applications.  Thus, characters in the reserved
+   set are protected from normalization and are therefore safe to be
+   used by scheme-specific and producer-specific algorithms for
+   delimiting data subcomponents within a URI.
+
+   A subset of the reserved characters (gen-delims) is used as
+   delimiters of the generic URI components described in Section 3.  A
+   component's ABNF syntax rule will not use the reserved or gen-delims
+   rule names directly; instead, each syntax rule lists the characters
+   allowed within that component (i.e., not delimiting it), and any of
+   those characters that are also in the reserved set are "reserved" for
+   use as subcomponent delimiters within the component.  Only the most
+   common subcomponents are defined by this specification; other
+   subcomponents may be defined by a URI scheme's specification, or by
+   the implementation-specific syntax of a URI's dereferencing
+   algorithm, provided that such subcomponents are delimited by
+   characters in the reserved set allowed within that component.
+
+   URI producing applications should percent-encode data octets that
+   correspond to characters in the reserved set unless these characters
+   are specifically allowed by the URI scheme to represent data in that
+   component.  If a reserved character is found in a URI component and
+   no delimiting role is known for that character, then it must be
+   interpreted as representing the data octet corresponding to that
+   character's encoding in US-ASCII.
+
+2.3.  Unreserved Characters
+
+   Characters that are allowed in a URI but do not have a reserved
+   purpose are called unreserved.  These include uppercase and lowercase
+   letters, decimal digits, hyphen, period, underscore, and tilde.
+
+      unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 13]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   URIs that differ in the replacement of an unreserved character with
+   its corresponding percent-encoded US-ASCII octet are equivalent: they
+   identify the same resource.  However, URI comparison implementations
+   do not always perform normalization prior to comparison (see Section
+   6).  For consistency, percent-encoded octets in the ranges of ALPHA
+   (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
+   underscore (%5F), or tilde (%7E) should not be created by URI
+   producers and, when found in a URI, should be decoded to their
+   corresponding unreserved characters by URI normalizers.
+
+2.4.  When to Encode or Decode
+
+   Under normal circumstances, the only time when octets within a URI
+   are percent-encoded is during the process of producing the URI from
+   its component parts.  This is when an implementation determines which
+   of the reserved characters are to be used as subcomponent delimiters
+   and which can be safely used as data.  Once produced, a URI is always
+   in its percent-encoded form.
+
+   When a URI is dereferenced, the components and subcomponents
+   significant to the scheme-specific dereferencing process (if any)
+   must be parsed and separated before the percent-encoded octets within
+   those components can be safely decoded, as otherwise the data may be
+   mistaken for component delimiters.  The only exception is for
+   percent-encoded octets corresponding to characters in the unreserved
+   set, which can be decoded at any time.  For example, the octet
+   corresponding to the tilde ("~") character is often encoded as "%7E"
+   by older URI processing implementations; the "%7E" can be replaced by
+   "~" without changing its interpretation.
+
+   Because the percent ("%") character serves as the indicator for
+   percent-encoded octets, it must be percent-encoded as "%25" for that
+   octet to be used as data within a URI.  Implementations must not
+   percent-encode or decode the same string more than once, as decoding
+   an already decoded string might lead to misinterpreting a percent
+   data octet as the beginning of a percent-encoding, or vice versa in
+   the case of percent-encoding an already percent-encoded string.
+
+2.5.  Identifying Data
+
+   URI characters provide identifying data for each of the URI
+   components, serving as an external interface for identification
+   between systems.  Although the presence and nature of the URI
+   production interface is hidden from clients that use its URIs (and is
+   thus beyond the scope of the interoperability requirements defined by
+   this specification), it is a frequent source of confusion and errors
+   in the interpretation of URI character issues.  Implementers have to
+   be aware that there are multiple character encodings involved in the
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 14]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   production and transmission of URIs: local name and data encoding,
+   public interface encoding, URI character encoding, data format
+   encoding, and protocol encoding.
+
+   Local names, such as file system names, are stored with a local
+   character encoding.  URI producing applications (e.g., origin
+   servers) will typically use the local encoding as the basis for
+   producing meaningful names.  The URI producer will transform the
+   local encoding to one that is suitable for a public interface and
+   then transform the public interface encoding into the restricted set
+   of URI characters (reserved, unreserved, and percent-encodings).
+   Those characters are, in turn, encoded as octets to be used as a
+   reference within a data format (e.g., a document charset), and such
+   data formats are often subsequently encoded for transmission over
+   Internet protocols.
+
+   For most systems, an unreserved character appearing within a URI
+   component is interpreted as representing the data octet corresponding
+   to that character's encoding in US-ASCII.  Consumers of URIs assume
+   that the letter "X" corresponds to the octet "01011000", and even
+   when that assumption is incorrect, there is no harm in making it.  A
+   system that internally provides identifiers in the form of a
+   different character encoding, such as EBCDIC, will generally perform
+   character translation of textual identifiers to UTF-8 [STD63] (or
+   some other superset of the US-ASCII character encoding) at an
+   internal interface, thereby providing more meaningful identifiers
+   than those resulting from simply percent-encoding the original
+   octets.
+
+   For example, consider an information service that provides data,
+   stored locally using an EBCDIC-based file system, to clients on the
+   Internet through an HTTP server.  When an author creates a file with
+   the name "Laguna Beach" on that file system, the "http" URI
+   corresponding to that resource is expected to contain the meaningful
+   string "Laguna%20Beach".  If, however, that server produces URIs by
+   using an overly simplistic raw octet mapping, then the result would
+   be a URI containing "%D3%81%87%A4%95%81@%C2%85%81%83%88".  An
+   internal transcoding interface fixes this problem by transcoding the
+   local name to a superset of US-ASCII prior to producing the URI.
+   Naturally, proper interpretation of an incoming URI on such an
+   interface requires that percent-encoded octets be decoded (e.g.,
+   "%20" to SP) before the reverse transcoding is applied to obtain the
+   local name.
+
+   In some cases, the internal interface between a URI component and the
+   identifying data that it has been crafted to represent is much less
+   direct than a character encoding translation.  For example, portions
+   of a URI might reflect a query on non-ASCII data, or numeric
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 15]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   coordinates on a map.  Likewise, a URI scheme may define components
+   with additional encoding requirements that are applied prior to
+   forming the component and producing the URI.
+
+   When a new URI scheme defines a component that represents textual
+   data consisting of characters from the Universal Character Set [UCS],
+   the data should first be encoded as octets according to the UTF-8
+   character encoding [STD63]; then only those octets that do not
+   correspond to characters in the unreserved set should be percent-
+   encoded.  For example, the character A would be represented as "A",
+   the character LATIN CAPITAL LETTER A WITH GRAVE would be represented
+   as "%C3%80", and the character KATAKANA LETTER A would be represented
+   as "%E3%82%A2".
+
+3.  Syntax Components
+
+   The generic URI syntax consists of a hierarchical sequence of
+   components referred to as the scheme, authority, path, query, and
+   fragment.
+
+      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
+
+      hier-part   = "//" authority path-abempty
+                  / path-absolute
+                  / path-rootless
+                  / path-empty
+
+   The scheme and path components are required, though the path may be
+   empty (no characters).  When authority is present, the path must
+   either be empty or begin with a slash ("/") character.  When
+   authority is not present, the path cannot begin with two slash
+   characters ("//").  These restrictions result in five different ABNF
+   rules for a path (Section 3.3), only one of which will match any
+   given URI reference.
+
+   The following are two example URIs and their component parts:
+
+         foo://example.com:8042/over/there?name=ferret#nose
+         \_/   \______________/\_________/ \_________/ \__/
+          |           |            |            |        |
+       scheme     authority       path        query   fragment
+          |   _____________________|__
+         / \ /                        \
+         urn:example:animal:ferret:nose
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 16]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+3.1.  Scheme
+
+   Each URI begins with a scheme name that refers to a specification for
+   assigning identifiers within that scheme.  As such, the URI syntax is
+   a federated and extensible naming system wherein each scheme's
+   specification may further restrict the syntax and semantics of
+   identifiers using that scheme.
+
+   Scheme names consist of a sequence of characters beginning with a
+   letter and followed by any combination of letters, digits, plus
+   ("+"), period ("."), or hyphen ("-").  Although schemes are case-
+   insensitive, the canonical form is lowercase and documents that
+   specify schemes must do so with lowercase letters.  An implementation
+   should accept uppercase letters as equivalent to lowercase in scheme
+   names (e.g., allow "HTTP" as well as "http") for the sake of
+   robustness but should only produce lowercase scheme names for
+   consistency.
+
+      scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
+
+   Individual schemes are not specified by this document.  The process
+   for registration of new URI schemes is defined separately by [BCP35].
+   The scheme registry maintains the mapping between scheme names and
+   their specifications.  Advice for designers of new URI schemes can be
+   found in [RFC2718].  URI scheme specifications must define their own
+   syntax so that all strings matching their scheme-specific syntax will
+   also match the <absolute-URI> grammar, as described in Section 4.3.
+
+   When presented with a URI that violates one or more scheme-specific
+   restrictions, the scheme-specific resolution process should flag the
+   reference as an error rather than ignore the unused parts; doing so
+   reduces the number of equivalent URIs and helps detect abuses of the
+   generic syntax, which might indicate that the URI has been
+   constructed to mislead the user (Section 7.6).
+
+3.2.  Authority
+
+   Many URI schemes include a hierarchical element for a naming
+   authority so that governance of the name space defined by the
+   remainder of the URI is delegated to that authority (which may, in
+   turn, delegate it further).  The generic syntax provides a common
+   means for distinguishing an authority based on a registered name or
+   server address, along with optional port and user information.
+
+   The authority component is preceded by a double slash ("//") and is
+   terminated by the next slash ("/"), question mark ("?"), or number
+   sign ("#") character, or by the end of the URI.
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 17]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      authority   = [ userinfo "@" ] host [ ":" port ]
+
+   URI producers and normalizers should omit the ":" delimiter that
+   separates host from port if the port component is empty.  Some
+   schemes do not allow the userinfo and/or port subcomponents.
+
+   If a URI contains an authority component, then the path component
+   must either be empty or begin with a slash ("/") character.  Non-
+   validating parsers (those that merely separate a URI reference into
+   its major components) will often ignore the subcomponent structure of
+   authority, treating it as an opaque string from the double-slash to
+   the first terminating delimiter, until such time as the URI is
+   dereferenced.
+
+3.2.1.  User Information
+
+   The userinfo subcomponent may consist of a user name and, optionally,
+   scheme-specific information about how to gain authorization to access
+   the resource.  The user information, if present, is followed by a
+   commercial at-sign ("@") that delimits it from the host.
+
+      userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )
+
+   Use of the format "user:password" in the userinfo field is
+   deprecated.  Applications should not render as clear text any data
+   after the first colon (":") character found within a userinfo
+   subcomponent unless the data after the colon is the empty string
+   (indicating no password).  Applications may choose to ignore or
+   reject such data when it is received as part of a reference and
+   should reject the storage of such data in unencrypted form.  The
+   passing of authentication information in clear text has proven to be
+   a security risk in almost every case where it has been used.
+
+   Applications that render a URI for the sake of user feedback, such as
+   in graphical hypertext browsing, should render userinfo in a way that
+   is distinguished from the rest of a URI, when feasible.  Such
+   rendering will assist the user in cases where the userinfo has been
+   misleadingly crafted to look like a trusted domain name
+   (Section 7.6).
+
+3.2.2.  Host
+
+   The host subcomponent of authority is identified by an IP literal
+   encapsulated within square brackets, an IPv4 address in dotted-
+   decimal form, or a registered name.  The host subcomponent is case-
+   insensitive.  The presence of a host subcomponent within a URI does
+   not imply that the scheme requires access to the given host on the
+   Internet.  In many cases, the host syntax is used only for the sake
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 18]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   of reusing the existing registration process created and deployed for
+   DNS, thus obtaining a globally unique name without the cost of
+   deploying another registry.  However, such use comes with its own
+   costs: domain name ownership may change over time for reasons not
+   anticipated by the URI producer.  In other cases, the data within the
+   host component identifies a registered name that has nothing to do
+   with an Internet host.  We use the name "host" for the ABNF rule
+   because that is its most common purpose, not its only purpose.
+
+      host        = IP-literal / IPv4address / reg-name
+
+   The syntax rule for host is ambiguous because it does not completely
+   distinguish between an IPv4address and a reg-name.  In order to
+   disambiguate the syntax, we apply the "first-match-wins" algorithm:
+   If host matches the rule for IPv4address, then it should be
+   considered an IPv4 address literal and not a reg-name.  Although host
+   is case-insensitive, producers and normalizers should use lowercase
+   for registered names and hexadecimal addresses for the sake of
+   uniformity, while only using uppercase letters for percent-encodings.
+
+   A host identified by an Internet Protocol literal address, version 6
+   [RFC3513] or later, is distinguished by enclosing the IP literal
+   within square brackets ("[" and "]").  This is the only place where
+   square bracket characters are allowed in the URI syntax.  In
+   anticipation of future, as-yet-undefined IP literal address formats,
+   an implementation may use an optional version flag to indicate such a
+   format explicitly rather than rely on heuristic determination.
+
+      IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
+
+      IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
+
+   The version flag does not indicate the IP version; rather, it
+   indicates future versions of the literal format.  As such,
+   implementations must not provide the version flag for the existing
+   IPv4 and IPv6 literal address forms described below.  If a URI
+   containing an IP-literal that starts with "v" (case-insensitive),
+   indicating that the version flag is present, is dereferenced by an
+   application that does not know the meaning of that version flag, then
+   the application should return an appropriate error for "address
+   mechanism not supported".
+
+   A host identified by an IPv6 literal address is represented inside
+   the square brackets without a preceding version flag.  The ABNF
+   provided here is a translation of the text definition of an IPv6
+   literal address provided in [RFC3513].  This syntax does not support
+   IPv6 scoped addressing zone identifiers.
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 19]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   A 128-bit IPv6 address is divided into eight 16-bit pieces.  Each
+   piece is represented numerically in case-insensitive hexadecimal,
+   using one to four hexadecimal digits (leading zeroes are permitted).
+   The eight encoded pieces are given most-significant first, separated
+   by colon characters.  Optionally, the least-significant two pieces
+   may instead be represented in IPv4 address textual format.  A
+   sequence of one or more consecutive zero-valued 16-bit pieces within
+   the address may be elided, omitting all their digits and leaving
+   exactly two consecutive colons in their place to mark the elision.
+
+      IPv6address =                            6( h16 ":" ) ls32
+                  /                       "::" 5( h16 ":" ) ls32
+                  / [               h16 ] "::" 4( h16 ":" ) ls32
+                  / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
+                  / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
+                  / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
+                  / [ *4( h16 ":" ) h16 ] "::"              ls32
+                  / [ *5( h16 ":" ) h16 ] "::"              h16
+                  / [ *6( h16 ":" ) h16 ] "::"
+
+      ls32        = ( h16 ":" h16 ) / IPv4address
+                  ; least-significant 32 bits of address
+
+      h16         = 1*4HEXDIG
+                  ; 16 bits of address represented in hexadecimal
+
+   A host identified by an IPv4 literal address is represented in
+   dotted-decimal notation (a sequence of four decimal numbers in the
+   range 0 to 255, separated by "."), as described in [RFC1123] by
+   reference to [RFC0952].  Note that other forms of dotted notation may
+   be interpreted on some platforms, as described in Section 7.4, but
+   only the dotted-decimal form of four octets is allowed by this
+   grammar.
+
+      IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
+
+      dec-octet   = DIGIT                 ; 0-9
+                  / %x31-39 DIGIT         ; 10-99
+                  / "1" 2DIGIT            ; 100-199
+                  / "2" %x30-34 DIGIT     ; 200-249
+                  / "25" %x30-35          ; 250-255
+
+   A host identified by a registered name is a sequence of characters
+   usually intended for lookup within a locally defined host or service
+   name registry, though the URI's scheme-specific semantics may require
+   that a specific registry (or fixed name table) be used instead.  The
+   most common name registry mechanism is the Domain Name System (DNS).
+   A registered name intended for lookup in the DNS uses the syntax
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 20]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
+   Such a name consists of a sequence of domain labels separated by ".",
+   each domain label starting and ending with an alphanumeric character
+   and possibly also containing "-" characters.  The rightmost domain
+   label of a fully qualified domain name in DNS may be followed by a
+   single "." and should be if it is necessary to distinguish between
+   the complete domain name and some local domain.
+
+      reg-name    = *( unreserved / pct-encoded / sub-delims )
+
+   If the URI scheme defines a default for host, then that default
+   applies when the host subcomponent is undefined or when the
+   registered name is empty (zero length).  For example, the "file" URI
+   scheme is defined so that no authority, an empty host, and
+   "localhost" all mean the end-user's machine, whereas the "http"
+   scheme considers a missing authority or empty host invalid.
+
+   This specification does not mandate a particular registered name
+   lookup technology and therefore does not restrict the syntax of reg-
+   name beyond what is necessary for interoperability.  Instead, it
+   delegates the issue of registered name syntax conformance to the
+   operating system of each application performing URI resolution, and
+   that operating system decides what it will allow for the purpose of
+   host identification.  A URI resolution implementation might use DNS,
+   host tables, yellow pages, NetInfo, WINS, or any other system for
+   lookup of registered names.  However, a globally scoped naming
+   system, such as DNS fully qualified domain names, is necessary for
+   URIs intended to have global scope.  URI producers should use names
+   that conform to the DNS syntax, even when use of DNS is not
+   immediately apparent, and should limit these names to no more than
+   255 characters in length.
+
+   The reg-name syntax allows percent-encoded octets in order to
+   represent non-ASCII registered names in a uniform way that is
+   independent of the underlying name resolution technology.  Non-ASCII
+   characters must first be encoded according to UTF-8 [STD63], and then
+   each octet of the corresponding UTF-8 sequence must be percent-
+   encoded to be represented as URI characters.  URI producing
+   applications must not use percent-encoding in host unless it is used
+   to represent a UTF-8 character sequence.  When a non-ASCII registered
+   name represents an internationalized domain name intended for
+   resolution via the DNS, the name must be transformed to the IDNA
+   encoding [RFC3490] prior to name lookup.  URI producers should
+   provide these registered names in the IDNA encoding, rather than a
+   percent-encoding, if they wish to maximize interoperability with
+   legacy URI resolvers.
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 21]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+3.2.3.  Port
+
+   The port subcomponent of authority is designated by an optional port
+   number in decimal following the host and delimited from it by a
+   single colon (":") character.
+
+      port        = *DIGIT
+
+   A scheme may define a default port.  For example, the "http" scheme
+   defines a default port of "80", corresponding to its reserved TCP
+   port number.  The type of port designated by the port number (e.g.,
+   TCP, UDP, SCTP) is defined by the URI scheme.  URI producers and
+   normalizers should omit the port component and its ":" delimiter if
+   port is empty or if its value would be the same as that of the
+   scheme's default.
+
+3.3.  Path
+
+   The path component contains data, usually organized in hierarchical
+   form, that, along with data in the non-hierarchical query component
+   (Section 3.4), serves to identify a resource within the scope of the
+   URI's scheme and naming authority (if any).  The path is terminated
+   by the first question mark ("?") or number sign ("#") character, or
+   by the end of the URI.
+
+   If a URI contains an authority component, then the path component
+   must either be empty or begin with a slash ("/") character.  If a URI
+   does not contain an authority component, then the path cannot begin
+   with two slash characters ("//").  In addition, a URI reference
+   (Section 4.1) may be a relative-path reference, in which case the
+   first path segment cannot contain a colon (":") character.  The ABNF
+   requires five separate rules to disambiguate these cases, only one of
+   which will match the path substring within a given URI reference.  We
+   use the generic term "path component" to describe the URI substring
+   matched by the parser to one of these rules.
+
+      path          = path-abempty    ; begins with "/" or is empty
+                    / path-absolute   ; begins with "/" but not "//"
+                    / path-noscheme   ; begins with a non-colon segment
+                    / path-rootless   ; begins with a segment
+                    / path-empty      ; zero characters
+
+      path-abempty  = *( "/" segment )
+      path-absolute = "/" [ segment-nz *( "/" segment ) ]
+      path-noscheme = segment-nz-nc *( "/" segment )
+      path-rootless = segment-nz *( "/" segment )
+      path-empty    = 0<pchar>
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 22]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      segment       = *pchar
+      segment-nz    = 1*pchar
+      segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
+                    ; non-zero-length segment without any colon ":"
+
+      pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
+
+   A path consists of a sequence of path segments separated by a slash
+   ("/") character.  A path is always defined for a URI, though the
+   defined path may be empty (zero length).  Use of the slash character
+   to indicate hierarchy is only required when a URI will be used as the
+   context for relative references.  For example, the URI
+   <mailto:fred@example.com> has a path of "fred@example.com", whereas
+   the URI <foo://info.example.com?fred> has an empty path.
+
+   The path segments "." and "..", also known as dot-segments, are
+   defined for relative reference within the path name hierarchy.  They
+   are intended for use at the beginning of a relative-path reference
+   (Section 4.2) to indicate relative position within the hierarchical
+   tree of names.  This is similar to their role within some operating
+   systems' file directory structures to indicate the current directory
+   and parent directory, respectively.  However, unlike in a file
+   system, these dot-segments are only interpreted within the URI path
+   hierarchy and are removed as part of the resolution process (Section
+   5.2).
+
+   Aside from dot-segments in hierarchical paths, a path segment is
+   considered opaque by the generic syntax.  URI producing applications
+   often use the reserved characters allowed in a segment to delimit
+   scheme-specific or dereference-handler-specific subcomponents.  For
+   example, the semicolon (";") and equals ("=") reserved characters are
+   often used to delimit parameters and parameter values applicable to
+   that segment.  The comma (",") reserved character is often used for
+   similar purposes.  For example, one URI producer might use a segment
+   such as "name;v=1.1" to indicate a reference to version 1.1 of
+   "name", whereas another might use a segment such as "name,1.1" to
+   indicate the same.  Parameter types may be defined by scheme-specific
+   semantics, but in most cases the syntax of a parameter is specific to
+   the implementation of the URI's dereferencing algorithm.
+
+3.4.  Query
+
+   The query component contains non-hierarchical data that, along with
+   data in the path component (Section 3.3), serves to identify a
+   resource within the scope of the URI's scheme and naming authority
+   (if any).  The query component is indicated by the first question
+   mark ("?") character and terminated by a number sign ("#") character
+   or by the end of the URI.
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 23]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      query       = *( pchar / "/" / "?" )
+
+   The characters slash ("/") and question mark ("?") may represent data
+   within the query component.  Beware that some older, erroneous
+   implementations may not handle such data correctly when it is used as
+   the base URI for relative references (Section 5.1), apparently
+   because they fail to distinguish query data from path data when
+   looking for hierarchical separators.  However, as query components
+   are often used to carry identifying information in the form of
+   "key=value" pairs and one frequently used value is a reference to
+   another URI, it is sometimes better for usability to avoid percent-
+   encoding those characters.
+
+3.5.  Fragment
+
+   The fragment identifier component of a URI allows indirect
+   identification of a secondary resource by reference to a primary
+   resource and additional identifying information.  The identified
+   secondary resource may be some portion or subset of the primary
+   resource, some view on representations of the primary resource, or
+   some other resource defined or described by those representations.  A
+   fragment identifier component is indicated by the presence of a
+   number sign ("#") character and terminated by the end of the URI.
+
+      fragment    = *( pchar / "/" / "?" )
+
+   The semantics of a fragment identifier are defined by the set of
+   representations that might result from a retrieval action on the
+   primary resource.  The fragment's format and resolution is therefore
+   dependent on the media type [RFC2046] of a potentially retrieved
+   representation, even though such a retrieval is only performed if the
+   URI is dereferenced.  If no such representation exists, then the
+   semantics of the fragment are considered unknown and are effectively
+   unconstrained.  Fragment identifier semantics are independent of the
+   URI scheme and thus cannot be redefined by scheme specifications.
+
+   Individual media types may define their own restrictions on or
+   structures within the fragment identifier syntax for specifying
+   different types of subsets, views, or external references that are
+   identifiable as secondary resources by that media type.  If the
+   primary resource has multiple representations, as is often the case
+   for resources whose representation is selected based on attributes of
+   the retrieval request (a.k.a., content negotiation), then whatever is
+   identified by the fragment should be consistent across all of those
+   representations.  Each representation should either define the
+   fragment so that it corresponds to the same secondary resource,
+   regardless of how it is represented, or should leave the fragment
+   undefined (i.e., not found).
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 24]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   As with any URI, use of a fragment identifier component does not
+   imply that a retrieval action will take place.  A URI with a fragment
+   identifier may be used to refer to the secondary resource without any
+   implication that the primary resource is accessible or will ever be
+   accessed.
+
+   Fragment identifiers have a special role in information retrieval
+   systems as the primary form of client-side indirect referencing,
+   allowing an author to specifically identify aspects of an existing
+   resource that are only indirectly provided by the resource owner.  As
+   such, the fragment identifier is not used in the scheme-specific
+   processing of a URI; instead, the fragment identifier is separated
+   from the rest of the URI prior to a dereference, and thus the
+   identifying information within the fragment itself is dereferenced
+   solely by the user agent, regardless of the URI scheme.  Although
+   this separate handling is often perceived to be a loss of
+   information, particularly for accurate redirection of references as
+   resources move over time, it also serves to prevent information
+   providers from denying reference authors the right to refer to
+   information within a resource selectively.  Indirect referencing also
+   provides additional flexibility and extensibility to systems that use
+   URIs, as new media types are easier to define and deploy than new
+   schemes of identification.
+
+   The characters slash ("/") and question mark ("?") are allowed to
+   represent data within the fragment identifier.  Beware that some
+   older, erroneous implementations may not handle this data correctly
+   when it is used as the base URI for relative references (Section
+   5.1).
+
+4.  Usage
+
+   When applications make reference to a URI, they do not always use the
+   full form of reference defined by the "URI" syntax rule.  To save
+   space and take advantage of hierarchical locality, many Internet
+   protocol elements and media type formats allow an abbreviation of a
+   URI, whereas others restrict the syntax to a particular form of URI.
+   We define the most common forms of reference syntax in this
+   specification because they impact and depend upon the design of the
+   generic syntax, requiring a uniform parsing algorithm in order to be
+   interpreted consistently.
+
+4.1.  URI Reference
+
+   URI-reference is used to denote the most common usage of a resource
+   identifier.
+
+      URI-reference = URI / relative-ref
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 25]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   A URI-reference is either a URI or a relative reference.  If the
+   URI-reference's prefix does not match the syntax of a scheme followed
+   by its colon separator, then the URI-reference is a relative
+   reference.
+
+   A URI-reference is typically parsed first into the five URI
+   components, in order to determine what components are present and
+   whether the reference is relative.  Then, each component is parsed
+   for its subparts and their validation.  The ABNF of URI-reference,
+   along with the "first-match-wins" disambiguation rule, is sufficient
+   to define a validating parser for the generic syntax.  Readers
+   familiar with regular expressions should see Appendix B for an
+   example of a non-validating URI-reference parser that will take any
+   given string and extract the URI components.
+
+4.2.  Relative Reference
+
+   A relative reference takes advantage of the hierarchical syntax
+   (Section 1.2.3) to express a URI reference relative to the name space
+   of another hierarchical URI.
+
+      relative-ref  = relative-part [ "?" query ] [ "#" fragment ]
+
+      relative-part = "//" authority path-abempty
+                    / path-absolute
+                    / path-noscheme
+                    / path-empty
+
+   The URI referred to by a relative reference, also known as the target
+   URI, is obtained by applying the reference resolution algorithm of
+   Section 5.
+
+   A relative reference that begins with two slash characters is termed
+   a network-path reference; such references are rarely used.  A
+   relative reference that begins with a single slash character is
+   termed an absolute-path reference.  A relative reference that does
+   not begin with a slash character is termed a relative-path reference.
+
+   A path segment that contains a colon character (e.g., "this:that")
+   cannot be used as the first segment of a relative-path reference, as
+   it would be mistaken for a scheme name.  Such a segment must be
+   preceded by a dot-segment (e.g., "./this:that") to make a relative-
+   path reference.
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 26]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+4.3.  Absolute URI
+
+   Some protocol elements allow only the absolute form of a URI without
+   a fragment identifier.  For example, defining a base URI for later
+   use by relative references calls for an absolute-URI syntax rule that
+   does not allow a fragment.
+
+      absolute-URI  = scheme ":" hier-part [ "?" query ]
+
+   URI scheme specifications must define their own syntax so that all
+   strings matching their scheme-specific syntax will also match the
+   <absolute-URI> grammar.  Scheme specifications will not define
+   fragment identifier syntax or usage, regardless of its applicability
+   to resources identifiable via that scheme, as fragment identification
+   is orthogonal to scheme definition.  However, scheme specifications
+   are encouraged to include a wide range of examples, including
+   examples that show use of the scheme's URIs with fragment identifiers
+   when such usage is appropriate.
+
+4.4.  Same-Document Reference
+
+   When a URI reference refers to a URI that is, aside from its fragment
+   component (if any), identical to the base URI (Section 5.1), that
+   reference is called a "same-document" reference.  The most frequent
+   examples of same-document references are relative references that are
+   empty or include only the number sign ("#") separator followed by a
+   fragment identifier.
+
+   When a same-document reference is dereferenced for a retrieval
+   action, the target of that reference is defined to be within the same
+   entity (representation, document, or message) as the reference;
+   therefore, a dereference should not result in a new retrieval action.
+
+   Normalization of the base and target URIs prior to their comparison,
+   as described in Sections 6.2.2 and 6.2.3, is allowed but rarely
+   performed in practice.  Normalization may increase the set of same-
+   document references, which may be of benefit to some caching
+   applications.  As such, reference authors should not assume that a
+   slightly different, though equivalent, reference URI will (or will
+   not) be interpreted as a same-document reference by any given
+   application.
+
+4.5.  Suffix Reference
+
+   The URI syntax is designed for unambiguous reference to resources and
+   extensibility via the URI scheme.  However, as URI identification and
+   usage have become commonplace, traditional media (television, radio,
+   newspapers, billboards, etc.) have increasingly used a suffix of the
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 27]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   URI as a reference, consisting of only the authority and path
+   portions of the URI, such as
+
+      www.w3.org/Addressing/
+
+   or simply a DNS registered name on its own.  Such references are
+   primarily intended for human interpretation rather than for machines,
+   with the assumption that context-based heuristics are sufficient to
+   complete the URI (e.g., most registered names beginning with "www"
+   are likely to have a URI prefix of "http://").  Although there is no
+   standard set of heuristics for disambiguating a URI suffix, many
+   client implementations allow them to be entered by the user and
+   heuristically resolved.
+
+   Although this practice of using suffix references is common, it
+   should be avoided whenever possible and should never be used in
+   situations where long-term references are expected.  The heuristics
+   noted above will change over time, particularly when a new URI scheme
+   becomes popular, and are often incorrect when used out of context.
+   Furthermore, they can lead to security issues along the lines of
+   those described in [RFC1535].
+
+   As a URI suffix has the same syntax as a relative-path reference, a
+   suffix reference cannot be used in contexts where a relative
+   reference is expected.  As a result, suffix references are limited to
+   places where there is no defined base URI, such as dialog boxes and
+   off-line advertisements.
+
+5.  Reference Resolution
+
+   This section defines the process of resolving a URI reference within
+   a context that allows relative references so that the result is a
+   string matching the <URI> syntax rule of Section 3.
+
+5.1.  Establishing a Base URI
+
+   The term "relative" implies that a "base URI" exists against which
+   the relative reference is applied.  Aside from fragment-only
+   references (Section 4.4), relative references are only usable when a
+   base URI is known.  A base URI must be established by the parser
+   prior to parsing URI references that might be relative.  A base URI
+   must conform to the <absolute-URI> syntax rule (Section 4.3).  If the
+   base URI is obtained from a URI reference, then that reference must
+   be converted to absolute form and stripped of any fragment component
+   prior to its use as a base URI.
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 28]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   The base URI of a reference can be established in one of four ways,
+   discussed below in order of precedence.  The order of precedence can
+   be thought of in terms of layers, where the innermost defined base
+   URI has the highest precedence.  This can be visualized graphically
+   as follows:
+
+         .----------------------------------------------------------.
+         |  .----------------------------------------------------.  |
+         |  |  .----------------------------------------------.  |  |
+         |  |  |  .----------------------------------------.  |  |  |
+         |  |  |  |  .----------------------------------.  |  |  |  |
+         |  |  |  |  |       <relative-reference>       |  |  |  |  |
+         |  |  |  |  `----------------------------------'  |  |  |  |
+         |  |  |  | (5.1.1) Base URI embedded in content   |  |  |  |
+         |  |  |  `----------------------------------------'  |  |  |
+         |  |  | (5.1.2) Base URI of the encapsulating entity |  |  |
+         |  |  |         (message, representation, or none)   |  |  |
+         |  |  `----------------------------------------------'  |  |
+         |  | (5.1.3) URI used to retrieve the entity            |  |
+         |  `----------------------------------------------------'  |
+         | (5.1.4) Default Base URI (application-dependent)         |
+         `----------------------------------------------------------'
+
+5.1.1.  Base URI Embedded in Content
+
+   Within certain media types, a base URI for relative references can be
+   embedded within the content itself so that it can be readily obtained
+   by a parser.  This can be useful for descriptive documents, such as
+   tables of contents, which may be transmitted to others through
+   protocols other than their usual retrieval context (e.g., email or
+   USENET news).
+
+   It is beyond the scope of this specification to specify how, for each
+   media type, a base URI can be embedded.  The appropriate syntax, when
+   available, is described by the data format specification associated
+   with each media type.
+
+5.1.2.  Base URI from the Encapsulating Entity
+
+   If no base URI is embedded, the base URI is defined by the
+   representation's retrieval context.  For a document that is enclosed
+   within another entity, such as a message or archive, the retrieval
+   context is that entity.  Thus, the default base URI of a
+   representation is the base URI of the entity in which the
+   representation is encapsulated.
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 29]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   A mechanism for embedding a base URI within MIME container types
+   (e.g., the message and multipart types) is defined by MHTML
+   [RFC2557].  Protocols that do not use the MIME message header syntax,
+   but that do allow some form of tagged metadata to be included within
+   messages, may define their own syntax for defining a base URI as part
+   of a message.
+
+5.1.3.  Base URI from the Retrieval URI
+
+   If no base URI is embedded and the representation is not encapsulated
+   within some other entity, then, if a URI was used to retrieve the
+   representation, that URI shall be considered the base URI.  Note that
+   if the retrieval was the result of a redirected request, the last URI
+   used (i.e., the URI that resulted in the actual retrieval of the
+   representation) is the base URI.
+
+5.1.4.  Default Base URI
+
+   If none of the conditions described above apply, then the base URI is
+   defined by the context of the application.  As this definition is
+   necessarily application-dependent, failing to define a base URI by
+   using one of the other methods may result in the same content being
+   interpreted differently by different types of applications.
+
+   A sender of a representation containing relative references is
+   responsible for ensuring that a base URI for those references can be
+   established.  Aside from fragment-only references, relative
+   references can only be used reliably in situations where the base URI
+   is well defined.
+
+5.2.  Relative Resolution
+
+   This section describes an algorithm for converting a URI reference
+   that might be relative to a given base URI into the parsed components
+   of the reference's target.  The components can then be recomposed, as
+   described in Section 5.3, to form the target URI.  This algorithm
+   provides definitive results that can be used to test the output of
+   other implementations.  Applications may implement relative reference
+   resolution by using some other algorithm, provided that the results
+   match what would be given by this one.
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 30]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+5.2.1.  Pre-parse the Base URI
+
+   The base URI (Base) is established according to the procedure of
+   Section 5.1 and parsed into the five main components described in
+   Section 3.  Note that only the scheme component is required to be
+   present in a base URI; the other components may be empty or
+   undefined.  A component is undefined if its associated delimiter does
+   not appear in the URI reference; the path component is never
+   undefined, though it may be empty.
+
+   Normalization of the base URI, as described in Sections 6.2.2 and
+   6.2.3, is optional.  A URI reference must be transformed to its
+   target URI before it can be normalized.
+
+5.2.2.  Transform References
+
+   For each URI reference (R), the following pseudocode describes an
+   algorithm for transforming R into its target URI (T):
+
+      -- The URI reference is parsed into the five URI components
+      --
+      (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);
+
+      -- A non-strict parser may ignore a scheme in the reference
+      -- if it is identical to the base URI's scheme.
+      --
+      if ((not strict) and (R.scheme == Base.scheme)) then
+         undefine(R.scheme);
+      endif;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 31]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      if defined(R.scheme) then
+         T.scheme    = R.scheme;
+         T.authority = R.authority;
+         T.path      = remove_dot_segments(R.path);
+         T.query     = R.query;
+      else
+         if defined(R.authority) then
+            T.authority = R.authority;
+            T.path      = remove_dot_segments(R.path);
+            T.query     = R.query;
+         else
+            if (R.path == "") then
+               T.path = Base.path;
+               if defined(R.query) then
+                  T.query = R.query;
+               else
+                  T.query = Base.query;
+               endif;
+            else
+               if (R.path starts-with "/") then
+                  T.path = remove_dot_segments(R.path);
+               else
+                  T.path = merge(Base.path, R.path);
+                  T.path = remove_dot_segments(T.path);
+               endif;
+               T.query = R.query;
+            endif;
+            T.authority = Base.authority;
+         endif;
+         T.scheme = Base.scheme;
+      endif;
+
+      T.fragment = R.fragment;
+
+5.2.3.  Merge Paths
+
+   The pseudocode above refers to a "merge" routine for merging a
+   relative-path reference with the path of the base URI.  This is
+   accomplished as follows:
+
+   o  If the base URI has a defined authority component and an empty
+      path, then return a string consisting of "/" concatenated with the
+      reference's path; otherwise,
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 32]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   o  return a string consisting of the reference's path component
+      appended to all but the last segment of the base URI's path (i.e.,
+      excluding any characters after the right-most "/" in the base URI
+      path, or excluding the entire base URI path if it does not contain
+      any "/" characters).
+
+5.2.4.  Remove Dot Segments
+
+   The pseudocode also refers to a "remove_dot_segments" routine for
+   interpreting and removing the special "." and ".." complete path
+   segments from a referenced path.  This is done after the path is
+   extracted from a reference, whether or not the path was relative, in
+   order to remove any invalid or extraneous dot-segments prior to
+   forming the target URI.  Although there are many ways to accomplish
+   this removal process, we describe a simple method using two string
+   buffers.
+
+   1.  The input buffer is initialized with the now-appended path
+       components and the output buffer is initialized to the empty
+       string.
+
+   2.  While the input buffer is not empty, loop as follows:
+
+       A.  If the input buffer begins with a prefix of "../" or "./",
+           then remove that prefix from the input buffer; otherwise,
+
+       B.  if the input buffer begins with a prefix of "/./" or "/.",
+           where "." is a complete path segment, then replace that
+           prefix with "/" in the input buffer; otherwise,
+
+       C.  if the input buffer begins with a prefix of "/../" or "/..",
+           where ".." is a complete path segment, then replace that
+           prefix with "/" in the input buffer and remove the last
+           segment and its preceding "/" (if any) from the output
+           buffer; otherwise,
+
+       D.  if the input buffer consists only of "." or "..", then remove
+           that from the input buffer; otherwise,
+
+       E.  move the first path segment in the input buffer to the end of
+           the output buffer, including the initial "/" character (if
+           any) and any subsequent characters up to, but not including,
+           the next "/" character or the end of the input buffer.
+
+   3.  Finally, the output buffer is returned as the result of
+       remove_dot_segments.
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 33]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   Note that dot-segments are intended for use in URI references to
+   express an identifier relative to the hierarchy of names in the base
+   URI.  The remove_dot_segments algorithm respects that hierarchy by
+   removing extra dot-segments rather than treat them as an error or
+   leaving them to be misinterpreted by dereference implementations.
+
+   The following illustrates how the above steps are applied for two
+   examples of merged paths, showing the state of the two buffers after
+   each step.
+
+      STEP   OUTPUT BUFFER         INPUT BUFFER
+
+       1 :                         /a/b/c/./../../g
+       2E:   /a                    /b/c/./../../g
+       2E:   /a/b                  /c/./../../g
+       2E:   /a/b/c                /./../../g
+       2B:   /a/b/c                /../../g
+       2C:   /a/b                  /../g
+       2C:   /a                    /g
+       2E:   /a/g
+
+      STEP   OUTPUT BUFFER         INPUT BUFFER
+
+       1 :                         mid/content=5/../6
+       2E:   mid                   /content=5/../6
+       2E:   mid/content=5         /../6
+       2C:   mid                   /6
+       2E:   mid/6
+
+   Some applications may find it more efficient to implement the
+   remove_dot_segments algorithm by using two segment stacks rather than
+   strings.
+
+      Note: Beware that some older, erroneous implementations will fail
+      to separate a reference's query component from its path component
+      prior to merging the base and reference paths, resulting in an
+      interoperability failure if the query component contains the
+      strings "/../" or "/./".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 34]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+5.3.  Component Recomposition
+
+   Parsed URI components can be recomposed to obtain the corresponding
+   URI reference string.  Using pseudocode, this would be:
+
+      result = ""
+
+      if defined(scheme) then
+         append scheme to result;
+         append ":" to result;
+      endif;
+
+      if defined(authority) then
+         append "//" to result;
+         append authority to result;
+      endif;
+
+      append path to result;
+
+      if defined(query) then
+         append "?" to result;
+         append query to result;
+      endif;
+
+      if defined(fragment) then
+         append "#" to result;
+         append fragment to result;
+      endif;
+
+      return result;
+
+   Note that we are careful to preserve the distinction between a
+   component that is undefined, meaning that its separator was not
+   present in the reference, and a component that is empty, meaning that
+   the separator was present and was immediately followed by the next
+   component separator or the end of the reference.
+
+5.4.  Reference Resolution Examples
+
+   Within a representation with a well defined base URI of
+
+      http://a/b/c/d;p?q
+
+   a relative reference is transformed to its target URI as follows.
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 35]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+5.4.1.  Normal Examples
+
+      "g:h"           =  "g:h"
+      "g"             =  "http://a/b/c/g"
+      "./g"           =  "http://a/b/c/g"
+      "g/"            =  "http://a/b/c/g/"
+      "/g"            =  "http://a/g"
+      "//g"           =  "http://g"
+      "?y"            =  "http://a/b/c/d;p?y"
+      "g?y"           =  "http://a/b/c/g?y"
+      "#s"            =  "http://a/b/c/d;p?q#s"
+      "g#s"           =  "http://a/b/c/g#s"
+      "g?y#s"         =  "http://a/b/c/g?y#s"
+      ";x"            =  "http://a/b/c/;x"
+      "g;x"           =  "http://a/b/c/g;x"
+      "g;x?y#s"       =  "http://a/b/c/g;x?y#s"
+      ""              =  "http://a/b/c/d;p?q"
+      "."             =  "http://a/b/c/"
+      "./"            =  "http://a/b/c/"
+      ".."            =  "http://a/b/"
+      "../"           =  "http://a/b/"
+      "../g"          =  "http://a/b/g"
+      "../.."         =  "http://a/"
+      "../../"        =  "http://a/"
+      "../../g"       =  "http://a/g"
+
+5.4.2.  Abnormal Examples
+
+   Although the following abnormal examples are unlikely to occur in
+   normal practice, all URI parsers should be capable of resolving them
+   consistently.  Each example uses the same base as that above.
+
+   Parsers must be careful in handling cases where there are more ".."
+   segments in a relative-path reference than there are hierarchical
+   levels in the base URI's path.  Note that the ".." syntax cannot be
+   used to change the authority component of a URI.
+
+      "../../../g"    =  "http://a/g"
+      "../../../../g" =  "http://a/g"
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 36]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   Similarly, parsers must remove the dot-segments "." and ".." when
+   they are complete components of a path, but not when they are only
+   part of a segment.
+
+      "/./g"          =  "http://a/g"
+      "/../g"         =  "http://a/g"
+      "g."            =  "http://a/b/c/g."
+      ".g"            =  "http://a/b/c/.g"
+      "g.."           =  "http://a/b/c/g.."
+      "..g"           =  "http://a/b/c/..g"
+
+   Less likely are cases where the relative reference uses unnecessary
+   or nonsensical forms of the "." and ".." complete path segments.
+
+      "./../g"        =  "http://a/b/g"
+      "./g/."         =  "http://a/b/c/g/"
+      "g/./h"         =  "http://a/b/c/g/h"
+      "g/../h"        =  "http://a/b/c/h"
+      "g;x=1/./y"     =  "http://a/b/c/g;x=1/y"
+      "g;x=1/../y"    =  "http://a/b/c/y"
+
+   Some applications fail to separate the reference's query and/or
+   fragment components from the path component before merging it with
+   the base path and removing dot-segments.  This error is rarely
+   noticed, as typical usage of a fragment never includes the hierarchy
+   ("/") character and the query component is not normally used within
+   relative references.
+
+      "g?y/./x"       =  "http://a/b/c/g?y/./x"
+      "g?y/../x"      =  "http://a/b/c/g?y/../x"
+      "g#s/./x"       =  "http://a/b/c/g#s/./x"
+      "g#s/../x"      =  "http://a/b/c/g#s/../x"
+
+   Some parsers allow the scheme name to be present in a relative
+   reference if it is the same as the base URI scheme.  This is
+   considered to be a loophole in prior specifications of partial URI
+   [RFC1630].  Its use should be avoided but is allowed for backward
+   compatibility.
+
+      "http:g"        =  "http:g"         ; for strict parsers
+                      /  "http://a/b/c/g" ; for backward compatibility
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 37]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+6.  Normalization and Comparison
+
+   One of the most common operations on URIs is simple comparison:
+   determining whether two URIs are equivalent without using the URIs to
+   access their respective resource(s).  A comparison is performed every
+   time a response cache is accessed, a browser checks its history to
+   color a link, or an XML parser processes tags within a namespace.
+   Extensive normalization prior to comparison of URIs is often used by
+   spiders and indexing engines to prune a search space or to reduce
+   duplication of request actions and response storage.
+
+   URI comparison is performed for some particular purpose.  Protocols
+   or implementations that compare URIs for different purposes will
+   often be subject to differing design trade-offs in regards to how
+   much effort should be spent in reducing aliased identifiers.  This
+   section describes various methods that may be used to compare URIs,
+   the trade-offs between them, and the types of applications that might
+   use them.
+
+6.1.  Equivalence
+
+   Because URIs exist to identify resources, presumably they should be
+   considered equivalent when they identify the same resource.  However,
+   this definition of equivalence is not of much practical use, as there
+   is no way for an implementation to compare two resources unless it
+   has full knowledge or control of them.  For this reason,
+   determination of equivalence or difference of URIs is based on string
+   comparison, perhaps augmented by reference to additional rules
+   provided by URI scheme definitions.  We use the terms "different" and
+   "equivalent" to describe the possible outcomes of such comparisons,
+   but there are many application-dependent versions of equivalence.
+
+   Even though it is possible to determine that two URIs are equivalent,
+   URI comparison is not sufficient to determine whether two URIs
+   identify different resources.  For example, an owner of two different
+   domain names could decide to serve the same resource from both,
+   resulting in two different URIs.  Therefore, comparison methods are
+   designed to minimize false negatives while strictly avoiding false
+   positives.
+
+   In testing for equivalence, applications should not directly compare
+   relative references; the references should be converted to their
+   respective target URIs before comparison.  When URIs are compared to
+   select (or avoid) a network action, such as retrieval of a
+   representation, fragment components (if any) should be excluded from
+   the comparison.
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 38]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+6.2.  Comparison Ladder
+
+   A variety of methods are used in practice to test URI equivalence.
+   These methods fall into a range, distinguished by the amount of
+   processing required and the degree to which the probability of false
+   negatives is reduced.  As noted above, false negatives cannot be
+   eliminated.  In practice, their probability can be reduced, but this
+   reduction requires more processing and is not cost-effective for all
+   applications.
+
+   If this range of comparison practices is considered as a ladder, the
+   following discussion will climb the ladder, starting with practices
+   that are cheap but have a relatively higher chance of producing false
+   negatives, and proceeding to those that have higher computational
+   cost and lower risk of false negatives.
+
+6.2.1.  Simple String Comparison
+
+   If two URIs, when considered as character strings, are identical,
+   then it is safe to conclude that they are equivalent.  This type of
+   equivalence test has very low computational cost and is in wide use
+   in a variety of applications, particularly in the domain of parsing.
+
+   Testing strings for equivalence requires some basic precautions.
+   This procedure is often referred to as "bit-for-bit" or
+   "byte-for-byte" comparison, which is potentially misleading.  Testing
+   strings for equality is normally based on pair comparison of the
+   characters that make up the strings, starting from the first and
+   proceeding until both strings are exhausted and all characters are
+   found to be equal, until a pair of characters compares unequal, or
+   until one of the strings is exhausted before the other.
+
+   This character comparison requires that each pair of characters be
+   put in comparable form.  For example, should one URI be stored in a
+   byte array in EBCDIC encoding and the second in a Java String object
+   (UTF-16), bit-for-bit comparisons applied naively will produce
+   errors.  It is better to speak of equality on a character-for-
+   character basis rather than on a byte-for-byte or bit-for-bit basis.
+   In practical terms, character-by-character comparisons should be done
+   codepoint-by-codepoint after conversion to a common character
+   encoding.
+
+   False negatives are caused by the production and use of URI aliases.
+   Unnecessary aliases can be reduced, regardless of the comparison
+   method, by consistently providing URI references in an already-
+   normalized form (i.e., a form identical to what would be produced
+   after normalization is applied, as described below).
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 39]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   Protocols and data formats often limit some URI comparisons to simple
+   string comparison, based on the theory that people and
+   implementations will, in their own best interest, be consistent in
+   providing URI references, or at least consistent enough to negate any
+   efficiency that might be obtained from further normalization.
+
+6.2.2.  Syntax-Based Normalization
+
+   Implementations may use logic based on the definitions provided by
+   this specification to reduce the probability of false negatives.
+   This processing is moderately higher in cost than character-for-
+   character string comparison.  For example, an application using this
+   approach could reasonably consider the following two URIs equivalent:
+
+      example://a/b/c/%7Bfoo%7D
+      eXAMPLE://a/./b/../b/%63/%7bfoo%7d
+
+   Web user agents, such as browsers, typically apply this type of URI
+   normalization when determining whether a cached response is
+   available.  Syntax-based normalization includes such techniques as
+   case normalization, percent-encoding normalization, and removal of
+   dot-segments.
+
+6.2.2.1.  Case Normalization
+
+   For all URIs, the hexadecimal digits within a percent-encoding
+   triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
+   should be normalized to use uppercase letters for the digits A-F.
+
+   When a URI uses components of the generic syntax, the component
+   syntax equivalence rules always apply; namely, that the scheme and
+   host are case-insensitive and therefore should be normalized to
+   lowercase.  For example, the URI <HTTP://www.EXAMPLE.com/> is
+   equivalent to <http://www.example.com/>.  The other generic syntax
+   components are assumed to be case-sensitive unless specifically
+   defined otherwise by the scheme (see Section 6.2.3).
+
+6.2.2.2.  Percent-Encoding Normalization
+
+   The percent-encoding mechanism (Section 2.1) is a frequent source of
+   variance among otherwise identical URIs.  In addition to the case
+   normalization issue noted above, some URI producers percent-encode
+   octets that do not require percent-encoding, resulting in URIs that
+   are equivalent to their non-encoded counterparts.  These URIs should
+   be normalized by decoding any percent-encoded octet that corresponds
+   to an unreserved character, as described in Section 2.3.
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 40]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+6.2.2.3.  Path Segment Normalization
+
+   The complete path segments "." and ".." are intended only for use
+   within relative references (Section 4.1) and are removed as part of
+   the reference resolution process (Section 5.2).  However, some
+   deployed implementations incorrectly assume that reference resolution
+   is not necessary when the reference is already a URI and thus fail to
+   remove dot-segments when they occur in non-relative paths.  URI
+   normalizers should remove dot-segments by applying the
+   remove_dot_segments algorithm to the path, as described in
+   Section 5.2.4.
+
+6.2.3.  Scheme-Based Normalization
+
+   The syntax and semantics of URIs vary from scheme to scheme, as
+   described by the defining specification for each scheme.
+   Implementations may use scheme-specific rules, at further processing
+   cost, to reduce the probability of false negatives.  For example,
+   because the "http" scheme makes use of an authority component, has a
+   default port of "80", and defines an empty path to be equivalent to
+   "/", the following four URIs are equivalent:
+
+      http://example.com
+      http://example.com/
+      http://example.com:/
+      http://example.com:80/
+
+   In general, a URI that uses the generic syntax for authority with an
+   empty path should be normalized to a path of "/".  Likewise, an
+   explicit ":port", for which the port is empty or the default for the
+   scheme, is equivalent to one where the port and its ":" delimiter are
+   elided and thus should be removed by scheme-based normalization.  For
+   example, the second URI above is the normal form for the "http"
+   scheme.
+
+   Another case where normalization varies by scheme is in the handling
+   of an empty authority component or empty host subcomponent.  For many
+   scheme specifications, an empty authority or host is considered an
+   error; for others, it is considered equivalent to "localhost" or the
+   end-user's host.  When a scheme defines a default for authority and a
+   URI reference to that default is desired, the reference should be
+   normalized to an empty authority for the sake of uniformity, brevity,
+   and internationalization.  If, however, either the userinfo or port
+   subcomponents are non-empty, then the host should be given explicitly
+   even if it matches the default.
+
+   Normalization should not remove delimiters when their associated
+   component is empty unless licensed to do so by the scheme
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 41]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   specification.  For example, the URI "http://example.com/?" cannot be
+   assumed to be equivalent to any of the examples above.  Likewise, the
+   presence or absence of delimiters within a userinfo subcomponent is
+   usually significant to its interpretation.  The fragment component is
+   not subject to any scheme-based normalization; thus, two URIs that
+   differ only by the suffix "#" are considered different regardless of
+   the scheme.
+
+   Some schemes define additional subcomponents that consist of case-
+   insensitive data, giving an implicit license to normalizers to
+   convert this data to a common case (e.g., all lowercase).  For
+   example, URI schemes that define a subcomponent of path to contain an
+   Internet hostname, such as the "mailto" URI scheme, cause that
+   subcomponent to be case-insensitive and thus subject to case
+   normalization (e.g., "mailto:Joe@Example.COM" is equivalent to
+   "mailto:Joe@example.com", even though the generic syntax considers
+   the path component to be case-sensitive).
+
+   Other scheme-specific normalizations are possible.
+
+6.2.4.  Protocol-Based Normalization
+
+   Substantial effort to reduce the incidence of false negatives is
+   often cost-effective for web spiders.  Therefore, they implement even
+   more aggressive techniques in URI comparison.  For example, if they
+   observe that a URI such as
+
+      http://example.com/data
+
+   redirects to a URI differing only in the trailing slash
+
+      http://example.com/data/
+
+   they will likely regard the two as equivalent in the future.  This
+   kind of technique is only appropriate when equivalence is clearly
+   indicated by both the result of accessing the resources and the
+   common conventions of their scheme's dereference algorithm (in this
+   case, use of redirection by HTTP origin servers to avoid problems
+   with relative references).
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 42]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+7.  Security Considerations
+
+   A URI does not in itself pose a security threat.  However, as URIs
+   are often used to provide a compact set of instructions for access to
+   network resources, care must be taken to properly interpret the data
+   within a URI, to prevent that data from causing unintended access,
+   and to avoid including data that should not be revealed in plain
+   text.
+
+7.1.  Reliability and Consistency
+
+   There is no guarantee that once a URI has been used to retrieve
+   information, the same information will be retrievable by that URI in
+   the future.  Nor is there any guarantee that the information
+   retrievable via that URI in the future will be observably similar to
+   that retrieved in the past.  The URI syntax does not constrain how a
+   given scheme or authority apportions its namespace or maintains it
+   over time.  Such guarantees can only be obtained from the person(s)
+   controlling that namespace and the resource in question.  A specific
+   URI scheme may define additional semantics, such as name persistence,
+   if those semantics are required of all naming authorities for that
+   scheme.
+
+7.2.  Malicious Construction
+
+   It is sometimes possible to construct a URI so that an attempt to
+   perform a seemingly harmless, idempotent operation, such as the
+   retrieval of a representation, will in fact cause a possibly damaging
+   remote operation.  The unsafe URI is typically constructed by
+   specifying a port number other than that reserved for the network
+   protocol in question.  The client unwittingly contacts a site running
+   a different protocol service, and data within the URI contains
+   instructions that, when interpreted according to this other protocol,
+   cause an unexpected operation.  A frequent example of such abuse has
+   been the use of a protocol-based scheme with a port component of
+   "25", thereby fooling user agent software into sending an unintended
+   or impersonating message via an SMTP server.
+
+   Applications should prevent dereference of a URI that specifies a TCP
+   port number within the "well-known port" range (0 - 1023) unless the
+   protocol being used to dereference that URI is compatible with the
+   protocol expected on that well-known port.  Although IANA maintains a
+   registry of well-known ports, applications should make such
+   restrictions user-configurable to avoid preventing the deployment of
+   new services.
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 43]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   When a URI contains percent-encoded octets that match the delimiters
+   for a given resolution or dereference protocol (for example, CR and
+   LF characters for the TELNET protocol), these percent-encodings must
+   not be decoded before transmission across that protocol.  Transfer of
+   the percent-encoding, which might violate the protocol, is less
+   harmful than allowing decoded octets to be interpreted as additional
+   operations or parameters, perhaps triggering an unexpected and
+   possibly harmful remote operation.
+
+7.3.  Back-End Transcoding
+
+   When a URI is dereferenced, the data within it is often parsed by
+   both the user agent and one or more servers.  In HTTP, for example, a
+   typical user agent will parse a URI into its five major components,
+   access the authority's server, and send it the data within the
+   authority, path, and query components.  A typical server will take
+   that information, parse the path into segments and the query into
+   key/value pairs, and then invoke implementation-specific handlers to
+   respond to the request.  As a result, a common security concern for
+   server implementations that handle a URI, either as a whole or split
+   into separate components, is proper interpretation of the octet data
+   represented by the characters and percent-encodings within that URI.
+
+   Percent-encoded octets must be decoded at some point during the
+   dereference process.  Applications must split the URI into its
+   components and subcomponents prior to decoding the octets, as
+   otherwise the decoded octets might be mistaken for delimiters.
+   Security checks of the data within a URI should be applied after
+   decoding the octets.  Note, however, that the "%00" percent-encoding
+   (NUL) may require special handling and should be rejected if the
+   application is not expecting to receive raw data within a component.
+
+   Special care should be taken when the URI path interpretation process
+   involves the use of a back-end file system or related system
+   functions.  File systems typically assign an operational meaning to
+   special characters, such as the "/", "\", ":", "[", and "]"
+   characters, and to special device names like ".", "..", "...", "aux",
+   "lpt", etc.  In some cases, merely testing for the existence of such
+   a name will cause the operating system to pause or invoke unrelated
+   system calls, leading to significant security concerns regarding
+   denial of service and unintended data transfer.  It would be
+   impossible for this specification to list all such significant
+   characters and device names.  Implementers should research the
+   reserved names and characters for the types of storage device that
+   may be attached to their applications and restrict the use of data
+   obtained from URI components accordingly.
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 44]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+7.4.  Rare IP Address Formats
+
+   Although the URI syntax for IPv4address only allows the common
+   dotted-decimal form of IPv4 address literal, many implementations
+   that process URIs make use of platform-dependent system routines,
+   such as gethostbyname() and inet_aton(), to translate the string
+   literal to an actual IP address.  Unfortunately, such system routines
+   often allow and process a much larger set of formats than those
+   described in Section 3.2.2.
+
+   For example, many implementations allow dotted forms of three
+   numbers, wherein the last part is interpreted as a 16-bit quantity
+   and placed in the right-most two bytes of the network address (e.g.,
+   a Class B network).  Likewise, a dotted form of two numbers means
+   that the last part is interpreted as a 24-bit quantity and placed in
+   the right-most three bytes of the network address (Class A), and a
+   single number (without dots) is interpreted as a 32-bit quantity and
+   stored directly in the network address.  Adding further to the
+   confusion, some implementations allow each dotted part to be
+   interpreted as decimal, octal, or hexadecimal, as specified in the C
+   language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0
+   implies octal; otherwise, the number is interpreted as decimal).
+
+   These additional IP address formats are not allowed in the URI syntax
+   due to differences between platform implementations.  However, they
+   can become a security concern if an application attempts to filter
+   access to resources based on the IP address in string literal format.
+   If this filtering is performed, literals should be converted to
+   numeric form and filtered based on the numeric value, and not on a
+   prefix or suffix of the string form.
+
+7.5.  Sensitive Information
+
+   URI producers should not provide a URI that contains a username or
+   password that is intended to be secret.  URIs are frequently
+   displayed by browsers, stored in clear text bookmarks, and logged by
+   user agent history and intermediary applications (proxies).  A
+   password appearing within the userinfo component is deprecated and
+   should be considered an error (or simply ignored) except in those
+   rare cases where the 'password' parameter is intended to be public.
+
+7.6.  Semantic Attacks
+
+   Because the userinfo subcomponent is rarely used and appears before
+   the host in the authority component, it can be used to construct a
+   URI intended to mislead a human user by appearing to identify one
+   (trusted) naming authority while actually identifying a different
+   authority hidden behind the noise.  For example
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 45]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_story.htm
+
+   might lead a human user to assume that the host is 'cnn.example.com',
+   whereas it is actually '10.0.0.1'.  Note that a misleading userinfo
+   subcomponent could be much longer than the example above.
+
+   A misleading URI, such as that above, is an attack on the user's
+   preconceived notions about the meaning of a URI rather than an attack
+   on the software itself.  User agents may be able to reduce the impact
+   of such attacks by distinguishing the various components of the URI
+   when they are rendered, such as by using a different color or tone to
+   render userinfo if any is present, though there is no panacea.  More
+   information on URI-based semantic attacks can be found in [Siedzik].
+
+8.  IANA Considerations
+
+   URI scheme names, as defined by <scheme> in Section 3.1, form a
+   registered namespace that is managed by IANA according to the
+   procedures defined in [BCP35].  No IANA actions are required by this
+   document.
+
+9.  Acknowledgements
+
+   This specification is derived from RFC 2396 [RFC2396], RFC 1808
+   [RFC1808], and RFC 1738 [RFC1738]; the acknowledgements in those
+   documents still apply.  It also incorporates the update (with
+   corrections) for IPv6 literals in the host syntax, as defined by
+   Robert M. Hinden, Brian E. Carpenter, and Larry Masinter in
+   [RFC2732].  In addition, contributions by Gisle Aas, Reese Anschultz,
+   Daniel Barclay, Tim Bray, Mike Brown, Rob Cameron, Jeremy Carroll,
+   Dan Connolly, Adam M. Costello, John Cowan, Jason Diamond, Martin
+   Duerst, Stefan Eissing, Clive D.W. Feather, Al Gilman, Tony Hammond,
+   Elliotte Harold, Pat Hayes, Henry Holtzman, Ian B. Jacobs, Michael
+   Kay, John C. Klensin, Graham Klyne, Dan Kohn, Bruce Lilly, Andrew
+   Main, Dave McAlpin, Ira McDonald, Michael Mealling, Ray Merkert,
+   Stephen Pollei, Julian Reschke, Tomas Rokicki, Miles Sabin, Kai
+   Schaetzl, Mark Thomson, Ronald Tschalaer, Norm Walsh, Marc Warne,
+   Stuart Williams, and Henry Zongaro are gratefully acknowledged.
+
+10.  References
+
+10.1.  Normative References
+
+   [ASCII]    American National Standards Institute, "Coded Character
+              Set -- 7-bit American Standard Code for Information
+              Interchange", ANSI X3.4, 1986.
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 46]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [STD63]    Yergeau, F., "UTF-8, a transformation format of
+              ISO 10646", STD 63, RFC 3629, November 2003.
+
+   [UCS]      International Organization for Standardization,
+              "Information Technology - Universal Multiple-Octet Coded
+              Character Set (UCS)", ISO/IEC 10646:2003, December 2003.
+
+10.2.  Informative References
+
+   [BCP19]    Freed, N. and J. Postel, "IANA Charset Registration
+              Procedures", BCP 19, RFC 2978, October 2000.
+
+   [BCP35]    Petke, R. and I. King, "Registration Procedures for URL
+              Scheme Names", BCP 35, RFC 2717, November 1999.
+
+   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
+              host table specification", RFC 952, October 1985.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
+              With Widely Deployed DNS Software", RFC 1535,
+              October 1993.
+
+   [RFC1630]  Berners-Lee, T., "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, June 1994.
+
+   [RFC1736]  Kunze, J., "Functional Recommendations for Internet
+              Resource Locators", RFC 1736, February 1995.
+
+   [RFC1737]  Sollins, K. and L. Masinter, "Functional Requirements for
+              Uniform Resource Names", RFC 1737, December 1994.
+
+   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+              Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC1808]  Fielding, R., "Relative Uniform Resource Locators",
+              RFC 1808, June 1995.
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 47]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
+              Jensen, "HTTP Extensions for Distributed Authoring --
+              WEBDAV", RFC 2518, February 1999.
+
+   [RFC2557]  Palme, J., Hopmann, A., and N. Shelness, "MIME
+              Encapsulation of Aggregate Documents, such as HTML
+              (MHTML)", RFC 2557, March 1999.
+
+   [RFC2718]  Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
+              "Guidelines for new URL Schemes", RFC 2718, November 1999.
+
+   [RFC2732]  Hinden, R., Carpenter, B., and L. Masinter, "Format for
+              Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
+
+   [RFC3305]  Mealling, M. and R. Denenberg, "Report from the Joint
+              W3C/IETF URI Planning Interest Group: Uniform Resource
+              Identifiers (URIs), URLs, and Uniform Resource Names
+              (URNs): Clarifications and Recommendations", RFC 3305,
+              August 2002.
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [Siedzik]  Siedzik, R., "Semantic Attacks: What's in a URL?",
+              April 2001, <http://www.giac.org/practical/gsec/
+              Richard_Siedzik_GSEC.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 48]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+Appendix A.  Collected ABNF for URI
+
+   URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
+
+   hier-part     = "//" authority path-abempty
+                 / path-absolute
+                 / path-rootless
+                 / path-empty
+
+   URI-reference = URI / relative-ref
+
+   absolute-URI  = scheme ":" hier-part [ "?" query ]
+
+   relative-ref  = relative-part [ "?" query ] [ "#" fragment ]
+
+   relative-part = "//" authority path-abempty
+                 / path-absolute
+                 / path-noscheme
+                 / path-empty
+
+   scheme        = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
+
+   authority     = [ userinfo "@" ] host [ ":" port ]
+   userinfo      = *( unreserved / pct-encoded / sub-delims / ":" )
+   host          = IP-literal / IPv4address / reg-name
+   port          = *DIGIT
+
+   IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"
+
+   IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
+
+   IPv6address   =                            6( h16 ":" ) ls32
+                 /                       "::" 5( h16 ":" ) ls32
+                 / [               h16 ] "::" 4( h16 ":" ) ls32
+                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
+                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
+                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
+                 / [ *4( h16 ":" ) h16 ] "::"              ls32
+                 / [ *5( h16 ":" ) h16 ] "::"              h16
+                 / [ *6( h16 ":" ) h16 ] "::"
+
+   h16           = 1*4HEXDIG
+   ls32          = ( h16 ":" h16 ) / IPv4address
+   IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 49]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   dec-octet     = DIGIT                 ; 0-9
+                 / %x31-39 DIGIT         ; 10-99
+                 / "1" 2DIGIT            ; 100-199
+                 / "2" %x30-34 DIGIT     ; 200-249
+                 / "25" %x30-35          ; 250-255
+
+   reg-name      = *( unreserved / pct-encoded / sub-delims )
+
+   path          = path-abempty    ; begins with "/" or is empty
+                 / path-absolute   ; begins with "/" but not "//"
+                 / path-noscheme   ; begins with a non-colon segment
+                 / path-rootless   ; begins with a segment
+                 / path-empty      ; zero characters
+
+   path-abempty  = *( "/" segment )
+   path-absolute = "/" [ segment-nz *( "/" segment ) ]
+   path-noscheme = segment-nz-nc *( "/" segment )
+   path-rootless = segment-nz *( "/" segment )
+   path-empty    = 0<pchar>
+
+   segment       = *pchar
+   segment-nz    = 1*pchar
+   segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
+                 ; non-zero-length segment without any colon ":"
+
+   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
+
+   query         = *( pchar / "/" / "?" )
+
+   fragment      = *( pchar / "/" / "?" )
+
+   pct-encoded   = "%" HEXDIG HEXDIG
+
+   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
+   reserved      = gen-delims / sub-delims
+   gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
+   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
+                 / "*" / "+" / "," / ";" / "="
+
+Appendix B.  Parsing a URI Reference with a Regular Expression
+
+   As the "first-match-wins" algorithm is identical to the "greedy"
+   disambiguation method used by POSIX regular expressions, it is
+   natural and commonplace to use a regular expression for parsing the
+   potential five components of a URI reference.
+
+   The following line is the regular expression for breaking-down a
+   well-formed URI reference into its components.
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 50]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
+       12            3  4          5       6  7        8 9
+
+   The numbers in the second line above are only to assist readability;
+   they indicate the reference points for each subexpression (i.e., each
+   paired parenthesis).  We refer to the value matched for subexpression
+   <n> as $<n>.  For example, matching the above expression to
+
+      http://www.ics.uci.edu/pub/ietf/uri/#Related
+
+   results in the following subexpression matches:
+
+      $1 = http:
+      $2 = http
+      $3 = //www.ics.uci.edu
+      $4 = www.ics.uci.edu
+      $5 = /pub/ietf/uri/
+      $6 = <undefined>
+      $7 = <undefined>
+      $8 = #Related
+      $9 = Related
+
+   where <undefined> indicates that the component is not present, as is
+   the case for the query component in the above example.  Therefore, we
+   can determine the value of the five components as
+
+      scheme    = $2
+      authority = $4
+      path      = $5
+      query     = $7
+      fragment  = $9
+
+   Going in the opposite direction, we can recreate a URI reference from
+   its components by using the algorithm of Section 5.3.
+
+Appendix C.  Delimiting a URI in Context
+
+   URIs are often transmitted through formats that do not provide a
+   clear context for their interpretation.  For example, there are many
+   occasions when a URI is included in plain text; examples include text
+   sent in email, USENET news, and on printed paper.  In such cases, it
+   is important to be able to delimit the URI from the rest of the text,
+   and in particular from punctuation marks that might be mistaken for
+   part of the URI.
+
+   In practice, URIs are delimited in a variety of ways, but usually
+   within double-quotes "http://example.com/", angle brackets
+   <http://example.com/>, or just by using whitespace:
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 51]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      http://example.com/
+
+   These wrappers do not form part of the URI.
+
+   In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may
+   have to be added to break a long URI across lines.  The whitespace
+   should be ignored when the URI is extracted.
+
+   No whitespace should be introduced after a hyphen ("-") character.
+   Because some typesetters and printers may (erroneously) introduce a
+   hyphen at the end of line when breaking it, the interpreter of a URI
+   containing a line break immediately after a hyphen should ignore all
+   whitespace around the line break and should be aware that the hyphen
+   may or may not actually be part of the URI.
+
+   Using <> angle brackets around each URI is especially recommended as
+   a delimiting style for a reference that contains embedded whitespace.
+
+   The prefix "URL:" (with or without a trailing space) was formerly
+   recommended as a way to help distinguish a URI from other bracketed
+   designators, though it is not commonly used in practice and is no
+   longer recommended.
+
+   For robustness, software that accepts user-typed URI should attempt
+   to recognize and strip both delimiters and embedded whitespace.
+
+   For example, the text
+
+      Yes, Jim, I found it under "http://www.w3.org/Addressing/",
+      but you can probably pick it up from <ftp://foo.example.
+      com/rfc/>.  Note the warning in <http://www.ics.uci.edu/pub/
+      ietf/uri/historical.html#WARNING>.
+
+   contains the URI references
+
+      http://www.w3.org/Addressing/
+      ftp://foo.example.com/rfc/
+      http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 52]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+Appendix D.  Changes from RFC 2396
+
+D.1.  Additions
+
+   An ABNF rule for URI has been introduced to correspond to one common
+   usage of the term: an absolute URI with optional fragment.
+
+   IPv6 (and later) literals have been added to the list of possible
+   identifiers for the host portion of an authority component, as
+   described by [RFC2732], with the addition of "[" and "]" to the
+   reserved set and a version flag to anticipate future versions of IP
+   literals.  Square brackets are now specified as reserved within the
+   authority component and are not allowed outside their use as
+   delimiters for an IP literal within host.  In order to make this
+   change without changing the technical definition of the path, query,
+   and fragment components, those rules were redefined to directly
+   specify the characters allowed.
+
+   As [RFC2732] defers to [RFC3513] for definition of an IPv6 literal
+   address, which, unfortunately, lacks an ABNF description of
+   IPv6address, we created a new ABNF rule for IPv6address that matches
+   the text representations defined by Section 2.2 of [RFC3513].
+   Likewise, the definition of IPv4address has been improved in order to
+   limit each decimal octet to the range 0-255.
+
+   Section 6, on URI normalization and comparison, has been completely
+   rewritten and extended by using input from Tim Bray and discussion
+   within the W3C Technical Architecture Group.
+
+D.2.  Modifications
+
+   The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of
+   [RFC2234].  This change required all rule names that formerly
+   included underscore characters to be renamed with a dash instead.  In
+   addition, a number of syntax rules have been eliminated or simplified
+   to make the overall grammar more comprehensible.  Specifications that
+   refer to the obsolete grammar rules may be understood by replacing
+   those rules according to the following table:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 53]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   +----------------+--------------------------------------------------+
+   | obsolete rule  | translation                                      |
+   +----------------+--------------------------------------------------+
+   | absoluteURI    | absolute-URI                                     |
+   | relativeURI    | relative-part [ "?" query ]                      |
+   | hier_part      | ( "//" authority path-abempty /                  |
+   |                | path-absolute ) [ "?" query ]                    |
+   |                |                                                  |
+   | opaque_part    | path-rootless [ "?" query ]                      |
+   | net_path       | "//" authority path-abempty                      |
+   | abs_path       | path-absolute                                    |
+   | rel_path       | path-rootless                                    |
+   | rel_segment    | segment-nz-nc                                    |
+   | reg_name       | reg-name                                         |
+   | server         | authority                                        |
+   | hostport       | host [ ":" port ]                                |
+   | hostname       | reg-name                                         |
+   | path_segments  | path-abempty                                     |
+   | param          | *<pchar excluding ";">                           |
+   |                |                                                  |
+   | uric           | unreserved / pct-encoded / ";" / "?" / ":"       |
+   |                |  / "@" / "&" / "=" / "+" / "$" / "," / "/"       |
+   |                |                                                  |
+   | uric_no_slash  | unreserved / pct-encoded / ";" / "?" / ":"       |
+   |                |  / "@" / "&" / "=" / "+" / "$" / ","             |
+   |                |                                                  |
+   | mark           | "-" / "_" / "." / "!" / "~" / "*" / "'"          |
+   |                |  / "(" / ")"                                     |
+   |                |                                                  |
+   | escaped        | pct-encoded                                      |
+   | hex            | HEXDIG                                           |
+   | alphanum       | ALPHA / DIGIT                                    |
+   +----------------+--------------------------------------------------+
+
+   Use of the above obsolete rules for the definition of scheme-specific
+   syntax is deprecated.
+
+   Section 2, on characters, has been rewritten to explain what
+   characters are reserved, when they are reserved, and why they are
+   reserved, even when they are not used as delimiters by the generic
+   syntax.  The mark characters that are typically unsafe to decode,
+   including the exclamation mark ("!"), asterisk ("*"), single-quote
+   ("'"), and open and close parentheses ("(" and ")"), have been moved
+   to the reserved set in order to clarify the distinction between
+   reserved and unreserved and, hopefully, to answer the most common
+   question of scheme designers.  Likewise, the section on
+   percent-encoded characters has been rewritten, and URI normalizers
+   are now given license to decode any percent-encoded octets
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 54]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   corresponding to unreserved characters.  In general, the terms
+   "escaped" and "unescaped" have been replaced with "percent-encoded"
+   and "decoded", respectively, to reduce confusion with other forms of
+   escape mechanisms.
+
+   The ABNF for URI and URI-reference has been redesigned to make them
+   more friendly to LALR parsers and to reduce complexity.  As a result,
+   the layout form of syntax description has been removed, along with
+   the uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path,
+   path_segments, rel_segment, and mark rules.  All references to
+   "opaque" URIs have been replaced with a better description of how the
+   path component may be opaque to hierarchy.  The relativeURI rule has
+   been replaced with relative-ref to avoid unnecessary confusion over
+   whether they are a subset of URI.  The ambiguity regarding the
+   parsing of URI-reference as a URI or a relative-ref with a colon in
+   the first segment has been eliminated through the use of five
+   separate path matching rules.
+
+   The fragment identifier has been moved back into the section on
+   generic syntax components and within the URI and relative-ref rules,
+   though it remains excluded from absolute-URI.  The number sign ("#")
+   character has been moved back to the reserved set as a result of
+   reintegrating the fragment syntax.
+
+   The ABNF has been corrected to allow the path component to be empty.
+   This also allows an absolute-URI to consist of nothing after the
+   "scheme:", as is present in practice with the "dav:" namespace
+   [RFC2518] and with the "about:" scheme used internally by many WWW
+   browser implementations.  The ambiguity regarding the boundary
+   between authority and path has been eliminated through the use of
+   five separate path matching rules.
+
+   Registry-based naming authorities that use the generic syntax are now
+   defined within the host rule.  This change allows current
+   implementations, where whatever name provided is simply fed to the
+   local name resolution mechanism, to be consistent with the
+   specification.  It also removes the need to re-specify DNS name
+   formats here.  Furthermore, it allows the host component to contain
+   percent-encoded octets, which is necessary to enable
+   internationalized domain names to be provided in URIs, processed in
+   their native character encodings at the application layers above URI
+   processing, and passed to an IDNA library as a registered name in the
+   UTF-8 character encoding.  The server, hostport, hostname,
+   domainlabel, toplabel, and alphanum rules have been removed.
+
+   The resolving relative references algorithm of [RFC2396] has been
+   rewritten with pseudocode for this revision to improve clarity and
+   fix the following issues:
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 55]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   o  [RFC2396] section 5.2, step 6a, failed to account for a base URI
+      with no path.
+
+   o  Restored the behavior of [RFC1808] where, if the reference
+      contains an empty path and a defined query component, the target
+      URI inherits the base URI's path component.
+
+   o  The determination of whether a URI reference is a same-document
+      reference has been decoupled from the URI parser, simplifying the
+      URI processing interface within applications in a way consistent
+      with the internal architecture of deployed URI processing
+      implementations.  The determination is now based on comparison to
+      the base URI after transforming a reference to absolute form,
+      rather than on the format of the reference itself.  This change
+      may result in more references being considered "same-document"
+      under this specification than there would be under the rules given
+      in RFC 2396, especially when normalization is used to reduce
+      aliases.  However, it does not change the status of existing
+      same-document references.
+
+   o  Separated the path merge routine into two routines: merge, for
+      describing combination of the base URI path with a relative-path
+      reference, and remove_dot_segments, for describing how to remove
+      the special "." and ".." segments from a composed path.  The
+      remove_dot_segments algorithm is now applied to all URI reference
+      paths in order to match common implementations and to improve the
+      normalization of URIs in practice.  This change only impacts the
+      parsing of abnormal references and same-scheme references wherein
+      the base URI has a non-hierarchical path.
+
+Index
+
+   A
+      ABNF  11
+      absolute  27
+      absolute-path  26
+      absolute-URI  27
+      access  9
+      authority  17, 18
+
+   B
+      base URI  28
+
+   C
+      character encoding  4
+      character  4
+      characters  8, 11
+      coded character set  4
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 56]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+   D
+      dec-octet  20
+      dereference  9
+      dot-segments  23
+
+   F
+      fragment  16, 24
+
+   G
+      gen-delims  13
+      generic syntax  6
+
+   H
+      h16  20
+      hier-part  16
+      hierarchical  10
+      host  18
+
+   I
+      identifier  5
+      IP-literal  19
+      IPv4  20
+      IPv4address  19, 20
+      IPv6  19
+      IPv6address  19, 20
+      IPvFuture  19
+
+   L
+      locator  7
+      ls32  20
+
+   M
+      merge  32
+
+   N
+      name  7
+      network-path  26
+
+   P
+      path  16, 22, 26
+         path-abempty  22
+         path-absolute  22
+         path-empty  22
+         path-noscheme  22
+         path-rootless  22
+      path-abempty  16, 22, 26
+      path-absolute  16, 22, 26
+      path-empty  16, 22, 26
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 57]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+      path-rootless  16, 22
+      pchar  23
+      pct-encoded  12
+      percent-encoding  12
+      port  22
+
+   Q
+      query  16, 23
+
+   R
+      reg-name  21
+      registered name  20
+      relative  10, 28
+      relative-path  26
+      relative-ref  26
+      remove_dot_segments  33
+      representation  9
+      reserved  12
+      resolution  9, 28
+      resource  5
+      retrieval  9
+
+   S
+      same-document  27
+      sameness  9
+      scheme  16, 17
+      segment  22, 23
+         segment-nz  23
+         segment-nz-nc  23
+      sub-delims  13
+      suffix  27
+
+   T
+      transcription  8
+
+   U
+      uniform  4
+      unreserved  13
+      URI grammar
+         absolute-URI  27
+         ALPHA  11
+         authority  18
+         CR  11
+         dec-octet  20
+         DIGIT  11
+         DQUOTE  11
+         fragment  24
+         gen-delims  13
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 58]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+         h16  20
+         HEXDIG  11
+         hier-part  16
+         host  19
+         IP-literal  19
+         IPv4address  20
+         IPv6address  20
+         IPvFuture  19
+         LF  11
+         ls32  20
+         OCTET  11
+         path  22
+         path-abempty  22
+         path-absolute  22
+         path-empty  22
+         path-noscheme  22
+         path-rootless  22
+         pchar  23
+         pct-encoded  12
+         port  22
+         query  24
+         reg-name  21
+         relative-ref  26
+         reserved  13
+         scheme  17
+         segment  23
+         segment-nz  23
+         segment-nz-nc  23
+         SP  11
+         sub-delims  13
+         unreserved  13
+         URI  16
+         URI-reference  25
+         userinfo  18
+      URI  16
+      URI-reference  25
+      URL  7
+      URN  7
+      userinfo  18
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 59]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+Authors' Addresses
+
+   Tim Berners-Lee
+   World Wide Web Consortium
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   USA
+
+   Phone: +1-617-253-5702
+   Fax:   +1-617-258-5999
+   EMail: timbl@w3.org
+   URI:   http://www.w3.org/People/Berners-Lee/
+
+
+   Roy T. Fielding
+   Day Software
+   5251 California Ave., Suite 110
+   Irvine, CA  92617
+   USA
+
+   Phone: +1-949-679-2960
+   Fax:   +1-949-679-2972
+   EMail: fielding@gbiv.com
+   URI:   http://roy.gbiv.com/
+
+
+   Larry Masinter
+   Adobe Systems Incorporated
+   345 Park Ave
+   San Jose, CA  95110
+   USA
+
+   Phone: +1-408-536-3024
+   EMail: LMM@acm.org
+   URI:   http://larry.masinter.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 60]
+
+RFC 3986                   URI Generic Syntax               January 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Berners-Lee, et al.         Standards Track                    [Page 61]
+
diff --git a/standards/rfc3995.txt b/standards/rfc3995.txt
new file mode 100644
index 000000000..9a8013b89
--- /dev/null
+++ b/standards/rfc3995.txt
@@ -0,0 +1,5323 @@
+
+
+
+
+
+
+Network Working Group                                         R. Herriot
+Request for Comments: 3995                     Global Workflow Solutions
+Category: Standards Track                                    T. Hastings
+Updates: 2911, 2910                                    Xerox Corporation
+                                                              March 2005
+
+
+                   Internet Printing Protocol (IPP):
+                 Event Notifications and Subscriptions
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes an OPTIONAL extension to the Internet
+   Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).
+   This extension allows a client to subscribe to printing related
+   Events.  Subscriptions are modeled as Subscription Objects.  The
+   Subscription Object specifies that when one of the specified Events
+   occurs, the Printer delivers an asynchronous Event Notification to
+   the specified Notification Recipient via the specified Push or Pull
+   Delivery Method (i.e., protocol).
+
+   A client associates Subscription Objects with a particular Job by
+   performing the Create-Job-Subscriptions operation or by submitting a
+   Job with subscription information.  A client associates Subscription
+   Objects with the Printer by performing a Create-Printer-Subscriptions
+   operation.  Four other operations are defined for Subscription
+   Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-
+   Subscription, and Cancel-Subscription.
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 1]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       1.1.  Notification Overview. . . . . . . . . . . . . . . . . .  5
+   2.  Models for Notification. . . . . . . . . . . . . . . . . . . .  8
+       2.1.  Model for Simple Notification (Normative). . . . . . . .  8
+       2.2.  Additional Models for Notification (Informative) . . . .  9
+   3.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  9
+       3.1.  Conformance Terminology. . . . . . . . . . . . . . . . .  9
+       3.2.  Other Terminology. . . . . . . . . . . . . . . . . . . . 10
+   4.  Object Relationships . . . . . . . . . . . . . . . . . . . . . 12
+       4.1.  Printer and Per-Printer Subscription Objects . . . . . . 13
+       4.2.  Printer, Job and Per-Job Subscription Objects. . . . . . 13
+   5.  Subscription Object. . . . . . . . . . . . . . . . . . . . . . 13
+       5.1.  Rules for Support of Subscription Template Attributes. . 14
+       5.2.  Rules for Processing Subscription Template Attributes. . 15
+       5.3.  Subscription Template Attributes . . . . . . . . . . . . 18
+             5.3.1.  notify-recipient-uri (uri) . . . . . . . . . . . 20
+             5.3.2.  notify-pull-method (type2 keyword) . . . . . . . 21
+             5.3.3.  notify-events (1setOf type2 keyword) . . . . . . 22
+             5.3.4.  notify-attributes (1setOf type2 keyword) . . . . 29
+             5.3.5.  notify-user-data (octetString(63)) . . . . . . . 30
+             5.3.6.  notify-charset (charset) . . . . . . . . . . . . 31
+             5.3.7.  notify-natural-language (naturalLanguage). . . . 31
+             5.3.8.  notify-lease-duration (integer(0:67108863)). . . 32
+             5.3.9.  notify-time-interval (integer(0:MAX)). . . . . . 33
+       5.4.  Subscription Description Attributes. . . . . . . . . . . 34
+             5.4.1.  notify-subscription-id  (integer (1:MAX)). . . . 35
+             5.4.2.  notify-sequence-number (integer (0:MAX)) . . . . 35
+             5.4.3.  notify-lease-expiration-time (integer(0:MAX)). . 36
+             5.4.4.  notify-printer-up-time (integer(1:MAX)). . . . . 37
+             5.4.5.  notify-printer-uri (uri) . . . . . . . . . . . . 37
+             5.4.6.  notify-job-id (integer(1:MAX)) . . . . . . . . . 37
+             5.4.7.  notify-subscriber-user-name (name(MAX)). . . . . 38
+   6.  Printer Description Attributes Related to Notification . . . . 38
+       6.1.  printer-state-change-time (integer(1:MAX)) . . . . . . . 39
+       6.2.  printer-state-change-date-time (dateTime). . . . . . . . 39
+   7.  New Values for Existing Printer Description Attributes . . . . 39
+       7.1.  operations-supported (1setOf type2 enum) . . . . . . . . 40
+   8.  Attributes Only in Event Notifications . . . . . . . . . . . . 40
+       8.1.  notify-subscribed-event (type2 keyword). . . . . . . . . 40
+       8.2.  notify-text (text(MAX)). . . . . . . . . . . . . . . . . 41
+   9.  Event Notification Content . . . . . . . . . . . . . . . . . . 41
+       9.1.  Content of Machine Consumable Event Notifications. . . . 44
+             9.1.1.  Event Notification Content Common to All Events. 44
+             9.1.2.  Additional Event Notification Content for Job
+                     Events . . . . . . . . . . . . . . . . . . . . . 45
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 2]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+             9.1.3.  Additional Event Notification Content for
+                     Printer Events . . . . . . . . . . . . . . . . . 46
+       9.2.  Content of Human Consumable Event Notification . . . . . 46
+             9.2.1.  Event Notification Content Common to All Events. 47
+             9.2.2.  Additional Event Notification Content for Job
+                     Events . . . . . . . . . . . . . . . . . . . . . 49
+             9.2.3.  Additional Event Notification Content for
+                     Printer Events . . . . . . . . . . . . . . . . . 49
+   10. Delivery Methods . . . . . . . . . . . . . . . . . . . . . . . 50
+   11. Operations for Notification. . . . . . . . . . . . . . . . . . 52
+       11.1. Subscription Creation Operations . . . . . . . . . . . . 52
+             11.1.1. Create-Job-Subscriptions Operation . . . . . . . 52
+             11.1.2. Create-Printer-Subscriptions operation . . . . . 55
+             11.1.3. Job Creation Operations - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 56
+       11.2 Other Operations. . . . . . . . . . . . . . . . . . . . . 58
+             11.2.1. Restart-Job Operation - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 58
+             11.2.2. Validate-Job Operation - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 59
+             11.2.3. Get-Printer-Attributes - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 59
+             11.2.4. Get-Subscription-Attributes operation. . . . . . 60
+             11.2.5. Get-Subscriptions operation. . . . . . . . . . . 63
+             11.2.6. Renew-Subscription operation . . . . . . . . . . 66
+             11.2.7. Cancel-Subscription operation. . . . . . . . . . 68
+   12. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 70
+       12.1. successful-ok-ignored-subscriptions (0x0003) . . . . . . 70
+       12.2. client-error-ignored-all-subscriptions (0x0414). . . . . 71
+   13. Status Codes in Subscription Attributes Groups . . . . . . . . 71
+       13.1. client-error-uri-scheme-not-supported (0x040C) . . . . . 71
+       13.2. client-error-attributes-or-values-not-supported (0x040B) 71
+       13.3. client-error-too-many-subscriptions (0x0415) . . . . . . 72
+       13.4. successful-ok-too-many-events (0x0005) . . . . . . . . . 72
+       13.5. successful-ok-ignored-or-substituted-attributes (0x0001) 72
+   14. Encodings of Additional Attribute Tags . . . . . . . . . . . . 72
+   15. Conformance Requirements . . . . . . . . . . . . . . . . . . . 72
+       15.1. Conformance requirements for clients . . . . . . . . . . 73
+       15.2. Conformance requirements for Printers. . . . . . . . . . 73
+   16. Model for Notification with Cascading Printers (Informative) . 74
+   17. Distributed Model for Notification (Informative) . . . . . . . 75
+   18. Extended Notification Recipient (Informative). . . . . . . . . 76
+   19. Object Model for Notification (Normative). . . . . . . . . . . 77
+       19.1. Object relationships . . . . . . . . . . . . . . . . . . 78
+       19.2. Printer Object and Per-Printer Subscription Objects. . . 79
+       19.3. Job Object and Per-Job Subscription Objects. . . . . . . 79
+   20. Per-Job versus Per-Printer Subscription Objects (Normative). . 79
+   21. Normative References . . . . . . . . . . . . . . . . . . . . . 80
+
+
+
+Herriot & Hastings          Standards Track                     [Page 3]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   22. Informative References . . . . . . . . . . . . . . . . . . . . 80
+   23. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 81
+       23.1. Attribute Registrations. . . . . . . . . . . . . . . . . 82
+       23.2. Additional Enum Attribute Value Registrations within
+             the IPP registry . . . . . . . . . . . . . . . . . . . . 83
+       23.3. Operation Registrations. . . . . . . . . . . . . . . . . 83
+       23.4. Status code Registrations. . . . . . . . . . . . . . . . 83
+       23.5. Attribute Group tag Registrations. . . . . . . . . . . . 84
+       23.6. Registration of Events . . . . . . . . . . . . . . . . . 84
+       23.7. Registration of Event Notification Delivery Methods. . . 85
+             23.7.1. Requirements for Registration of Event
+                     Notification Delivery Methods. . . . . . . . . . 85
+             23.7.2. Registration Procedure . . . . . . . . . . . . . 86
+             23.7.3. Delivery Method Document Registrations . . . . . 87
+             23.7.4. Registration Template. . . . . . . . . . . . . . 88
+   24. Internationalization Considerations. . . . . . . . . . . . . . 89
+   25. Security Considerations. . . . . . . . . . . . . . . . . . . . 89
+       25.1. Client access rights . . . . . . . . . . . . . . . . . . 89
+       25.2. Printer security threats . . . . . . . . . . . . . . . . 91
+       25.3. Notification Recipient security threats. . . . . . . . . 91
+   26. Description of the base IPP documents (Informative). . . . . . 92
+   27. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 93
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 95
+
+Tables
+
+   Table 1  - Subscription Template Attributes. . . . . . . . . . . . 20
+   Table 2  - Subscription Description Attributes . . . . . . . . . . 35
+   Table 3  - Printer Description Attributes Associated with
+              Notification. . . . . . . . . . . . . . . . . . . . . . 39
+   Table 4  - Operation-id assignments. . . . . . . . . . . . . . . . 40
+   Table 5  - Attributes in Event Notification Content. . . . . . . . 45
+   Table 6  - Additional Event Notification Content for Job Events. . 46
+   Table 7  - Combinations of Events and Subscribed Events for
+              "job-impressions-completed" . . . . . . . . . . . . . . 46
+   Table 8  - Additional Event Notification Content for Printer
+              Events. . . . . . . . . . . . . . . . . . . . . . . . . 46
+   Table 9  - Printer Name in Event Notification Content. . . . . . . 48
+   Table 10 - Event Name in Event Notification Content. . . . . . . . 48
+   Table 11 - Event Time in Event Notification Content. . . . . . . . 48
+   Table 12 - Job Name in Event Notification Content. . . . . . . . . 49
+   Table 13 - Job State in Event Notification Content . . . . . . . . 49
+   Table 14 - Printer State in Event Notification Content . . . . . . 50
+   Table 15 - Information about the Delivery Method . . . . . . . . . 51
+   Table 16 - Printer Conformance Requirements for Operations . . . . 74
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 4]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+Figures
+
+   Figure 1 - Model for Notification. . . . . . . . . . . . . . . . .  9
+   Figure 2 - Model for Notification with Cascading Printers. . . . . 75
+   Figure 3 - Opaque Use of a Notification Server Transparent to the
+              Client. . . . . . . . . . . . . . . . . . . . . . . . . 76
+   Figure 4 - Use of an Extended Notification Recipient transparent
+              to the Printer. . . . . . . . . . . . . . . . . . . . . 77
+   Figure 5 - Object Model for Notification . . . . . . . . . . . . . 78
+
+1.  Introduction
+
+   This IPP notification specification is an OPTIONAL extension to
+   Internet Printing Protocol/1.1: Model and Semantics [RFC2911,
+   RFC2910].  See Appendix 29 for a description of the base IPP
+   documents.  This document in combination with the following documents
+   is intended to meet the most important notification requirements
+   described in [RFC3997]:
+
+      Internet Printing Protocol (IPP):  "Job Progress Attributes"
+      [RFC3381]
+
+      Internet Printing Protocol (IPP):  "The 'ippget' Delivery Method
+      for Event Notifications" [RFC3996]
+
+   This specification REQUIRES that clients and Printers support the
+   'ippget' Pull Delivery Method [RFC3996].  Conforming client and
+   Printer implementations MAY support additional Push or Pull Delivery
+   Methods as well.  Note: this document does not define any Delivery
+   Methods itself, but it does define the rules for conformance for
+   Delivery Method Documents and their registration with IANA (see
+   section 23.7.3).
+
+   Refer to the Table of Contents for the layout of this document.
+
+1.1.  Notification Overview
+
+   This document defines operations that a client can perform in order
+   to create Subscription Objects in a Printer and carry out other
+   operations on them.  A Subscription Object represents a Subscription
+   abstraction.  The Subscription Object specifies that when one of the
+   specified Events occurs, the Printer delivers an asynchronous Event
+   Notification to the specified Notification Recipient via the
+   specified Delivery Method (i.e., protocol).
+
+   When a client (called a Subscribing Client) performs an operation
+   that creates a Subscription Object, the operation contains one or
+   more Subscription Template Attributes Groups.  Each such group holds
+
+
+
+Herriot & Hastings          Standards Track                     [Page 5]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   information used by the Printer to initialize a newly created
+   Subscription Object.  The Printer creates one Subscription Object for
+   each Subscription Template Attributes Group in the operation.  This
+   group is like the Job Template Attributes group defined in [RFC2911].
+   The following is an example of the information included in a
+   Subscription Template Attributes Group (see section 5 for details on
+   the Subscription Object attributes):
+
+   1. The names of Subscribed Events that are of interest to the
+      Notification Recipient.
+
+   2. The address (URL) of one Notification Recipient for a Push
+      Delivery Method or the method for a Pull Delivery Method.
+
+   3. The Delivery Method (i.e., the protocol) which the Printer uses to
+      deliver the Event Notification.
+
+   4. Some opaque data that the Printer delivers to the Notification
+      Recipient in the Event Notification.  For example, the
+      Notification Recipient might use this opaque data as a forwarding
+      address for the Event Notification.
+
+   5. The charset to use in text fields within an Event Notification
+
+   6. The natural language to use in the text fields of the Event
+      Notification
+
+   7. The requested lease time in seconds for the Subscription Object
+
+   An operation that creates a Subscription Object is called a
+   Subscription Creation Operation.  These operations include the
+   following operations (see section 11.1 for further details):
+
+      -  Job Creation operation: When a client performs such an
+         operation (Print-Job, Print-URI, and Create-Job), a client can
+         include zero or more Subscription Template Attributes Groups in
+         the request.  The Printer creates one Subscription Object for
+         each Subscription Template Attributes Group in the request, and
+         the Printer associates each such Subscription Object with the
+         newly created Job.  This document extends these operations'
+         definitions in [RFC2911] by adding Subscription Template
+         Attributes Groups in the request and Subscription Attributes
+         Groups in the response.
+
+      -  Create-Job-Subscriptions operation: A client can include one or
+         more Subscription Template Attributes Groups in the request.
+         The Printer creates one Subscription Object for each
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 6]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         Subscription Template Attributes Group and associates each with
+         the job that is the target of this operation.
+
+      -  Create-Printer-Subscriptions operation: A client can include
+         one or more Subscription Template Attributes Groups in the
+         request.  The Printer creates one Subscription Object for each
+         Subscription Template Attributes Group and associates each with
+         the Printer that is the target of this operation.
+
+   For each of the above operations:
+
+      -  the Printer associates a Subscription Object with the Printer
+         or a specific Job.  When a Subscription Object is associated
+         with a Job Object, it is called a Per-Job Subscription Object.
+         When a Subscription Object is associated with a Printer Object,
+         it is called a Per-Printer Subscription Object.
+
+      -  the response contains one Subscription Attributes Group for
+         each Subscription Template Attributes Group in the request and
+         in the same order.  When the Printer successfully creates a
+         Subscription Object, its corresponding Subscription Attributes
+         Group contains the "notify-subscription-id" attribute.  This
+         attribute uniquely identifies the Subscription Object and is
+         analogous to a "job-id" for a Job object.  Some operations
+         described below use the "notify-subscription-id" to identify
+         the target Subscription Object.
+
+   This document defines the following additional operations (see
+   section 11.2 for further details):
+
+   -  Restart-Job operation: When a client performs the Restart-Job
+      operation [RFC2911], the Printer re-uses the same Job and its
+      Subscription Objects.
+
+   -  Validate-Job operation: When a client performs this operation, a
+      client can include zero or more Subscription Template Attributes
+      Groups in the request.  The Printer determines if it could create
+      one Subscription Object for each Subscription Template Attributes
+      Group in the request.  This document extends this operation's
+      definition in [RFC2911] by adding Subscription Template Attributes
+      Groups in the request and Subscription Attributes Groups in the
+      response.
+
+   -  Get-Subscription-Attributes operation: This operation allows a
+      client to obtain the specified attributes of a target Subscription
+      Object.
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 7]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   -  Get-Subscriptions operation: This operation allows a client to
+      obtain the specified attributes of all Subscription Objects
+      associated with the Printer or a specified Job.
+
+   -  Renew-Subscription operation: This operation renews the lease on
+      the target Per-Printer Subscription Object before it expires.  A
+      newly created Per-Printer Subscription Object receives an initial
+      lease.  It is the duty of the client to use this operation
+      frequently enough to preserve a Per-Printer Subscription Object.
+      The Printer deletes a Per-Printer Subscription Object when its
+      lease expires.  A Per-Job Subscription Object last exactly as long
+      as its associated Job Object and thus doesn't have a lease.
+
+   -  Cancel-Subscription operation: This operation (1) cancels the
+      lease on the specified Per-Printer Subscription Object and thereby
+      deletes the Per-Printer Subscription Object or (2) deletes the
+      Per-Job Subscription Object.
+
+   When an Event occurs, the Printer finds all Subscription Objects
+   listening for the Event (see section 9 for details on finding such
+   Subscription Objects).  For each such Subscription Object, the
+   Printer:
+
+   a) generates an Event Notification with information specified in
+      section 9, AND
+
+   b) either:
+
+      i)  If the Delivery Method is a Push Delivery Method as indicated
+          by the presence of the Subscription Object's "notify-
+          recipient-uri" attribute, delivers the Event Notification
+          using the Delivery Method and target address identified in the
+          Subscription Object's "notify-recipient-uri" attribute, OR
+
+      ii) If the Delivery Method is a Pull Delivery Method as indicated
+          by the presence of the Subscription Object's "notify-pull-
+          method" attribute, saves Event Notification for a time period
+          called the Event Life defined by the Delivery Method, i.e.,
+          the Notification Recipient is expected to fetch the Event
+          Notifications.
+
+2.  Models for Notification
+
+2.1.  Model for Simple Notification (Normative)
+
+   As part of a Subscription Creation Operation, an IPP Printer (i.e.,
+   located in an output device or a server) creates one or more
+   Subscription Objects.  In a Subscription Creation Operation, the
+
+
+
+Herriot & Hastings          Standards Track                     [Page 8]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   client specifies the Notification Recipient to which the Printer is
+   to deliver Event Notifications.  A Notification Recipient can be the
+   Subscribing Client or a third party.
+
+   Figure 1 shows the Notification model for a simple Client-Printer
+   relationship.
+
+   embedded printer:
+
+                                        output device or server
+   PDA, desktop, or server                 +---------------+
+        +--------+                         |  ###########  |
+        | client |-----Subscription ---------># Printer #  |
+        +--------+  Creation Operation     |  # Object  #  |
+     +------------+                        |  #####|#####  |
+     |Notification|                        +-------|-------+
+     |Recipient   |<----IPP Event Notifications----+
+     +------------+    (Job and/or Printer Events)
+
+                  Figure 1 - Model for Notification
+
+2.2.  Additional Models for Notification (Informative)
+
+   Additional models have been proposed (see Appendices 16, 17, and 18).
+
+3.  Terminology
+
+   This section defines terminology used throughout this document.
+   Other terminology is defined in [RFC2911].
+
+3.1.  Conformance Terminology
+
+   Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+   NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+   conformance as defined in RFC 2119 [RFC2119] and [RFC2911] section
+   12.1.  If an implementation supports the extension defined in this
+   document, then these terms apply; otherwise, they do not.  These
+   terms define conformance to this document only; they do not affect
+   conformance to other documents, unless explicitly stated otherwise.
+
+   Note: a feature that is OPTIONAL in this document becomes REQUIRED if
+   the Printer implements a Delivery Method that REQUIRES the feature.
+
+   READ-ONLY - an adjective used in an attribute definition to indicate
+   that an IPP Printer MUST NOT allow the attribute's value to be
+   modified.
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 9]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+3.2.  Other Terminology
+
+   This document uses the same terminology as [RFC2911], such as
+   "client", "Printer", "attribute", "attribute value", "keyword",
+   "operation", "request", "response", "administrator", "operator", and
+   "support".  In addition, the following terms are defined for use in
+   this document and the Delivery Method Documents:
+
+   Compound Event Notification - two or more Event Notifications that a
+   Printer delivers together as a single request or response.  The
+   Delivery Method Document specifies whether the Delivery Method
+   supports Compound Event Notifications.
+
+   Delivery Method - the mechanism by which the Printer delivers an
+   Event Notification.
+
+   Delivery Method Document - a document, separate from this document,
+   that defines a Delivery Method.
+
+   Event - some occurrence (either expected or unexpected) within the
+   printing system of a change of state, condition, or configuration of
+   a Job or Printer object.  An Event occurs only at one instant in time
+   and does not span the time the physical Event takes place.  For
+   example, jam-occurred and jam-cleared are two distinct, instantaneous
+   Events, even though the jam may last for a while.
+
+   Event Life - For a Pull Delivery Method, the length of time in
+   seconds after an Event occurs during which the Printer will retain
+   that Event for delivery in an Event Notification.  After the Event
+   Life expires, the Printer will no longer deliver an Event
+   Notification for that Event in such a response.
+
+   Event Notification - the information about an Event that the Printer
+   delivers when an Event occurs.
+
+   Event Notification Attributes Group - The attributes group which is
+   used to deliver an Event Notification in a request (Push Delivery
+   Methods) or a response (Pull Delivery Methods).
+
+   Human Consumable Event Notification - localized text for human
+   consumption only.  There is no standardized format and thus programs
+   should not try to parse this text.
+
+   Job Creation operation - One of the operations that creates a Job
+   object:  Print-Job, Print-URI and Create-Job.  The Restart-Job
+   operation [RFC2911] is not considered a Job Creation operation, since
+   the Printer re-uses the existing Job object.  The Validate-Job
+   operation is not considered a Job Creation operation because no Job
+
+
+
+Herriot & Hastings          Standards Track                    [Page 10]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   object is created.  Therefore, when a statement also applies to
+   either the Restart-Job and/or the Validate-Job operation, they are
+   mentioned explicitly.
+
+   Job Event - an Event caused by some change in a particular job on the
+   Printer, e.g., 'job-completed'.
+
+   Machine Consumable Event Notification - bytes for program
+   consumption.  The bytes are formatted according to the Delivery
+   Method document.
+
+   Notification - when not in the phrases 'Event Notification' and
+   'Notification Recipient' - the concepts of this specification, i.e.,
+   Events, Subscription Objects, and Event Notifications.
+
+   Notification Recipient - the entity to which the Printer delivers an
+   Event Notification.  For Push Delivery Methods, the IPP Printer sends
+   the Notifications to a Notification Recipient.  For Pull Delivery
+   Methods, the Notification Recipient is acting in the role of an IPP
+   client and requests Event Notifications and so the terms "client" and
+
+   "Notification Recipient" are used interchangeably with such Delivery
+   Methods.  For example, see [RFC3996].
+
+   Per-Job Subscription Object - A Subscription Object that is
+   associated with a single Job.  The Create-Job-Subscriptions operation
+   and Job Creation operations create such an object.
+
+   Per-Printer Subscription Object - A Subscription Object that is
+   associated with the Printer as a whole.  The Create-Printer-
+   Subscriptions operation creates such an object.
+
+   Printer Event - an Event caused by some change in the Printer that is
+   not specific to a job, e.g., 'printer-state-changed'.
+
+   Pull Delivery Method - The Printer saves Event Notifications for some
+   event life time and expects the Notification Recipient to request
+   Event Notifications.  The Printer delivers the Event Notifications in
+   a response to such a request.
+
+   Push Delivery Method -The Printer delivers the Event Notification
+   shortly after an Event occurs.
+
+   Subscribed Event - an Event that the Subscribing Client expresses
+   interest in by making it a value of the "notify-events" attribute on
+   a Subscription Object.
+
+   Subscribed Job Event - a Subscribed Event that is a Job Event.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 11]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Subscribed Printer Event - a Subscribed Event that is a Printer
+   Event.
+
+   Subscribing Client - The client that creates the Subscription Object.
+
+   Subscription Attributes Group - The attributes group in a response
+   that contains Subscription Object attributes.
+
+   Subscription Creation Operation - An operation that creates a
+   Subscription Object:  Job Creation operations, Create-Job-
+   Subscriptions operation, Create-Printer-Subscriptions operation.  In
+   the context of a Job Creation operation, a Subscription Creation
+   Operation is the part of the Job Creation operation that creates one
+   or more Subscription objects.  The Restart-Job operation [RFC2911] is
+   not considered a Subscription Creation Operation, since the Printer
+   re-uses the Job's existing Subscription Objects, rather than creating
+   any new Subscription Objects.
+
+   Subscription Creation Request - The request portion of a Subscription
+   Creation Operation.
+
+   Subscription Description Attributes - Subscription Object attributes
+   that a Printer supplies during a Subscription Creation Operation.
+
+   Subscription Object - An object containing a set of attributes that
+   indicate:  the Notification Recipient (for Push Delivery Method
+   only), the Delivery Method, the Subscribed Events that cause the
+   Printer to deliver an Event Notification, and the information to
+   include in an Event Notification.
+
+   Subscription Template Attributes - Subscription Object attributes
+   that a client can supply in a Subscription Creation Operation and
+   associated Printer Object attributes that specify supported and
+   default values for the Subscription Object attributes.
+
+   Subscription Template Attributes Group - The attributes group in a
+   request that contains Subscription Object attributes that are
+   Subscription Template Attributes.
+
+4.  Object Relationships
+
+   This section defines the object relationships between the Printer,
+   Job, and Subscription Objects.  It does not define the
+   implementation.  For an illustration of these relationships, see
+   Appendix 19.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 12]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+4.1.  Printer and Per-Printer Subscription Objects
+
+   1. A Printer object can be associated with zero or more Per-Printer
+      Subscription Objects.
+
+   2. Each Per-Printer Subscription Object is associated with exactly
+      one Printer object.
+
+4.2.  Printer, Job and Per-Job Subscription Objects
+
+   1. A Printer object is associated with zero or more Job objects.
+
+   2. Each Job object is associated with exactly one Printer object.
+
+   3. A Job object is associated with zero or more Per-Job Subscription
+      Objects.
+
+   4. Each Per-Job Subscription Object is associated with exactly one
+      Job object.
+
+5.  Subscription Object
+
+   A Subscribing Client creates a Subscription Object with a
+   Subscription Creation Operation in order to indicate its interest in
+   certain Events.  See section 11 for a description of these
+   operations.  When an Event occurs, the Subscription Object specifies
+   to the Printer where to deliver Event Notifications for Push Delivery
+   Methods only, how to deliver them, and what to include in them.  See
+   section 9 for details on the contents of an Event Notification.
+
+   Using the IPP Job Template attributes as a model (see [RFC2911]
+   section 4.2), the attributes of a Subscription Object are divided
+   into two categories: Subscription Template Attributes and
+   Subscription Description Attributes.
+
+   Subscription Template attributes are, in turn, like the Job Template
+   attributes, divided into
+
+   1. Subscription Object attributes that a client can supply in a
+      Subscription Creation Request and
+
+   2. their associated Printer Object attributes that specify supported
+      and default values for the Subscription Object attributes
+
+   The remainder of this section specifies general rules for
+   Subscription Template Attributes and describes each attribute in a
+   Subscription Object.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 13]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.1.  Rules for Support of Subscription Template Attributes
+
+   Subscription Template Attributes are fundamental to the Notification
+   model described in this specification.  The client supplies these
+   attributes in Subscription Creation Operations and the Printer uses
+   these attributes to populate a newly created Subscription Object.
+
+   Subscription Objects attributes that are Subscription Template
+   Attributes conform to the following rules:
+
+   1. Each attribute's name starts with the prefix string "notify-" and
+      this document calls such attributes "notify-xxx".
+
+   2. For each "notify-xxx" Subscription Object attribute defined in
+      column 1 of Table 1 in section 5.3, Table 1 specifies
+      corresponding Printer attributes: "notify-xxx-default", "notify-
+      xxx-supported", "yyy-supported" and "notify-max-xxx-supported"
+      defined in column 2 of Table 1.  Note "xxx" stands for the same
+      string in each case and "yyy" stands for some other string.
+
+   3. If a Printer supports "notify-xxx" in column 1 of Table 1, then
+      the Printer MUST support all associated attributes specified in
+      column 2 of Table 1.  For example, Table 1 shows that if the
+      Printer supports "notify-events", it MUST support "notify-events-
+      default", "notify-events-supported" and "notify-max-events-
+      supported".
+
+   4. If a Printer does not support "notify-xxx" in column 1 of Table 1,
+      then the Printer MUST NOT support any associated "notify-yyy"
+      attributes specified in column 2 of Table 1.  For example, Table 1
+      shows that if the Printer doesn't support "notify-events", it MUST
+      NOT support "notify-events-default", "notify-events-supported" and
+      "notify-max-events-supported".  Note this rule does not apply to
+      attributes whose names do not start with the string "notify-" and
+      are thus defined in another object and used by other attributes.
+
+   5. Most "notify-xxx" attributes have a corresponding "yyy-supported"
+      attribute that specifies the supported values for "notify-xxx".
+      Column 2 of Table 1 specifies the name of each "yyy-supported"
+      attribute.  The naming rules of IPP/1.1 (see [RFC2911]) are used
+      when "yyy-supported" is "notify-xxx-supported".
+
+   6. Some "notify-xxx" attributes have a corresponding "notify-xxx-
+      default" attribute that specifies the value for "notify-xxx" if
+      the client does not supply it.  Column 2 of Table 1 specifies the
+      name of each "notify-xxx-default" attribute.  The naming rules of
+      IPP/1.1 (see [RFC2911]) are used.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 14]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   If a client wishes to present an end user with a list of supported
+   values from which to choose, the client SHOULD query the Printer for
+   its supported value attributes.  The client SHOULD also query the
+   default value attributes.  If the client then limits selectable
+   values to only those values that are supported, the client can
+   guarantee that the values supplied by the client in the create
+   request all fall within the set of supported values at the Printer.
+   When querying the Printer, the client MAY enumerate each attribute by
+   name in the Get-Printer-Attributes Request, or the client MAY just
+   supply the 'subscription-template' group name in order to get the
+   complete set of supported attributes (both supported and default
+   attributes - see section 11.2.3).
+
+5.2.  Rules for Processing Subscription Template Attributes
+
+   This section defines a detailed set of rules that a Printer follows
+   when it processes Subscription Template Attributes in a Subscription
+   Creation Request.  These rules are similar to the rules for
+   processing Operation attributes in [RFC2911].  That is, the Printer
+   may or may not support an attribute and a client may or may not
+   supply the attribute.  Some combinations of these cases are OK.
+   Others return warnings or errors, and perhaps a list of unsupported
+   attributes.
+
+   A Printer MUST implement the following behavior for processing
+   Subscription Template Attributes in a Subscription Creation Request:
+
+   1. If a client supplies a "notify-xxx" attribute from column 1 of
+      Table 1 and the Printer supports it and its value, the Printer
+      MUST populate the attribute on the created Subscription Object.
+
+   2. If a client supplies a "notify-xxx" attribute from column 1 of
+      Table 1 and the Printer doesn't support it or its value, the
+      Printer MUST NOT populate the attribute on the created
+      Subscription Object with it.  The Printer MUST do one of the
+      following:
+
+      a) If the value of the "notify-xxx" attribute is unsupported, the
+         Printer MUST return the attribute with its value in the
+         Subscription Attributes Group of the response.
+
+      b) If "notify-xxx" is an unsupported attribute, the Printer MUST
+         return the attribute in the Subscription Attributes Group of
+         the response with the 'unsupported' out-of-band value.
+
+      Note:  The rules of this step are the same as for Unsupported
+      Attributes [RFC2911] section 3.1.7.  except that the unsupported
+      attributes are returned in the Subscription Attributes Group
+
+
+
+Herriot & Hastings          Standards Track                    [Page 15]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      rather than the Unsupported Attributes Group because Subscription
+      Creation Operations can create more than one Subscription Object).
+
+   3. If a client is REQUIRED to supply a "notify-xxx" attribute from
+      column 1 of Table 1 and the Printer doesn't support the supplied
+      value, the Printer MUST NOT create a Subscription Object.  The
+      rules for Unsupported Attributes in step #2 still apply.
+
+   4. If a client does not supply a "notify-xxx" attribute from column 1
+      of Table 1 and the attribute is REQUIRED for the client to supply,
+      the Printer MUST reject the Subscription Creation Operation
+      (including Job Creation operations) without creating a
+      Subscription Object, and MUST return in the response:
+
+      a) the status code 'client-error-bad-request' AND
+
+      b) no Subscription Attribute Groups.
+
+   5. If a client does not supply a "notify-xxx" attribute from column 1
+      of Table 1 that is OPTIONAL for the client to supply, and column 2
+      of Table 1 either:
+
+      a) specifies a "notify-xxx-default" attribute, the Printer MUST
+         behave as if the client had supplied the "notify-xxx-default"
+         attribute (see step #1) and populate the Subscription object
+         with the value of the "notify-xxx-default" attribute as part of
+         the Subscription Creation operation (unlike Job Template
+         attributes where the Printer does not populate the Job object
+         with defaults - see [RFC2911]) OR
+
+      b) does not specify a "notify-xxx-default" attribute, the Printer
+         MUST populate the "notify-xxx" attribute on the Subscription
+         Object according to the definition of the "notify-xxx"
+         attribute in a section 5.3.  For some attributes, the "notify-
+         xxx" is populated with the value of some other attribute, and
+         for others, the "notify-xxx" is NOT populated on the
+         Subscription object at all.
+
+   6. A Printer MUST create a Subscription Object for each Subscription
+      Template Attributes group in a request unless the Printer:
+
+      a) encounters some attributes in a Subscription Template
+         Attributes Group that require the Printer not to create the
+         Subscription Object OR
+
+      b) would create a Per-Job Subscription Object when it doesn't have
+         space for another Per-Job Subscription Object OR
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 16]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      c) would create a Per-Printer Subscription Object when it doesn't
+         have space for another Per-Printer Subscription Object.
+
+   7. A response MUST contain one Subscription Attributes Group for each
+      Subscription Template Attributes Group in the request (and in the
+      same order) whether the Printer creates a Subscription Object from
+      the Subscription Template Attributes Group or not.  However, the
+      attributes in each Subscription Attributes Group can be in any
+      order.
+
+   8. The Printer MUST populate each Subscription Attributes Group of
+      the response such that each contains:
+
+      a) the "notify-subscription-id" attribute (see section 5.4.1), if
+         and only if the Printer creates a Subscription Object.
+
+      b) the "notify-lease-duration" attribute (see section 5.3.8), if
+         and only if the Printer creates a Per-Printer Subscription
+         Object.  The value of this attribute is the value of the
+         Subscription Object's "notify-lease-duration" attribute.  This
+         value MAY be different from the client-supplied value (see
+         section 5.3.8).  If a client supplies this attribute in the
+         creation of a Per-Job Subscription Object, it MUST appear in
+         this group with the out-of-band value 'unsupported' to indicate
+         that the Printer doesn't support it in this context.
+
+      c) all of the unsupported Subscription Template Attributes from
+         step #2.  Note, they are not returned in the Unsupported
+         Attributes Group in order to separate the unsupported
+         attributes for each Subscription Object.
+
+      d) the "notify-status-code" attribute if the Printer does not
+         create the Subscription Object or if there are unsupported
+         attributes from step #2.  The possible values of the "notify-
+         status-code" attribute are shown below (see section 13 for more
+         details).  The Printer returns the first value in the list
+         below that describes the status.
+
+         'client-error-uri-scheme-not-supported':  the Subscription
+            Object was not created because the scheme of the "notify-
+            recipient-uri" attribute is not supported.  See section 13.1
+            for more details about this status code.  See step #3 in
+            this section for the case that causes this error, and the
+            resulting step #6a) that causes the Printer not to create
+            the Subscription Object.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 17]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         'client-error-attributes-or-values-not-supported':  the
+            Subscription Object was not created because the method of
+            the "notify-pull-method" attribute is not supported.  See
+            section 13.1 for more details about this status code.  See
+            step #3 in this section for the case that causes this error,
+            and the resulting step #6a) that causes the Printer not to
+            create the Subscription Object.
+
+         'client-error-too-many-subscriptions':  the Subscription
+            Object was not created because the Printer has no space for
+            additional Subscription Objects.  The client MAY try again
+            later.  See section 13.3 for more details about this status
+            code.  See steps #6b) and #6c) in this section for the cases
+            that causes this error.
+
+         'successful-ok-too-many-events':  the Subscription Object was
+            created without the "notify-events" values included in this
+            Subscription Attributes Group because the "notify-events"
+            attribute contains too many values.  See section 13.4 for
+            more details about this status code.  See step #2 in this
+            section and section 5.3.3 for the cases that cause this
+            status code.
+
+         'successful-ok-ignored-or-substituted-attributes':  the
+            Subscription Object was created but some supplied
+            Subscription Template Attributes are unsupported.  These
+            unsupported attributes are also in the Subscription
+            Attributes Group.  See section 13.5 for more details about
+            this status code.  See step #2 in this section for the cases
+            that cause this status code.
+
+   9. The Printer MUST validate all Subscription Template Attributes and
+      MUST return all unsupported attributes and values in the
+      corresponding Subscription Attributes Group of the response (see
+      step #2) unless it determines that it could not create additional
+      Subscription Objects because of condition #6b) or condition #6c).
+      Then, the Printer NEED NOT validate these additional Subscription
+      Template Attributes and the client MUST NOT expect to find
+      unsupported attributes from step #2 in such additional
+      Subscription Attribute Groups.
+
+5.3.  Subscription Template Attributes
+
+   This section contains the Subscription Template Attributes defined
+   for the Subscription and Printer objects.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 18]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 1 below shows the Subscription Template Attributes and has two
+   columns:
+
+   -  Attribute in Subscription Object: the name and attribute syntax of
+      each Subscription Object Attribute that is a Subscription Template
+      Attribute
+
+   -  Default and Supported Printer Attributes: the default attribute
+      and supported Printer attributes that are associated with the
+      attribute in column 1.
+
+   The "notify-recipient-uri" attribute is for use with Push Delivery
+   Methods.  The "notify-pull-method" attribute is for use with Pull
+   Delivery Methods.
+
+   For Push Delivery Methods, a Printer MUST support all attributes in
+   Table 1 below except for "notify-pull-method" and "notify-attributes"
+   (and "notify-pull-method-supported" and "notify-attributes-
+   supported").  For Pull Delivery Methods, a Printer MUST support all
+   attributes in Table 1 below except for "notify-recipient-uri" and
+   "notify-attributes" (and "notify-schemes-supported" and "notify-
+   attributes-supported").  If a Printer supports both Push and Pull
+   Delivery Methods, then it MUST support both "notify-recipient-uri"
+   and "notify-pull-method" attributes.
+
+   For Pull Delivery Methods, a client MUST supply "notify-recipient-
+   uri" and MAY omit any of the rest of the attributes in column 1 of
+   Table 1 in a Subscription Creation Request.  For Push Delivery
+   Methods, a client MUST supply "notify-pull-method" and MAY omit any
+   of the rest of the attributes in column 1 of Table 1 in a
+   Subscription Creation Request.  A client MUST NOT supply both
+   "notify-recipient-uri" and "notify-pull-method" attributes in the
+   same Subscription Creation Request.
+
+   Note:  The Default and Supported Printer attributes listed in column
+   2 of Table 1 do not have separate sections in this specification
+   defining their semantics.  Instead, the section for the corresponding
+   Subscription Object attribute (column 1 of Table 1) contains the
+   semantics of these Printer attributes.  This approach follows the
+   precedence of the Job Template attributes in section 4.2 of [RFC2911]
+   where the corresponding "xxx-default" and "xxx-supported" Printer
+   attributes are defined in the same section as the "xxx" Job
+   attribute.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 19]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 1 - Subscription Template Attributes
+
+   Attribute in Subscription     Default and Supported Printer
+   Object                        Attributes
+
+   notify-recipient-uri (uri) *  notify-schemes-supported  (1setOf
+                                 uriScheme)
+   notify-pull-method (type2     notify-pull-method-supported (1setOf
+   keyword) **                   type2 keyword)
+   notify-events (1setOf type2   notify-events-default (1setOf type2
+   keyword)                      keyword)
+                                 notify-events-supported (1setOf type2
+                                 keyword)
+                                 notify-max-events-supported
+                                 (integer(2:MAX))
+
+   notify-attributes (1setOf     notify-attributes-supported (1setOf
+   type2 keyword)                type2 keyword)
+   notify-user-data
+   (octetString(63))
+   notify-charset (charset)      charset-supported (1setOf charset)
+   notify-natural-language       generated-natural-language-supported
+   (naturalLanguage)             (1setOf naturalLanguage)
+   notify-lease-duration         notify-lease-duration-default
+   (integer(0:MAX))              (integer(0:67108863))
+                                 notify-lease-duration-supported
+                                 (1setOf (integer(0: 67108863) |
+                                 rangeOfInteger(0:67108863)))
+   notify-time-interval
+   (integer(0:MAX))
+
+   * "notify-recipient-uri" is for Push Delivery Methods only.
+   ** "notify-pull-method" is for Pull Delivery Methods only.
+
+5.3.1.  notify-recipient-uri (uri)
+
+   This attribute's value is a URL, which is a special case of a URI.
+   Its value consists of a scheme and an address.  The address specifies
+   the Notification Recipient and the scheme specifies the Push Delivery
+   Method for each Event Notification associated with this Subscription
+   Object.
+
+   If a Printer supports any Push Delivery Methods, a Printer MUST
+   support this attribute and return the value as supplied by the client
+   (no case conversion or other canonicalization) in any operation
+   response that includes this attribute.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 20]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   For a Push Delivery Method, a client MUST supply this attribute in a
+   Subscription Creation Operation.  Thus there is no need for a default
+   Printer attribute.
+
+   The URI scheme of the value of this attribute on a Subscription
+   object MUST be a value of the "notify-schemes-supported (1setOf
+   uriScheme)" Printer attribute (see section 5.3.1.1).  Note: According
+   to [RFC2396] the ":" terminates the scheme and so is not part of the
+   scheme.  Therefore, values of the "notify-schemes-supported" Printer
+   attribute do not include the ":" character.
+
+   If the client supplies an unsupported scheme in the value of this
+   attribute, then the Printer MUST NOT create the Subscription Object
+   and MUST return the "notify-status-code" attribute with the 'client-
+   error-uri-scheme-not-supported' value in the Subscription Attributes
+   Group in the response.
+
+5.3.1.1.  notify-schemes-supported  (1setOf uriScheme)
+
+   This attribute contains the URI schemes supported in the "notify-
+   recipient-uri" Subscription Template attribute.  See sections 5.1 and
+   5.2 for the behavior of "xxx-supported" Subscription Template Printer
+   attributes.
+
+5.3.2.  notify-pull-method (type2 keyword)
+
+   This attribute's value is a type2 keyword indicating which Pull
+   Delivery Method is to be used.
+
+   Since a Printer MUST support the 'ippget' Pull Delivery Method
+   [RFC3996] (see section 15), a Printer MUST support this attribute and
+   return the value as supplied by the client in any operation response
+   that includes this attribute.
+
+   For a Pull Delivery Method, a client MUST supply this attribute in a
+   Subscription Creation Operation.  Thus there is no need for a default
+   Printer attribute.
+
+   The keyword value of this attribute on a Subscription object MUST be
+   a value of the "notify-pull-method-supported (1setOf type2 keyword)"
+   Printer attribute.
+
+   If the client supplies an unsupported method in the value of this
+   attribute, then the Printer MUST NOT create the Subscription Object
+   and MUST return the "notify-status-code" attribute with the 'client-
+   error-attributes-or-values-not-supported' value in the Subscription
+   Attributes Group in the response.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 21]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.3.2.1.  notify-pull-method-supported (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+5.3.3.  notify-events (1setOf type2 keyword)
+
+   This attribute contains a set of Subscribed Events.  When an Event
+   occurs and it "matches" a value of this attribute, the Printer
+   delivers an Event Notification using information in the Subscription
+   Object.  The details of "matching" are described subsection 5.3.3.5.
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation, the Printer MUST populate this
+   attribute on the Subscription Object with its "notify-events-default"
+   attribute value.
+
+   Each keyword value of this attribute on a Subscription Object MUST be
+   a value of the  "notify-events-supported (1setOf type2 keyword)"
+   Printer attribute.
+
+   The number of values of this attribute MUST NOT exceed the value of
+   the "notify-max-events-supported" attribute.  A Printer MUST support
+   at least 2 values per Subscription Object.  If the number of values
+   supplied by a client in a Subscription Creation Operation exceeds the
+   value of this attribute, the Printer MUST treat extra values as
+   unsupported values and MUST use the value of 'successful-ok-too-
+   many-events' for the "notify-status-code" attribute in the
+   Subscription Attributes Group of the response.
+
+5.3.3.1.  notify-events-default (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-default"
+   Subscription Template Printer attributes.
+
+5.3.3.2.  notify-events-supported (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 22]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.3.3.3.  notify-max-events-supported (integer(2:MAX))
+
+   This attribute specified the maximum number of events that the
+   Printer supports for the "notify-events" Subscription Template
+   attribute.  See sections 5.1 and 5.2 for the behavior of "xxx-
+   supported" Subscription Template Printer attributes.
+
+5.3.3.4.  Standard Values for Subscribed Events
+
+   Each value of this attribute is a keyword and it specifies a
+   Subscribed Event that represents certain changes.  Some keywords
+   represent a subset of changes of another keyword, e.g., 'job-
+   completed' is an Event value which is a sub-value of 'job-state-
+   change'.  See section 5.3.3.5 for the case where this attribute
+   contains both a value and a sub-value.
+
+   The values in this section are divided into three categories: No
+   Events, Job Events and Printer Events.
+
+   A Printer MUST support the Events indicated as "REQUIRED" and MAY
+   support the Events indicated as "OPTIONAL".
+
+5.3.3.4.1.  No Events
+
+   The standard and only keyword value for No Events is:
+
+   'none':  REQUIRED - no Event Notifications for any Events.  As the
+      sole value of "notify-events-supported", this value means that the
+      Printer does not support the delivery of Event Notifications.  As
+      the sole value of "notify-events-default", this value means that a
+      client MUST specify the "notify-events" attribute in order for a
+      Subscription Creation Operation to succeed.  If the Printer
+      receives this value as the sole value of a Subscription Creation
+      Operation, it does not create a Subscription Object.  If a Printer
+      receives this value with other values of a Subscription Creation
+      Operation, the Printer MUST treat this value as an unsupported
+      value.
+
+5.3.3.4.2.  Subscribed Printer Events
+
+   The standard keyword values for Subscribed Printer Events are:
+
+   'printer-state-changed':  REQUIRED - the Printer changed state from
+      any state to any other state.  Specifically, the value of the
+      Printer's "printer-state", "printer-state-reasons" or "printer-
+      is-accepting-jobs" attributes changed.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 23]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      This Subscribed Event value has the following sub-values:
+      'printer-restarted' and 'printer-shutdown'.  A client can listen
+      for any of these sub-values if it doesn't want to listen to all
+      printer-state changes:
+
+         'printer-restarted':  OPTIONAL - when the printer is powered
+            up.
+
+         'printer-shutdown':  OPTIONAL - when the device is being
+            powered down.
+
+         'printer-stopped:  REQUIRED - when the printer stops printing,
+            i.e., the value of the "printer-state" Printer attribute
+            becomes 'stopped'.
+
+   'printer-config-changed':  OPTIONAL - when the configuration of a
+      Printer has changed, i.e., the value of the "printer-message-
+      from-operator" or any "configuration" Printer attribute has
+      changed.  A "configuration" Printer attribute is an attribute
+      which can change value because of some human interaction either
+      direct or indirect, and which is not covered by one of the other
+      Events in this section.  Examples of "configuration" Printer
+      attributes are any of the Job Template attributes, such as "xxx-
+      supported", "xxx-ready" and "xxx-default".  The client has to
+      perform a Get-Printer-Attributes to find out the new values of
+      these changed attributes.  This Event is useful for GUI clients
+      and drivers to update the available printer capabilities to the
+      user.
+
+      This Event value has the following sub-values: 'printer-media-
+      changed' and 'printer-finishings-changed'.  A client can listen
+      for any of these sub-values if it doesn't want to listen to all
+      printer-configuration changes:
+
+         'printer-media-changed':  OPTIONAL - when the media loaded on
+            a printer has been changed, i.e., the "media-ready"
+            attribute has changed.  This Event includes two cases: an
+            input tray that goes empty and an input tray that receives
+            additional media of the same type or of a different type.
+            The client must check the "media-ready" Printer attribute
+            (see [RFC2911] section 4.2.11) separately to find out what
+            changed.
+
+         'printer-finishings-changed':  OPTIONAL - when the finisher on
+            a printer has been changed, i.e., the "finishings-ready"
+            attribute has changed.  This Event includes two cases: a
+            finisher that goes empty and a finisher that is refilled
+            (even if it is not full).  The client must check the
+
+
+
+Herriot & Hastings          Standards Track                    [Page 24]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+            "finishings-ready" Printer attribute separately to find out
+            what changed.
+
+   'printer-queue-order-changed': OPTIONAL - the order of jobs in the
+      Printer's queue has changed, so that an application that is
+      monitoring the queue can perform a Get-Jobs operation to determine
+      the new order.  This Event does not include when a job enters the
+      queue (the 'job-created' Event covers that) and does not include
+      when a job leaves the queue (the 'job-completed' Event covers
+      that).
+
+5.3.3.4.3.  Subscribed Job Events
+
+   The standard keyword values for Subscribed Job Events are:
+
+   'job-state-changed':  REQUIRED - the job has changed from any state
+      to any other state.  Specifically, the Printer delivers this Event
+      whenever the value of the "job-state" attribute or "job-state-
+      reasons" attribute changes.  When a Job is removed from the Job
+      Retention or Job History phases (see [RFC2911] section 4.3.7.1),
+      no Event is generated.
+
+      This Event value has the following sub-values: 'job-created',
+      'job-completed' and 'job-stopped'.  A client can listen for any of
+      these sub-values if it doesn't want to listen to all 'job-state
+      changes'.
+
+      'job-created':  REQUIRED - the Printer has accepted a Job
+         Creation operation, a Restart-Job operation [RFC2911], or any
+         job operation that creates a Job object from an existing Job
+         object.  The Printer populates the job's "time-at-creation"
+         attribute value (see [RFC2911] section 4.3.14.1).  The Printer
+         puts the job in the 'pending', 'pending-held' or 'processing'
+         states.
+
+      'job-completed':  REQUIRED - the job has reached one of the
+         completed states, i.e., the value of the job's "job-state"
+         attribute has changed to: 'completed', 'aborted', or
+         'canceled'.  The Job's "time-at-completed" and "date-time-at-
+         completed" (if supported) attributes are set (see [RFC2911]
+         section 4.3.14).  When a Job completes, a Notification
+         Recipient MAY query the Job using the Get-Job-Attributes
+         operation.  To allow such a query, the Printer retains the Job
+         in the Job Retention and/or the Job History phases (see
+         [RFC2911] section 4.3.7.1) for a suitable amount of time that
+         depends on implementation and the Delivery Methods supported.
+         The Printer also delivers this Event when a Job is removed with
+         the Purge-Job operation (see [RFC2911] section 3.2.9).  In this
+
+
+
+Herriot & Hastings          Standards Track                    [Page 25]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         case, the Event Notification MUST report the 'job-state' as
+         'canceled' and the Job object is no longer present for query.
+
+      'job-stopped:  OPTIONAL - when the job stops printing, i.e.,
+         the value of the "job-state" Job attribute becomes
+         'processing-stopped'.
+
+   'job-config-changed':  OPTIONAL - when the configuration of a job has
+      changed, i.e., the value of the "job-message-from-operator" or any
+      of the "configuration" Job attributes have changed.  A
+      "configuration" Job attribute is an attribute that can change
+      value because of some human interaction either direct or indirect.
+      Examples of "configuration" Job attributes are any of the job
+      template attributes and the "job-name" attribute.  The client
+      performs a Get-Job-Attributes to find out the new values of the
+      changed attributes.  This Event is useful for GUI clients and
+      drivers to update the job information to the user.
+
+   'job-progress': OPTIONAL - when the Printer has completed Printing a
+      sheet.  See the separate [RFC3381] specification for additional
+      attributes that a Printer MAY deliver in an Event Notification
+      caused by this Event.  The "notify-time-interval" attribute
+      affects this Event by causing the Printer NOT to deliver an Event
+      Notification every time a 'job-progress' Events occurs.  See
+      section 5.3.9 for full details.
+
+5.3.3.5.  Rules for Matching of Subscribed Events
+
+   When an Event occurs, the Printer MUST find each Subscription object
+   whose "notify-events" attribute "matches" the Event.  The rules for
+   "matching" of Subscribed Events are described separately for Printer
+   Events and for Job Events.  This section also describes some special
+   cases.
+
+5.3.3.5.1.  Rules for Matching of Printer Events
+
+   Given that the Printer causes Printer Event E to occur, for each
+   Per-Job or Per-Printer Subscription S in the Printer, if E equals a
+   value of this attribute in S or E is a sub-value of a value of this
+   attribute in S, the Printer MUST generate an Event Notification.
+
+   Consider the example.  There are three Subscription Objects each with
+   the Subscribed Printer Event 'printer-state-changed'.  Subscription
+   Object A is a Per-Printer Subscription Object.  Subscription Object B
+   is a Per-Job Subscription Object for Job 1, and Subscription Object C
+   is a Per-Job Subscription Object for Job 2.  When the Printer enters
+   the 'stopped' state, the Printer delivers an Event Notification to
+   the Notification Recipients of Subscription Objects A, B, and C
+
+
+
+Herriot & Hastings          Standards Track                    [Page 26]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   because this is a Printer Event.  Note if Job 1 has already
+   completed, the Printer would not deliver an Event Notification for
+   its Subscription Object, even if Job 1 is retained in the Job
+   Retention and/or the Job History phases (see [RFC2911] section
+   4.3.7.1).
+
+5.3.3.5.2.  Rules for Matching of Job Events
+
+   Given that Job J causes Job Event E to occur:
+
+   1. For each Per-Printer Subscription S in the Printer, if E equals a
+      value of this attribute in S or E is a sub-value of a value of
+      this attribute in S, the Printer MUST generate an Event
+      Notification.
+
+   2. For each Per-Job Subscription S associated with Job J, if E equals
+      a value of this attribute in S or E is a sub-value of a value of
+      this attribute in S, the Printer MUST generate an Event
+      Notification.
+
+   3. For each Per-Job Subscription S that is NOT associated Job J, if E
+      equals a value of this attribute in S or E is a sub-value of a
+      value of this attribute in, the Printer MUST NOT generate an Event
+      Notification from S.
+
+   Consider the example: There are three Subscription Objects listening
+   for the Job Event 'job-completed'.  Subscription Object A is a Per-
+   Printer Subscription Object.  Subscription Object B is a Per-Job
+   Subscription Object for Job 1, and Subscription Object C is a Per-Job
+   Subscription Object for Job 2.  In addition, Per-Printer Subscription
+   Object D is listening for the Job Event 'job-state-changed'.  When
+   Job 1 completes, the Printer delivers an Event Notification to the
+   Notification Recipient of Subscription Object A (because it is Per-
+   Printer) and Subscription Object B because it is a Per-Job
+   Subscription Object associated with the Job generating the Event.
+   The Printer also delivers an Event Notification to the Notification
+   Recipient of Subscription Object D because 'job-completed' is a sub-
+   value of 'job-state-changed' - the value that Subscription Object D
+   is listening for.  The Printer does not deliver an Event Notification
+   to the Notification Recipients of Subscription Object C because it is
+   a Per-Job Subscription Object associated with some Job other than the
+   Job generating the Event.
+
+5.3.3.5.3.  Special Cases for Matching Rules
+
+   This section contains two rules for the special case where a single
+   Event produces multiple Event Notifications destined for the same
+   Notification Recipient.  These two rules clarify whether a Printer
+
+
+
+Herriot & Hastings          Standards Track                    [Page 27]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   should send multiple Event Notifications or consolidate them into a
+   single Event Notification.
+
+   If an Event matches Subscribed Events in two different Subscription
+   Objects and the Printer would deliver two identical Event
+   Notifications (except for the "notify-subscription-id" attribute) to
+   the same Notification Recipient using the same Delivery Method, the
+   Printer MUST deliver both Event Notifications.  That is, the Printer
+   MUST NOT try to consolidate seemingly identical Event Notifications
+   that occur in separate Subscription objects.  Incidentally, the
+   Printer MUST NOT reject Subscription Creation Operations that would
+   create this scenario.
+
+   Consider the example: At the time a Job completes, there are two
+   Per-Printer Subscription Objects A and B with the same Notification
+   Recipient R.  Subscription Object A has the Subscribed Job Event
+   'job-state-changed'.  Subscription Object B has the Subscribed Job
+   Event 'job-completed'.  Both Subscription Objects match the Event
+   'job-completed'.  The Printer delivers two Event Notifications to the
+   Notification Recipient R.  One with the value of  'job-state-changed'
+   for the "notify-subscribed-event" attribute and the other with the
+   value of  'job-completed' for the "notify-subscribed-event"
+   attribute.
+
+   If an Event matches two Subscribed Events in a single Subscription
+   object (e.g., a value and its sub-value), a Printer MAY deliver one
+   Event Notification for each matched value in the Subscription Object
+   or it MAY deliver only a single Event Notification.  The rules in
+   sections 5.3.3.5.1 and 5.3.3.5.2 are purposefully flexible about the
+   number of Event Notifications sent when Event E matches two or more
+   values in a Subscription Object.
+
+   Consider the example: At the time a Job completes, a Subscription
+   Object A has two Subscribed Job Events 'job-state-changed' and 'job-
+   completed'.  Both Subscribed Job Events match the Event 'job-
+   completed'.  The Printer delivers either one or two Event
+   Notifications to the Notification Recipient of Subscription Object A,
+   depending on implementation.  If it delivers two Event Notifications,
+   one has the value of  'job-state-changed' for the "notify-
+   subscribed-event" attribute, and the other has the value of 'job-
+   completed' for the "notify-subscribed-event" attribute.  If it
+   delivers one Event Notification, it has the value of either 'job-
+   state-changed' or 'job-completed' for the "notify-subscribed-event"
+   attribute, depending on implementation.  The algorithm for choosing
+   such a value is implementation dependent.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 28]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.3.4.  notify-attributes (1setOf type2 keyword)
+
+   This attribute contains a set of attribute names.  When a Printer
+   delivers a Machine Consumable Event Notification, it includes a fixed
+   set of attributes (see section 9.1).  If this attribute is present
+   and the Event Notification is Machine Consumable, the Printer also
+   includes the attributes specified by this attribute.
+
+   A Printer MAY support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation or the Printer does not support this
+   attribute, the Subscription Object either (1) MAY contain the
+   "notify-attributes" attribute with a 'none' value or (2) NEED NOT
+   contain the attribute at all.  There is no "notify-attributes-
+   default" Printer attribute.
+
+   Each keyword value of this attribute on a Subscription Object MUST be
+   a value of the "notify-attributes-supported (1setOf type2 keyword)"
+   Printer attribute (see section 5.3.4.1).  The "notify-attributes-
+   supported" MAY contain any Printer attribute, Job attribute or
+   Subscription Object attribute that the Printer supports in an Event
+   Notification.  It MUST NOT contain any of the attributes in Section
+   9.1 that a Printer automatically puts in an Event Notification; it
+   would be redundant.  If a client supplies an attribute in Section
+   9.1, the Printer MUST treat it as an unsupported attribute value of
+   the "notify-attributes" attribute.
+
+   The following rules apply to each keyword value N of the "notify-
+   attributes" attribute: If the value N names:
+
+   a) a Subscription attribute, the Printer MUST use the attribute N in
+      the Subscription Object that is being used to generate the Event
+      Notification.
+
+   b) a Job attribute and the Printer is generating an Event
+      Notification from a Per-Job Subscription Object S, the Printer
+      MUST use the attribute N in the Job object associated with S.
+
+   c) a Job attribute and the Printer is generating an Event
+      Notification from a Per-Printer Subscription Object and the Event
+      is:
+
+      -  a Job Event, the Printer MUST use the attribute N in the Job
+         object that caused the Event.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 29]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      -  a Printer Event, the Printer MUST use the attribute N in the
+         active Job.
+
+   If a Printer supports this attribute and a Subscription Object
+   contains this attribute and the Delivery Method generates a Machine
+   Consumable Event Notification, the Printer MUST include in each Event
+   Notification:
+
+   a) the attributes specified in section 9.1 and
+
+   b) each attribute named by this attribute.
+
+   The Printer MUST NOT use this attribute to generate a Human
+   Consumable Event Notification.
+
+5.3.4.1.  notify-attributes-supported (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+5.3.5.  notify-user-data (octetString(63))
+
+   This attribute contains opaque data that some Delivery Methods
+   include in each Machine Consumable Event Notification.  The opaque
+   data might contain, for example:
+
+   -  the identity of the Subscriber
+
+   -  a path or index to some Subscriber information
+
+   -  a key that identifies to the Notification Recipient the ultimate
+      recipient of the Event Notification
+
+   -  the id for a Notification Recipient that had previously registered
+      with an Instant Messaging Service
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in the
+   Subscription Creation Operation, the Subscription Object either (1)
+   MAY contain the "notify-user-data" attribute with a zero length value
+   or (2) NEED NOT contain the attribute at all.  There is no "notify-
+   user-data-default" Printer attribute.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 30]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   There is no "notify-user-data-supported" Printer attribute.  Rather,
+   any octetString whose length does not exceed 63 octets is a supported
+   value.  If the length exceeds 63 octets, the Printer MUST treat it as
+   an unsupported value.
+
+5.3.6.  notify-charset (charset)
+
+   This attribute specifies the charset to be used in the Event
+   Notification content sent to the Notification Recipient, whether the
+   Event Notification content is Machine Consumable or Human Consumable.
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation or supplies an unsupported value, the
+   Printer MUST populate this attribute in the Subscription Object with
+   the value of the "attributes-charset" operation attribute, which is a
+   REQUIRED attribute in all IPP requests (see [RFC2911]).  If the value
+   of the "attributes-charset" attribute is unsupported, the Printer
+   MUST populate this attribute in the Subscription Object with the
+   value of the Printer's "charset-configured" attribute.  There is no
+   "notify-charset-default" Printer attribute.
+
+   The value of this attribute on a Subscription Object MUST be a value
+   of the "charset-supported (1setOf charset)" Printer attribute.
+
+5.3.7.  notify-natural-language (naturalLanguage)
+
+   This attribute specifies the natural language to be used in any human
+   consumable text in the Event Notification content sent to the
+   Notification Recipient, whether the Event Notification content is
+   Machine Consumable or Human Consumable.
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation or supplies an unsupported value, the
+   Printer MUST populate this attribute in the Subscription Object with
+   the value of the "attributes-natural-language" operation attribute,
+   which is a REQUIRED attribute in all IPP requests (see [RFC2911]
+   section 3.1.4).  If the value of the "attributes-natural-language"
+   attribute is unsupported, the Printer MUST populate this attribute in
+   the Subscription Object with the value of the Printer's "natural-
+   language-configured" attribute (see [RFC2911] section 4.4.19).  There
+   is no "notify-natural-language-default" Printer attribute.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 31]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   The value of this attribute on a Subscription Object MUST be a value
+   of the "generated-natural-language-supported (1setOf type2
+   naturalLanguage)" Printer attribute (see [RFC2911] section 4.4.20).
+
+5.3.8.  notify-lease-duration (integer(0:67108863))
+
+   This attribute specifies the duration of the lease (in seconds)
+   associated with the Per-Printer Subscription Object at the time the
+   Subscription Object was created or the lease was renewed.  The
+   duration of the lease is infinite if the value is 0, i.e., the lease
+   never expires.  See section 5.4.3 on "notify-lease-expiration-time
+   (integer(0:MAX))" for more details.
+
+   This attribute is not present on a Per-Job Subscription Object
+   because the Subscription Object lasts exactly as long as the
+   associated Job object.  See discussion of the 'job-completed' event
+   in section 5.3.3.4.3 about retention of the Job object after
+   completion.
+
+   A Printer MUST support this attribute.
+
+   For a Subscription Object Creation operation of a Per-Job
+   Subscription Object, the client MUST NOT supply this attribute.  If
+   the client does supply this attribute, the Printer MUST treat it as
+   an unsupported attribute.
+
+   For a Subscription Creation Operation of a Per-Printer Subscription
+   Object or a Renew-Subscription operation, a client MAY supply this
+   attribute.  If the client does not supply this attribute, the Printer
+   MUST populate this attribute with its "notify-lease-duration-default"
+   (0:67108863) attribute value.  If the client supplies this attribute
+   with an unsupported value, the Printer MUST populate this attribute
+   with a supported value, and this value SHOULD be as close as possible
+   to the value requested by the client.  Note: this rule implies that a
+   Printer doesn't assign the value of 0 (infinite) unless the client
+   requests it.
+
+   After the Printer has populated this attribute with a supported
+   value, the value represents the "granted duration" of the lease in
+   seconds and the Printer updates the value of the Subscription
+   Object's "notify-lease-expiration-time" attribute as specified in
+   section 5.4.3.
+
+   The value of this attribute on a Subscription Object MUST be a value
+   of the "notify-lease-duration-supported" (1setOf (integer(0:67108863)
+   | rangeOfInteger(0:67108863))) Printer attribute.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 32]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   A Printer MAY require authentication in order to return the value of
+   0 (the lease never expires) as one of the values of "notify-lease-
+   duration-supported", and to allow 0 as a value of the "notify-lease-
+   duration" attribute.
+
+   Note:  The maximum value 67,108,863 is 2 raised to the 26 power minus
+   1 and is about 2 years in seconds.  The value is considerably less
+   than MAX so that there is virtually no chance of an overflow when the
+   Printer adds it to the Printer's "printer-up-time" attribute value
+   (see [RFC2911] section 4.4.29) to produce the "notify-lease-
+   expiration-time" Subscription Description attribute value (see
+   section 5.4.3).
+
+5.3.8.1.  notify-lease-duration-default (integer(0:67108863))
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-default"
+   Subscription Template Printer attributes.
+
+5.3.8.2. notify-lease-duration-supported (1setOf (integer(0: 67108863) |
+         rangeOfInteger(0:67108863)))
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+5.3.9.  notify-time-interval (integer(0:MAX))
+
+   The 'job-progress' Event occurs each time that a Printer completes a
+   sheet.  Some Notification Recipients do not want to receive an Event
+   Notification every time this Event occurs.  This attribute allows a
+   Subscribing Client to request how often it wants to receive Event
+   Notifications for 'job-progress' Events.  The value of this attribute
+   MAY be any nonnegative integer (0,MAX) indicating the minimum number
+   of seconds between 'job-progress' Event Notifications.
+
+   The Printer MUST support this attribute if and only if the Printer
+   supports the 'job-progress' Event.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in the
+   Subscription Creation Operation, the Subscription Object either (1)
+   MAY contain the "notify-time-interval" attribute with a '0' value or
+   (2) NEED NOT contain this attribute at all.  There is no "notify-
+   time-interval-default" Printer attribute.
+
+   There is no "notify-time-interval-supported" Printer attribute.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 33]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   If the 'job-progress' Event occurs and a Subscription Object contains
+   the 'job-progress' Event as a value of the 'notify-events' attribute,
+   there are two cases to consider:
+
+   1. This attribute is not present on the Subscription Object or has
+      the value of 0.  The Printer MUST generate and deliver an Event
+      Notification (as is the case with other Events).
+
+   2. This attribute is present with a nonzero value of N:
+
+      a) If the Printer has not sent an Event Notification for the
+         'job-progress' Event for the associated Subscription Object
+         within the past N seconds, the Printer MUST deliver an Event
+         Notification for the Event that just occurred.  Note when the
+         Printer completes the first page of a Job, this rule implies
+         that the Printer delivers an Event Notification for a Per-Job
+         Subscription Object.
+
+      b) Otherwise, the Printer MUST NOT generate or deliver an Event
+         Notification for the associated Subscription Object.  The
+         Printer MUST NOT increase the value of the "notify-sequence-
+         number" Subscription Object attribute (i.e., the sequence of
+         values of the "notify-sequence-number" attribute counts the
+         Event Notifications that the Printer sent and not the Events
+         that do not cause an Event Notification to be sent).
+
+   It is RECOMMENDED that a Subscribing Client use this attribute when
+   it subscribes to the 'job-progress' Event, and that the value be
+   sufficiently large to limit the frequency with which the Printer
+   delivers Event Notifications requests.
+
+   This attribute MUST NOT effect any Events other than 'job-progress'.
+
+5.4.  Subscription Description Attributes
+
+   Subscription Description Attributes are those attributes that a
+   Printer adds to a Subscription Object at the time of its creation.
+
+   A Printer MUST support all attributes in this Table 2.
+
+   A client MUST NOT supply the attributes in Table 2 in a Subscription
+   Template Attributes Group of a Subscription Creation Operation.
+   There are no corresponding default or supported attributes.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 34]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 2 - Subscription Description Attributes
+
+      Subscription Object attributes:
+
+      notify-subscription-id (integer(1:MAX))
+      notify-sequence-number (integer(0:MAX))
+      notify-lease-expiration-time (integer(0:MAX))
+      notify-printer-up-time (integer(1:MAX))
+      notify-printer-uri (uri)
+      notify-job-id (integer(1:MAX))
+      notify-subscriber-user-name (name(MAX))
+
+5.4.1.  notify-subscription-id  (integer (1:MAX))
+
+   This attribute identifies a Subscription Object instance with a
+   number that is unique within the context of the Printer.  The Printer
+   generates this value at the time it creates the Subscription Object.
+
+   A Printer MUST support this attribute.
+
+   The Printer MAY assign the value of this attribute sequentially as it
+   creates Subscription Objects.  However, if there is no security on
+   Subscription objects, sequential assignment exposes the system to a
+   passive traffic monitoring threat.
+
+   The Printer SHOULD avoid re-using recent values of this attribute
+   during continuous operation of the Printer as well as across power
+   cycles.  Then a Subscribing Client is unlikely to find that a stale
+   reference accesses a new Subscription Object.
+
+   The 0 value is not permitted in order to allow for compatibility with
+   "job-id" and with MIB table index values, which are recommended not
+   to be 0.
+
+5.4.2.  notify-sequence-number (integer (0:MAX))
+
+   The value of this attribute indicates the number of times that the
+   Printer has generated and attempted to deliver an Event Notification
+   for this Subscription object.  When an Event Notification contains
+   this attribute, the Notification Recipient can determine whether it
+   missed some Event Notifications (i.e., numbers skipped) or received
+   duplicates (i.e., same number twice).
+
+   A Printer MUST support this attribute.
+
+   When the Printer creates a Subscription Object, it MUST populate this
+   attribute with a value of 0.  This value indicates that the Printer
+   has not sent any Event Notifications for this Subscription Object.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 35]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Each time the Printer delivers a newly generated Event Notification,
+   it MUST increase the value of this attribute by 1.  For some Delivery
+   Methods, the Printer MUST include this attribute in each Event
+   Notification, and the value MUST be the value after it is increased
+   by 1.  That is, the value of this attribute in the first Event
+   Notification after Subscription object creation MUST be 1, the second
+   MUST be 2, etc.  If a Delivery Method is defined such that the
+   Notification Recipient returns a response, the Printer can re-try
+   delivering an Event Notification a certain number of times with the
+   same sequence number when the Notification Recipient fails to return
+   a response.
+
+   If a Subscription Object lasts long enough to reach the value of MAX,
+   its next value MUST be 0, i.e., it wraps.
+
+5.4.3.  notify-lease-expiration-time (integer(0:MAX))
+
+   This attribute specifies the time in the future when the lease on the
+   Per-Printer Subscription Object will expire, i.e., the "printer-up-
+   time" value at which the lease will expire.  If the value is 0, the
+   lease never expires.
+
+   A Printer MUST support this attribute.
+
+   When the Printer creates a Per-Job Subscription Object, this
+   attribute MUST NOT be present - the Subscription Object lasts exactly
+   as long as the associated Job object.  See also the discussion of the
+   'job-completed' event in section 5.3.3.4.3 about retention of the Job
+   object after completion so that a Notification Recipient can query
+   the Job object after receiving the 'job-completed' Event
+   Notification.
+
+   When the Printer creates a Per-Printer Subscription Object, it
+   populates this attribute with a value that is the sum of the values
+   of the Printer's "printer-up-time" attribute and the Subscription
+   Object's "notify-lease-duration" attribute with the following
+   exception.  If the value of the Subscription Object's "notify-lease-
+   duration" attribute is 0 (i.e., no expiration time), then the value
+   of this attribute MUST be set to 0 (i.e., no expiration time).
+
+   When the Printer powers up, it MUST populate this attribute in each
+   persistent Subscription Object with a value using the algorithm in
+   the previous paragraph.
+
+   When the "printer-up-time" equals the value of this attribute, the
+   Printer MUST delete the Subscription Object.  A client can extend a
+   lease of a Per-Printer Subscription Object with the Renew-
+   Subscription operation (see section 11.2.6).
+
+
+
+Herriot & Hastings          Standards Track                    [Page 36]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Note: In order to compute the number of seconds remaining in a lease
+   for a Per-Printer Subscription Object, a client can subtract the
+   Subscription's "notify-printer-up-time" attribute (see section 5.4.4)
+   from the Subscription's "notify-lease-expiration-time" attribute.
+
+5.4.4.  notify-printer-up-time (integer(1:MAX))
+
+   This attribute is an alias for the Printer's "printer-up-time"
+   attribute " (see [RFC2911] section 4.4.29).  In other words, when
+   this attribute is queried with the Get-Subscriptions or Get-
+   Subscription-Attributes operations (see sections 11.2.4 and 11.2.5),
+   the value returned is the current value of the Printer's "printer-
+   up-time" attribute, rather than the time at which the Subscription
+   Object was created.
+
+   A Printer MUST support this attribute.
+
+   When the Printer creates a Per-Job Subscription Object, this
+   attribute MUST NOT be present.  When the Printer creates a Per-
+   Printer Subscription Object, this attribute MUST be present.
+
+   Note: this attribute exists in a Per-Printer Subscription Object so
+   that a client using the Get-Subscription-Attributes or Get-
+   Subscription operations can convert the Per-Printer Subscription's
+   "notify-lease-expiration-time" attribute to wall clock time with one
+   request.  If the value of the "notify-lease-expiration-time"
+   attribute is not 0 (i.e., no expiration time), then the difference
+   between the "notify-lease-expiration-time" attribute and the
+   "notify-printer-up-time" is the remaining number of seconds on the
+   lease from the current time.
+
+5.4.5.  notify-printer-uri (uri)
+
+   This attribute identifies the Printer object that created this
+   Subscription Object.
+
+   A Printer MUST support this attribute.
+
+   During a Subscription Creation Operation, the Printer MUST populate
+   this attribute with the value of the "printer-uri" operation
+   attribute in the request.  From the Printer URI, the client can, for
+   example, determine what security scheme was used.
+
+5.4.6.  notify-job-id (integer(1:MAX))
+
+   This attribute specifies whether the containing Subscription Object
+   is a Per-Job or Per-Printer Subscription Object, and for Per-Job
+   Subscription Objects, it specifies the associated Job.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 37]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   A Printer MUST support this attribute.
+
+   If this attribute is not present, the Subscription Object MUST be a
+   Per-Printer Subscription.  If this attribute is present, the
+   Subscription Object MUST be a Per-Job Subscription Object and this
+   attribute MUST identify the Job with which the Subscription Object is
+   associated.
+
+   Note: This attribute could be useful to a Notification Recipient that
+   receives an Event Notification generated from a Per-Job Subscription
+   Object and caused by a Printer Event.  The Event Notification gives
+   access to the Printer and the Subscription Object.  The Event
+   Notification gives access to the associated Job only via this
+   attribute.  See discussion of the 'job-completed' event in section
+   5.3.3.4.3 about retention of the Job object after completion so that
+   a Notification Recipient can query the Job object after receiving the
+   'job-completed' Event Notification.
+
+5.4.7.  notify-subscriber-user-name (name(MAX))
+
+   This attribute contains the name of the user who performed the
+   Subscription Creation Operation.
+
+   A Printer MUST support this attribute.
+
+   The Printer MUST populates this attribute with the most authenticated
+   printable name that it can obtain from the authentication service
+   over which the Subscription Creation Operation was received.  The
+   Printer uses the same mechanism for determining the value of this
+   attribute as it does for a Job's "job-originating-user-name" (see
+   [RFC2911] section 4.3.6).
+
+   Note:  To help with authentication, a Subscription Object may have
+   additional private attributes about the user, e.g., a credential of a
+   principal.  Such private attributes are implementation-dependent and
+   not defined in this document.
+
+6.  Printer Description Attributes Related to Notification
+
+   This section defines the Printer Description attributes that are
+   related to Notification.  Table 3 lists the Printer Description
+   attributes, indicates the Printer support required for conformance,
+   and whether or not the attribute is READ-ONLY (see section 3.1):
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 38]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 3 - Printer Description Attributes Associated with Notification
+
+   Printer object attributes:                   REQUIRED     READ-ONLY
+
+   printer-state-change-time (integer(1:MAX))   No           Yes
+   printer-state-change-date-time (dateTime)    No           Yes
+
+6.1.  printer-state-change-time (integer(1:MAX))
+
+   This OPTIONAL attribute records the most recent time at which the
+   'printer-state-changed' Printer Event occurred whether or not any
+   Subscription objects were listening for this event.  This attribute
+   helps a client or operator to determine how long the Printer has been
+   in its current state.
+
+   A Printer MAY support this attribute and if so, the attribute MUST be
+   READ-ONLY.
+
+   On power-up, the Printer MUST populate this attribute with the value
+   of its "printer-up-time" attribute, so that it always has a value.
+   Whenever the 'printer-state-changed' Printer Event occurs, the
+   Printer MUST update this attribute with the value of the Printer's
+   "printer-up-time" attribute.
+
+6.2.  printer-state-change-date-time (dateTime)
+
+   This OPTIONAL attribute records the most recent time at which the
+   'printer-state-changed' Printer Event occurred whether or not there
+   were any Subscription Objects listening for this event.  This
+   attribute helps a client or operator to determine how long the
+   Printer has been in its current state.
+
+   A Printer MAY support this attribute and if so, the attribute MUST be
+   READ-ONLY.
+
+   On power-up, the Printer MUST populate this attribute with the value
+   of its "printer-current-time" attribute, so that it always has a
+   value (see [RFC2911] section 4.4.30 on "printer-current-time").
+   Whenever the 'printer-state-changed' Printer Event occurs, the
+   Printer MUST update this attribute with the value of the Printer's
+   "printer-current-time" attribute.
+
+7.  New Values for Existing Printer Description Attributes
+
+   This section contains those attributes for which additional values
+   are added.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 39]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+7.1.  operations-supported (1setOf type2 enum)
+
+   The following "operation-id" values are added in order to support the
+   new operations defined in this document:
+
+   Table 4 - Operation-id assignments
+
+   Value       Operation Name
+
+   0x0016      Create-Printer-Subscriptions
+   0x0017      Create-Job-Subscriptions
+   0x0018      Get-Subscription-Attributes
+   0x0019      Get-Subscriptions
+   0x001A      Renew-Subscription
+   0x001B      Cancel-Subscription
+
+8.  Attributes Only in Event Notifications
+
+   This section contains those attributes that exist only in Event
+   Notifications and do not exist in any objects.
+
+8.1.  notify-subscribed-event (type2 keyword)
+
+   This attribute indicates the Subscribed Event that caused the Printer
+   to deliver this Event Notification.  This attribute exists only in
+   Event Notifications.
+
+   This attribute MUST contain one of the values of the "notify-events"
+   attribute in the Subscription Object, i.e., one of the Subscribed
+   Event values.  Its value is the Subscribed Event that "matches" the
+   Event that caused the Printer to deliver this Event Notification.
+   This Subscribed Event value may be identical to the Event or the
+   Event may be a sub-value of the Subscribed Event.  For example, the
+   'job-completed' Event (which is a sub-event of the 'job-state-
+   changed' event) would cause the Printer to deliver an Event
+   Notification for either the 'job-completed' or 'job-state-changed'
+   Subscribed Events and to deliver the 'job-completed' or 'job-state-
+   changed' value for this attribute, respectively.  See section 5.3.3.5
+   for the "matching" rules of Subscribed Events and for additional
+   examples.
+
+   The Delivery Method Document specifies whether the Printer includes
+   the value of this attribute in an Event Notification.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 40]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+8.2.  notify-text (text(MAX))
+
+   This attribute contains a Human Consumable text message (see section
+   9.2).  This message describes the Event and is encoded as plain text,
+   i.e., 'text/plain' with the charset specified by Subscription
+   Object's "notify-charset" attribute.
+
+   Note: this attribute contains a text message only and must not
+   contain any encoding information, such as 'text/plain'.  The
+   'text/plain' encoding is implicit and thus the charset must be
+   specified by an alternate mechanism, namely the "notify-charset"
+   attribute.
+
+   The Delivery Method Document specifies whether the Printer includes
+   this attribute in an Event Notification.
+
+9.  Event Notification Content
+
+   This section defines the Event Notification content that the Printer
+   delivers when an Event occurs.
+
+   When an Event occurs, the Printer MUST find each Subscription object
+   whose "notify-events" attribute "matches" the Event.  See section
+   5.3.3.5 for details on "matching".  For each matched Subscription
+   Object, the Printer MUST create an Event Notification with the
+   content and format that the Delivery Method Document specifies.  The
+   content contains the value of attributes specified by the Delivery
+   Method Document.  The Printer obtains the values immediately after
+   the Event occurs.  For example, if the "printer-state" attribute
+   changes from 'idle' to 'processing', the Event 'printer-state-
+   changed' occurs and the Printer puts various attributes into the
+   Event Notification, including "printer-up-time" and "printer-state"
+   with the values that they have immediately after the Event occurs,
+   i.e., the value of  "printer-state" is 'processing'.
+
+   Event Notification Ordering:
+
+   When a Printer delivers Event Notifications, the Event Notifications
+   from any given Subscription Object MUST be in time stamp order, i.e.,
+   in order of increasing "printer-up-time" attribute value in the Event
+   Notification (see Table 5).  These Event Notifications MAY be
+   interleaved with those from other Subscription Objects, as long as
+   those others are also in time stamp order.  The Printer MUST observe
+   these ordering requirements whether delivering multiple pending
+   Events as multiple separate Event Notifications or together in a
+   single Compound Event Notification.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 41]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   If a Subscribing Client wants the Printer to deliver certain Event
+   Notifications in time stamp order, the Subscribing Client uses a
+   single Subscription Object.  Even so, depending on the underlying
+   transport, the actual order that a Notification Recipient receives
+   separate Event Notifications may differ from the order sent by the
+   Printer (e.g., email).
+
+   Example:  Consider two Per-Printer Subscription Objects: SO1 and SO2.
+   SO1 requests 'job-state-changed' events and SO2 requests 'printer-
+   state-changed' events.  The number in parens is the time stamp.  The
+   following Event Notification sequences are the only ones that conform
+   to the ordering requirements for the Printer to deliver the Event
+   Notifications:
+
+      (a) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO1:
+      'job-completed' (1009), SO2: 'printer-stopped' (1005)
+
+      (b) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO2:
+      'printer-stopped' (1005), SO1: 'job-completed' (1009)
+
+      (c) SO1: 'job-created' (1000), SO2: 'printer-stopped' (1005), SO1:
+      'job-stopped' (1005), SO1: 'job-completed' (1009)
+
+      (d) SO2: 'printer-stopped (1005), SO1: 'job-created' (1000), SO1:
+      'job-stopped' (1005), SO1: 'job-completed' (1009)
+
+   Examples (b) and (c) are interleaved; examples (a) and (d) are not
+   interleaved and are not appropriate for some Delivery Methods.
+
+   If two different Events occur simultaneously, or nearly so (e.g.,
+   "printer-up-time" has the same value for both), the Printer MUST
+   create a separate Event Notification for each Event, even if the
+   associated Subscription Object is the same for both Events.  However,
+   the Printer MAY combine these distinct Event Notifications into a
+   single Compound Event Notification if the Delivery Method supports
+   Compound Event Notifications.  For example, suppose that two nearly-
+   simultaneously Events represent two successive 'printer-state-
+   changed' Events, one from 'idle' to 'processing' and another from
+   'processing' to 'stopped'.  These two Events have the same name but
+   are different instances of the Event.  Then the Printer MUST create a
+   separate Event Notification for each Event and SHOULD accurately
+   report the "printer-state" of the first Event as 'processing' and the
+   second Event as 'stopped'.
+
+   If a Subscription Object contains more than one Subscribed Event, and
+   several Events occur in quick succession each matching a different
+   Subscribed Event in the Subscription Object, the Printer MUST NOT
+   generate a single Event Notification from several of these Events,
+
+
+
+Herriot & Hastings          Standards Track                    [Page 42]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   but MAY combine distinct Event Notifications into a single Compound
+   Event Notification if the Delivery Method supports Compound Event
+   Notifications.
+
+   After the Printer has created the Event Notification, the Printer
+   delivers it via either a:
+
+      Push Delivery Method: The Printer delivers the Event Notification
+      shortly after an Event occurs.  For some Push Delivery Methods,
+      the Notification Recipient MUST deliver a response; for others it
+      MUST NOT deliver a response.
+
+      Pull Delivery Method: The Printer saves Event Notifications for
+      some Event Life and expects the Notification Recipient to request
+      Event Notifications.  The Printer returns the Event Notifications
+      in a response to such a request.
+
+   If an error that meets the following conditions occurs, the Printer
+   MUST cancel the Subscription Object.
+
+   a) the error occurs during the delivering of an Event Notification
+      generated from Subscription Object S AND
+
+   b) the error would continue to occur every time the Printer delivers
+      an Event Notification generated from Subscription Object S in the
+      future.
+
+   For example, if the address of the "notify-recipient-uri" of
+   Subscription Object A references a non-existent target and the
+   Printer determines this fact, it MUST delete Subscription Object A.
+
+   The next two sections describe the values that a Printer delivers in
+   the content of Machine Consumable and Human Consumable Event
+   Notifications, respectively.
+
+   The tables in the sub-sections of this section contain the following
+   columns:
+
+   a) Source Value: the name of the attribute that supplies the value
+      for the Event Notification.  Asterisks in this field refer to a
+      note below the table.
+
+   b) Delivers: if the Printer supports the value (column 1) on the
+      Source Object (column 3) the Delivery Method MUST specify:
+
+         MUST: that the Printer MUST deliver the value.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 43]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         SHOULD: either that the Printer MUST deliver the value or that
+         the value is incompatible with the Delivery Method.
+
+         MAY: that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT,
+         or NEED NOT deliver the value.  The Delivery Method specifies
+         the level of conformance for the Printer.
+
+   c) Source Object: the object from which the source value comes.  If
+      the object is "Event Notification", the Printer fabricates the
+      value when it delivers the Event Notification.  See section 8.
+
+9.1.  Content of Machine Consumable Event Notifications
+
+   This section defines the attributes that a Delivery Method MUST
+   mention in a Delivery Method Document when specifying the Machine
+   Consumable Event Notification's contents.
+
+   This document does not define the order of attributes in Event
+   Notifications.  However, Delivery Method Documents MAY define the
+   order of some or all of the attributes.
+
+   A Delivery Method Document MUST specify additional attributes (if
+   any) that a Printer implementation delivers in a Machine Consumable
+   Event Notification.
+
+   Notification Recipients MUST be able to accept Event Notifications
+   containing attributes they do not recognize.  What a Notification
+   Recipient does with an unrecognized attribute is implementation-
+   dependent.  Notification Recipients MAY attempt to display
+   unrecognized attributes anyway or MAY ignore them.
+
+   The next three sections define the attributes in Event Notification
+   Contents that are:
+
+      1. for all Events
+
+      2. for Job Events only
+
+      3. for Printer Events only
+
+9.1.1.  Event Notification Content Common to All Events
+
+   This section lists the attributes that a Delivery Method Document
+   MUST specify for all Events.
+
+   Table 5 lists potential values in each Event Notification.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 44]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 5 - Attributes in Event Notification Content
+
+   Source Value                               Delivers   Source Object
+
+   notify-subscription-id (integer(1:MAX))    MUST       Subscription
+   notify-printer-uri (uri)                   MUST       Subscription
+   notify-subscribed-event (type2 keyword)    MUST       Event
+                                                         Notification
+   printer-up-time (integer(MIN:MAX))         MUST       Printer
+   printer-current-time (dateTime) *          MUST       Printer
+   notify-sequence-number (integer (0:MAX))   SHOULD     Subscription
+   notify-charset (charset)                   SHOULD     Subscription
+   notify-natural-language (naturalLanguage)  SHOULD     Subscription
+   notify-user-data (octetString(63)) **      SHOULD     Subscription
+   notify-text (text)                         SHOULD     Event
+                                                         Notification
+   attributes from the "notify-attributes"    MAY        Printer
+   attribute ***
+   attributes from the "notify-attributes"    MAY        Job
+   attribute ***
+   attributes from the "notify-attributes"    MAY        Subscription
+   attribute ***
+
+   *A Printer MUST deliver this value only if and only if it supports
+   the Printer's "printer-current-time" attribute.
+
+   ** If the Subscription Object does not contain a "notify-user-data"
+   attribute and the Delivery Method Document REQUIRES the Printer to
+   deliver the "notify-user-data" source value in the Event
+   Notification, the Printer MUST deliver an octet-string of length 0.
+
+   *** The last three rows represent additional attributes that a client
+   MAY request via the  "notify-attributes" attribute.  A Printer MAY
+   support the "notify-attributes" attribute.  The Delivery Method MUST
+   say that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, or NEED
+   NOT support the "notify-attributes" attribute and specific values of
+   this attribute.  The Delivery Method MAY say that support for the
+   "notify-attributes" is conditioned on support of the attribute by the
+   Printer or it MAY say that Printer MUST support the "notify-
+   attributes" attribute if the Printer supports the Delivery Method.
+
+9.1.2.  Additional Event Notification Content for Job Events
+
+   This section lists the additional attributes that a Delivery Method
+   Document MUST specify for Job Events.  See Table 6.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 45]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 6 - Additional Event Notification Content for Job Events
+
+   Source Value                                  Delivers  Source
+                                                            Object
+
+   job-id (integer(1:MAX))                       MUST      Job
+   job-state (type1 enum)                        MUST      Job
+   job-state-reasons (1setOf type2 keyword)      MUST      Job
+   job-impressions-completed (integer(0:MAX)) *  MUST      Job
+
+   *  The Printer MUST deliver the "job-impressions-completed" attribute
+   in an Event Notification only for the combinations of Events and
+   Subscribed Events shown in Table 7.
+
+   Table 7 - Combinations of Events and Subscribed Events for "job-
+   impressions-completed"
+
+   Job Event              Subscribed Job Event
+
+   'job-progress'         'job-progress'
+   'job-completed'        'job-completed'
+   'job-completed'        'job-state-changed'
+
+9.1.3.  Additional Event Notification Content for Printer Events
+
+   This section lists the additional attributes that a Delivery Method
+   Document MUST specify for Printer Events.  See Table 8.
+
+   Table 8 - Additional Event Notification Content for Printer Events
+
+   Source Value                             Delivers   Source Object
+
+   printer-state (type1 enum)               MUST       Printer
+   printer-state-reasons (1setOf type2      MUST       Printer
+   keyword)
+   printer-is-accepting-jobs (boolean)      MUST       Printer
+
+9.2.  Content of Human Consumable Event Notification
+
+   This section defines the information that a Delivery Method MUST
+   mention in a Delivery Method Document when specifying the Human
+   Consumable Event Notifications contents or the value of the "notify-
+   text" attribute.
+
+   Such a Delivery Method MUST specify the following information and a
+   Printer SHOULD deliver it:
+
+   a) the Printer name (see Table 9)
+
+
+
+Herriot & Hastings          Standards Track                    [Page 46]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   b) the time of the Event (see Table 11)
+
+   c) for Printer Events only:
+
+      i) the Event (see Table 10) and/or Printer state information (see
+         Table 14)
+
+   d) for Job Events only:
+
+      i) the job identity (see Table 12)
+
+      ii) the Event (see Table 10) and/or Job state information (see
+          Table 13)
+
+   The subsections of this section specify the attributes that a Printer
+   MUST use to obtain this information.
+
+   A Delivery Method Document MUST specify additional information (if
+   any) that a Printer implementation delivers in a Human Consumable
+   Event Notification or in the "notify-text" attribute.
+
+   A client MUST NOT request additional attributes via the "notify-
+   attributes" attribute because this attribute works only for Machine
+   Consumable Event Notifications.
+
+   Notification Recipients MUST NOT expect to be able to parse the Human
+   Consumable Event Notification contents or the value of the "notify-
+   text" attribute.
+
+   The next three sections define the attributes in Event Notification
+   Contents that are:
+
+      a) for all Events
+      b) for Job Events only
+      c) for Printer Events only
+
+9.2.1.  Event Notification Content Common to All Events
+
+   This section lists the source of the information that a Delivery
+   Method MUST specify for all Events.
+
+   There is a separate table for each piece of information.  Each row in
+   the table represents a source value for the information and the
+   values are listed in order of preference, with the first one being
+   the preferred one.  An implementation SHOULD use the source value
+   from the earliest row in each table.  It MAY use the source value
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 47]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   from another row instead, or it MAY combine the source values from
+   several rows.  An implementation is free to determine the best way to
+   present this information.
+
+   In all tables of this section, all rows contain a "MAY" in order to
+   state that the Delivery Method specifies the conformance.
+
+   Table 9 lists the source of the information for the Printer Name.
+   The "printer-name" is more user-friendly unless the Notification
+   Recipient is in a place where the Printer name is not meaningful.
+   For example, an implementation could have the intelligence to deliver
+   the value of the "printer-name" attribute to a Notification Recipient
+   that can access the Printer via value of the "printer-name" attribute
+   and otherwise deliver the value of the "notify-printer-uri"
+   attribute.
+
+   Table 9 - Printer Name in Event Notification Content
+
+   Source Value                            Delivers   Source Object
+
+   printer-name (name(127))                MAY        Printer
+   notify-printer-uri (uri)                MAY        Subscription
+
+
+   Table 10 lists the source of the information for the Event name.  A
+   Printer MAY combine this information with state information described
+   for Jobs in Table 13 or for Printers in Table 14.
+
+   Table 10 - Event Name in Event Notification Content
+
+   Source Value                             Delivers    Source Object
+
+   notify-subscribed-event (type2 keyword)  MAY         Subscription
+
+   Table 11 lists the source of the information for the time that the
+   Event occurred.  A Printer can deliver this value only if it supports
+   the Printer's "printer-current-time" attribute.  If a Printer does
+   not support the "printer-current-time" attribute, it MUST NOT deliver
+   the "printer-up-time" value instead, since it is not an allowed
+   option for human consumable information.
+
+   Table 11 - Event Time in Event Notification Content
+
+   Source Value                            Delivers   Source Object
+
+   printer-current-time (dateTime)         MAY        Printer
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 48]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+9.2.2.  Additional Event Notification Content for Job Events
+
+   This section lists the source of the additional information that a
+   Delivery Method MUST specify for Job Events.
+
+   Table 12 lists the source of the information for the job name.  The
+   "job-name" is likely more meaningful to a user than "job-id".
+
+   Table 12 - Job Name in Event Notification Content
+
+   Source Value                           Delivers    Source Object
+
+   job-name (name(MAX))                   MAY         Job
+   job-id (integer(1:MAX))                MAY         Job
+
+   Table 13 lists the source of the information for the job state.  If a
+   Printer supports the "job-state-message" and "job-detailed-state-
+   message" attributes, it SHOULD use those attributes for the job state
+   information, otherwise, it should fabricate such information from the
+   "job-state" and "job-state-reasons".  For some Events, a Printer MAY
+   combine this information with Event information.
+
+   Table 13 - Job State in Event Notification Content
+
+   Source Value                                     Delivers  Source
+                                                               Object
+
+   job-state-message (text(MAX))                    MAY       Job
+   job-detailed-status-messages (1setOf text(MAX))  MAY       Job
+   job-state (type1 enum)                           MAY       Job
+   job-state-reasons (1setOf type2 keyword)         MAY       Job
+
+9.2.3.  Additional Event Notification Content for Printer Events
+
+   This section lists the source of the additional information that a
+   Delivery Method MUST specify for Printer Events.
+
+   Table 14 lists the source of the information for the printer state.
+   If a Printer supports the "printer-state-message", it SHOULD use that
+   attribute for the job state information, otherwise it SHOULD
+   fabricate such information from the "printer-state" and "printer-
+   state-reasons".  For some Events, a Printer MAY combine this
+   information with Event information.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 49]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 14 - Printer State in Event Notification Content
+
+   Source Value                                    Delivers   Source
+                                                               Object
+
+   printer-state-message (text(MAX))               MAY        Printer
+   printer-state (type1 enum)                      MAY        Printer
+   printer-state-reasons (1setOf type2 keyword)    MAY        Printer
+   printer-is-accepting-jobs (boolean)             MAY        Printer
+
+10.  Delivery Methods
+
+   A Delivery Method is the mechanism, i.e., protocol, by which the
+   Printer delivers an Event Notification to a Notification Recipient.
+   There are several potential Delivery Methods for Event Notifications,
+   standardized, as well as proprietary.  This specification REQUIRES
+   that the 'ippget' Pull Delivery Method [RFC3996] be supported.
+   Conforming implementations MAY support additional Push or Pull
+   Delivery Methods as well.  This document does not define any of these
+   delivery mechanisms.  Each Delivery Method MUST be defined in a
+   Delivery Method Document that is separate from this document.  New
+   Delivery Methods will be created as needed using an extension to the
+   registration procedures defined in [RFC2911].  Such documents are
+   registered with IANA (see section 23.7.3).
+
+   The following sorts of Delivery Methods are possible:
+
+   -  The Notification Recipient polls for Event Notifications at
+      intervals directed by the Printer
+
+   -  The Printer delivers Event Notifications to the Notification
+      Recipient using http as the transport.
+
+   -  The Printer delivers an email message.
+
+   This section specifies how to define a Delivery Method Document and
+   what to put in such a document.
+
+   A Delivery Method Document MUST contain an exact copy of the
+   following paragraph, caption and table.  In addition, column 2 of the
+   table in the Delivery Method Document MUST contain answers to
+   questions in column 1 for the Delivery Method.  Also, the Delivery
+   Method document MUST contain a reference to this document and call
+   that reference [RFC3995] because the table contains an [RFC3995]
+   reference.
+
+   If a Printer supports this Delivery Method, the following are its
+   characteristics.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 50]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 15 - Information about the Delivery Method
+
+   Document Method Conformance Requirement     Delivery Method
+                                               Realization
+
+   1.  What is the URL scheme name for the Push Delivery Method or the
+       keyword method name for the Pull Delivery Method?
+
+   2.  Is the Delivery Method REQUIRED, RECOMMENDED, or OPTIONAL for an
+       IPP Printer to support?
+
+   3.  What transport and delivery protocols does the Printer use to
+       deliver the Event Notification Content, i.e., what is the entire
+       network stack?
+
+   4.  Can several Event Notifications be combined into a Compound Event
+       Notification?
+
+   5.  Is the Delivery Method initiated by the Notification Recipient
+       (pull), or by the Printer (push)?
+
+   6.  Is the Event Notification content Machine Consumable or Human
+       Consumable?
+
+   7.  What section in this document answers the following question?
+       For a Machine Consumable Event Notification, what is the
+       representation and encoding of values defined in section 9.1 of
+       [RFC3995] and the conformance requirements thereof?  For a Human
+       Consumable Event Notification, what is the representation and
+       encoding of pieces of information defined in section 9.2 of
+       [RFC3995] and the conformance requirements thereof?
+
+   8.  What are the latency and reliability of the transport and
+       delivery protocol?
+
+   9.  What are the security aspects of the transport and delivery
+       protocol, e.g., how it is handled in firewalls?
+
+   10.  What are the content length restrictions?
+
+   11.  What are the additional values or pieces of information that a
+        Printer delivers in an Event Notification content and the
+        conformance requirements thereof?
+
+   12.  What are the additional Subscription Template and/or
+        Subscription Description attributes and the conformance
+        requirements thereof?
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 51]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   13.  What are the additional Printer Description attributes and the
+        conformance requirements thereof?
+
+11.  Operations for Notification
+
+   This section defines all of the operations for Notification.  Section
+   7.1 assigns the "operation-id" for each operation.  The following two
+   sub-sections define Subscription Creation Operations, and other
+   operations.
+
+11.1.  Subscription Creation Operations
+
+   This section defines the Subscription Creation Operations.  The first
+   section on Create-Job-Subscriptions gives most of the information.
+   The other Subscription Creation Operations refer to the section on
+   Create-Job-Subscriptions, even though the Create-Job-Subscriptions
+   operation is the only OPTIONAL operation in this document (see
+   section 12).
+
+   A Printer MUST support Create-Printer-Subscriptions and the
+   Subscription Template Attributes Group in Job Creation operations.
+   It MAY support Create-Job-Subscriptions operations.
+
+11.1.1.  Create-Job-Subscriptions Operation
+
+   The operation creates one or more Per-Job Subscription Objects.  The
+   client supplies one or more Subscription Template Attributes Groups
+   each containing one or more of Subscription Template Attributes
+   (defined in section 5.3).
+
+   Except for errors, the Printer MUST create exactly one Per-Job
+   Subscription Object from each Subscription Template Attributes Group
+   in the request, even if the newly created Subscription Object would
+   have identical behavior to some existing Subscription Object.  The
+   Printer MUST associate each newly created Per-Job Subscription Object
+   with the target Job, which is specified by the "notify-job-id"
+   operation attribute.
+
+   The Printer MUST accept the request in any of the target job's 'not-
+   completed' states, i.e., 'pending', 'pending-held', 'processing', or
+   'processing-stopped'.  The Printer MUST NOT change the job's "job-
+   state" attribute because of this operation.  If the target job is in
+   any of the 'completed' states, i.e., 'completed', 'canceled', or
+   'aborted, then the Printer MUST reject the request and return the
+   'client-error-not-possible' status code; the response MUST NOT
+   contain any Subscription Attribute Groups.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 52]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Access Rights:  To create Per-Job Subscription Objects, the
+   authenticated user (see [RFC2911] section 8.3) performing this
+   operation MUST (1) be the job owner, (2) have Operator or
+   Administrator access rights for this Printer (see [RFC2911] sections
+   1 and 8.5), or (3) be otherwise authorized by the Printer's
+   administrator-configured security policy to create Per-Job
+   Subscription Objects for the target job.  Otherwise the Printer MUST
+   reject the operation and return: the 'client-error-forbidden',
+   'client-error-not-authenticated', or 'client-error-not-authorized'
+   status code as appropriate.
+
+11.1.1.1.  Create-Job-Subscriptions Request
+
+   The following groups of attributes are part of the Create-Job-
+   Subscriptions Request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.1.1.1.1.  notify-job-id (integer(1:MAX))
+
+   The client MUST supply this attribute and it MUST specify the Job
+   object to associate the Per-Job Subscription with.  The value of
+   "notify-job-id" MUST be the value of the "job-id" of the associated
+   Job object.  If the client does not supply this attribute, the
+   Printer MUST reject this request with a 'client-error-bad-request'
+   status code.
+
+   Group 2-N: Subscription Template Attributes
+
+      For each occurrence of this group:
+
+         The client MUST supply one or more Subscription Template
+         Attributes in any order.  See section 5.3 for a description of
+         each such attribute.  See section 5.2 for details on processing
+         these attributes.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 53]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.1.1.2.  Create-Job-Subscriptions Response
+
+   The Printer MUST return to the client the following sets of
+   attributes as part of a Create-Job-Subscriptions response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      In addition to the REQUIRED status code returned in every
+      response, the response OPTIONALLY includes a "status-message"
+      (text(255)) and/or a "detailed-status-message" (text(MAX))
+      operation attribute as described in [RFC2911] sections 13 and
+      3.1.6.
+
+      In this group, the Printer can return any status codes defined in
+      [RFC2911] and section 12.  The following is a description of the
+      important status codes:
+
+      successful-ok: the Printer created all Subscription Objects
+         requested (see [RFC2911]).
+
+      successful-ok-ignored-subscriptions: the Printer created some
+         Subscription Objects requested but some failed.  The
+         Subscription Attributes Groups with a "notify-status-code"
+         attribute are the ones that failed (see section 12.1).
+
+      client-error-ignored-all-subscriptions: the Printer created no
+         Subscription Objects requested and all failed.  The
+         Subscription Attributes Groups with a "notify-status-code"
+         attribute are the ones that failed (see section 12.2).
+
+      client-error-not-possible: For this operation and other Per-Job
+         Subscription operations, this error can occur because the
+         specified Job has already completed (see [RFC2911], whether or
+         not the Job is retained in the Job Retention and/or Job History
+         phases (see [RFC2911] section 4.3.7.1).
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.  This group does not contain any unsupported
+      Subscription Template Attributes; they are returned in the
+      Subscription Attributes Group (see below).
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 54]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Group 3-N: Subscription Attributes
+
+      These groups MUST be returned unless the Printer is unable to
+      interpret the entire request, e.g., the "status-code" parameter
+      returned in Group 1 has the value: 'client-error-bad-request'.
+
+      "notify-status-code" (type2 enum):
+         Indicates the status of this subscription (see section 13 for
+         the status code definitions).  Section 5.2 defines when this
+         attribute MUST be present in this group.
+
+      See section 5.2 for details on the contents of each occurrence of
+      this group.
+
+11.1.2.  Create-Printer-Subscriptions operation
+
+   The operation is identical to Create-Job-Subscriptions with
+   exceptions noted in this section.
+
+   The operation creates Per-Printer Subscription Objects instead of
+   Per-Job Subscription Objects, and associates each newly created Per-
+   Printer Subscription Object with the Printer specified by the
+   operation target rather than with a specific Job.
+
+   The Printer MUST accept the request in any of its states, i.e.,
+   'idle', 'processing', or 'stopped'.  The Printer MUST NOT change its
+   "printer-state" attribute because of this operation.
+
+   Access Rights:  To create Per-Printer Subscription Objects, the
+   authenticated user (see [RFC2911] section 8.3) performing this
+   operation MUST have (1) Operator or Administrator access rights for
+   this Printer (see [RFC2911] sections 1 and 8.5), or (2) be otherwise
+   authorized by the Printer's administrator-configured security policy
+   to create Per-Printer Subscription Objects for this Printer.
+   Otherwise, the Printer MUST reject the operation and return: the
+   'client-error-forbidden', 'client-error-not-authenticated', or
+   'client-error-not-authorized' status code as appropriate.
+
+11.1.2.1.  Create-Printer-Subscriptions Request
+
+   The groups are identical to the Create-Job-Subscriptions (see section
+   11.1.1.1) except that the Operation Attributes group MUST NOT contain
+   the  "notify-job-id" attribute.  If the client does supply the
+   "notify-job-id" attribute, then the Printer MUST treat it as any
+   other unsupported Operation attribute and MUST return it in the
+   Unsupported Attributes group.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 55]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.1.2.2.  Create-Printer-Subscriptions Response
+
+   The groups are identical to the Create-Job-Subscriptions (see section
+   11.1.1.2).
+
+11.1.3.  Job Creation Operations - Extensions for Notification
+
+   This document extends the Job Creation operations (see section 3.2)
+   to create Subscription Objects as a part of the operation.
+
+   The Job Creation operations are identical to Create-Job-Subscriptions
+   operation with exceptions noted in this section.
+
+   Unlike the Create-Job-Subscriptions operation, a Job Creation
+   operation associates the newly created Subscription Objects with the
+   Job object created by this operation.  The operation succeeds if and
+   only if the Job creation succeeds.  If the Printer does not create
+   some or all of the requested Subscription Objects, the Printer MUST
+   return a  'successful-ok-ignored-subscriptions' status-code instead
+   of a 'successful-ok' status-code, but the Printer MUST NOT reject the
+   operation because of a failure to create Subscription Objects.
+
+   If the Job Creation operation includes a Job Template group, the
+   client MUST supply it after the Operation Attributes group and before
+   the first Subscription Template Attributes Group.
+
+   If a Printer does not support this Notification specification, then
+   it MUST treat the Subscription Attributes Group like an unknown group
+   and ignore it (see [RFC2911] section 5.2.2).  Because the Printer
+   ignores the Subscription Attributes Group, it doesn't return them in
+   the response either, thus indicating to the client that the Printer
+   doesn't support Notification.
+
+   After completion of a successful Job Creation operation, the Printer
+   generates a 'job-created' event (see section 5.3.3.4.3).
+
+   Access Rights:  To create Per-Job Subscription Objects, the
+   authenticated user (see [RFC2911] section 8.3) performing this
+   operation MUST either have permission to create Jobs on the Printer
+   or have Operator or Administrator access rights for this Printer (see
+   [RFC2911] sections 1 and 8.5).  Otherwise the Printer MUST reject the
+   operation and return: the 'client-error-forbidden', 'client-error-
+   not-authenticated', or 'client-error-not-authorized' status code as
+   appropriate.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 56]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.1.3.1.  Job Creation Request
+
+   The groups for this operation are sufficiently different from the
+   Create-Job-Subscriptions operation that they are all presented here.
+   The following groups of attributes are supplied as part of a Job
+   Creation Request:
+
+   Group 1: Operation Attributes
+
+      Same as defined in [RFC2911] for Print-Job, Print-URI, and
+      Create-Job requests.
+
+   Group 2: Job Template Attributes
+
+      The client OPTIONALLY supplies a set of Job Template attributes as
+      defined in [RFC2911] section 4.2.
+
+   Group 3 to N: Subscription Template Attributes
+
+      The same as Group 2-N in Create-Job-Subscriptions.  See section
+      11.1.1.1.
+
+   Group N+1: Document Content  (Print-Job only)
+
+      The client MUST supply the document data to be processed.
+
+11.1.3.2.  Job Creation Response
+
+   The Printer MUST return to the client the following sets of
+   attributes as part of a Print-Job, Print-URI, and Create-Job
+   Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+
+         As defined in [RFC2911] for Print-Job, Print-URI, and Create-
+         Job requests.
+
+         In this group, the Printer can return any status codes defined
+         in [RFC2911] and section 12.  The following is a description of
+         the important status codes:
+
+         successful-ok: the Printer created the Job and all
+            Subscription Objects requested (see [RFC2911].
+
+         successful-ok-ignored-subscriptions: the Printer created
+            the Job and not all of the Subscription Objects requested
+
+
+
+Herriot & Hastings          Standards Track                    [Page 57]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+            (see section 12.1).  This status-code hides 'successful-ok-
+            xxx' status-codes that could reveal problems in Job
+            creation.  The Printer MUST NOT return the 'client-error-
+            ignored-all-subscriptions' status code for Job Creation
+            operations because the Printer returns an error status-code
+            only when it fails to create a Job.
+
+         Natural Language and Character Set:
+            The "attributes-charset" and "attributes-natural-language"
+            attributes as described in [RFC2911] section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.  This group does not contain any unsupported
+      Subscription Template Attributes; they are returned in the
+      Subscription Attributes Group (see below).
+
+   Group 3: Job Object Attributes
+
+      The "job-id" of the Job Object just created, etc., as defined in
+      [RFC2911] for Print-Job, Print-URI, and Create-Job requests.
+
+   Group 4 to N: Subscription Attributes
+
+      These groups MUST be returned if and only if the client supplied
+      Subscription Template Attributes and the operation was accepted.
+
+      See section 5.2 for details on the contents of each occurrence of
+      this group.
+
+11.2.  Other Operations
+
+   This section defines other operations on Subscription objects.
+
+11.2.1.  Restart-Job Operation - Extensions for Notification
+
+   The Restart-Job operation [RFC2911] is neither a Job Creation
+   operation nor a Subscription Creation operation (see section 3.2).
+
+   For the Restart-Job operation, the client MUST NOT supply any Job
+   Subscription Attributes Groups.  The Printer MUST treat any supplied
+   Job Subscription Attributes as unsupported attributes.
+
+   For this operation, the Printer does not return a job-id or any
+   Subscription Attributes groups because the Printer reuses the
+   existing Job object with the same job-id and the existing Per-Job
+   Subscription Objects with the same subscription-ids.  However, after
+
+
+
+Herriot & Hastings          Standards Track                    [Page 58]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   successful completion of this operation, the Printer generates a
+   'job-created' event (see section 5.3.3.4.3).
+
+11.2.2.  Validate-Job Operation - Extensions for Notification
+
+   A client can test whether one or more Subscription Objects could be
+   created using the Validate-Job operation.  The client supplies one or
+   more Subscription Template Attributes Groups (defined in section
+   5.3), just as in a Job Creation request.
+
+   A Printer MUST support this extension to this operation.
+
+   The Printer MUST accept requests that are identical to the Job
+   Creation request defined in section 11.1.3.1, except that the request
+   MUST NOT contain document data.
+
+   The Printer MUST return the same groups and attributes as the Print-
+   Job operation (section 11.1.3.1) with the following exceptions.  The
+   Printer MUST NOT return a Job Object Attributes Group because no Job
+   is created.  The Printer MUST NOT return the "notify-subscription-id"
+   attribute in any Subscription Attribute Group because no Subscription
+   Object is created.
+
+   If the Printer would succeed in creating a Subscription Object, the
+   corresponding Subscription Attributes Group either has no 'status-
+   code' attribute or a 'status-code' attribute with a value of
+   'successful-ok-too-many-events' or 'successful-ok-ignored-or-
+   substituted-attributes' (see sections 5.2 and 13).  The status-codes
+   have the same meaning as in Job Creation except the results state
+   what "would happen".
+
+   The Printer MUST validate Subscription Template Attributes Groups in
+   the same manner as the Job Creation operations.
+
+11.2.3.  Get-Printer-Attributes - Extensions for Notification
+
+   This operation is extended so that it returns Printer attributes
+   defined in this document.
+
+   A Printer MUST support this extension to this operation.
+
+   In addition to the requirements of [RFC2911] section 3.2.5, a Printer
+   MUST support the following additional values for the "requested-
+   attributes" Operation attribute in this operation and return such
+   attributes in the Printer Object Attributes group of its response.
+
+   1. Subscription Template Attributes: Each supported attribute in
+      column 2 of Table 1.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 59]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   2. New Printer Description Attributes: Each supported attribute in
+      section 6.
+
+   3. New Group Name: The 'subscription-template' group name, which
+      names all supported Subscription Template Attribute in column 2 of
+      Table 1.  This group name is also used in the Get-Subscription-
+      Attributes and Get-Subscriptions operation with an analogous
+      meaning.
+
+   4. Extended Group Name: The 'all' group name, which names all Printer
+      attributes according to [RFC2911] section 3.2.5.  In this
+      extension 'all' names all attributes specified in [RFC2911] plus
+      those named in items 1 and 2 of this list.
+
+11.2.4.  Get-Subscription-Attributes operation
+
+   This operation allows a client to request the values of the
+   attributes of a Subscription Object.
+
+   A Printer MUST support this operation.
+
+   This operation is almost identical to the Get-Job-Attributes
+   operation (see [RFC2911] section 3.3.4).  The only differences are
+   that the operation is directed at a Subscription Object rather than a
+   Job object, and the returned attribute group contains Subscription
+   Object attributes rather than Job object attributes.
+
+   Access Rights:  The authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) be the Subscription Object owner,
+   (2) have Operator or Administrator access rights for this Printer
+   (see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
+   the Printer's administrator-configured security policy to query the
+   Subscription Object for the target job.  Otherwise the Printer MUST
+   reject the operation and return: the 'client-error-forbidden',
+   'client-error-not-authenticated', or 'client-error-not-authorized'
+   status code as appropriate.  Furthermore, the Printer's security
+   policy MAY limit which attributes are returned, in a manner similar
+   to the Get-Job-Attributes operation (see [RFC2911] end of section
+   3.3.4.2).
+
+11.2.4.1.  Get-Subscription-Attributes Request
+
+   The following groups of attributes are part of the Get-Subscription-
+   Attributes request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+
+
+
+Herriot & Hastings          Standards Track                    [Page 60]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in section [RFC2911] 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.2.4.1.1.  "notify-subscription-id" (integer (1:MAX))
+
+   The client MUST supply this attribute.  The Printer MUST support this
+   attribute.  This attribute specifies the Subscription Object from
+   which the client is requesting attributes.  If the client omits this
+   attribute, the Printer MUST reject this request with the 'client-
+   error-bad-request' status code.
+
+11.2.4.1.2.  "requested-attributes" (1setOf keyword)
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  This attribute specifies the attributes of
+   the specified Subscription Object that the Printer MUST return in the
+   response.  Each value of this attribute is either an attribute name
+   (defined in sections 5.3 and 5.4) or an attribute group name.  The
+   attribute group names are:
+
+   -  'subscription-template': all attributes that are both defined in
+      section 5.3 and present on the specified Subscription Object
+      (column 1 of Table 1).
+
+   -  'subscription-description': all attributes that are both defined
+      in section 5.4 and present on the specified Subscription Object
+      (Table 2).
+
+   -  'all': all attributes that are present on the specified
+      Subscription Object.
+
+   A Printer MUST support all these group names.
+
+      If the client omits this attribute, the Printer MUST respond as if
+      this attribute had been supplied with a value of 'all'.
+
+11.2.4.2.  Get-Subscription-Attributes Response
+
+   The Printer returns the following sets of attributes as part of the
+   Get-Subscription-Attributes Response:
+
+
+
+Herriot & Hastings          Standards Track                    [Page 61]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.  The
+      "attributes-natural-language" MAY be the natural language of the
+      Subscription Object, rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 and section 3.2.5.2 for details on
+      returning Unsupported Attributes.
+
+      The response NEED NOT contain the "requested-attributes" operation
+      attribute with any supplied keyword values that were requested by
+      the client but are not supported by the IPP object.  If the
+      Printer object does return unsupported attributes referenced in
+      the "requested-attributes" operation attribute, the values of the
+      "requested-attributes" attribute returned MUST include only the
+      unsupported keywords that were requested by the client.  If the
+      client had requested a group name, such as 'all', the resulting
+      unsupported attributes returned MUST NOT include attribute keyword
+      names described in the standard but not supported by the
+      implementation.
+
+   Group 3: Subscription Attributes
+
+      This group contains a set of attributes with their current values.
+      Each attribute returned in this group:
+
+   a) MUST be specified by the "requested-attributes" attribute in the
+      request, AND
+
+   b) MUST be present on the specified Subscription Object AND
+
+   c) MUST  NOT be restricted by the security policy in force.  For
+      example, a Printer MAY prohibit a client who is not the creator of
+      a Subscription Object from seeing some or all of its attributes.
+      See [RFC2911] end of section 3.3.4.2 and section 8.
+
+      The Printer can return the attributes of the Subscription Object
+      in any order.  The client MUST accept the attributes in any order.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 62]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.2.5.  Get-Subscriptions operation
+
+   This operation allows a client to retrieve the values of attributes
+   of all Subscription Objects belonging to a Job or Printer.
+
+   A Printer MUST supported this operation.
+
+   This operation is similar to the Get-Subscription-Attributes
+   operation, except that this Get-Subscriptions operation returns
+   attributes from possibly more than one object.
+
+   This operation is similar to the Get-Jobs operation (see [RFC2911]
+   section 3.2.6), except that the operation returns Subscription
+   Objects rather than Job objects.
+
+   Access Rights:  To query Per-Job Subscription Objects of the
+   specified job (client supplied the "notify-job-id" operation
+   attribute - see section 11.2.5.1.1), the authenticated user (see
+   [RFC2911] section 8.3) performing this operation MUST (1) be the
+   Subscription Object owner, (2) have Operator or Administrator access
+   rights for this Printer (see [RFC2911] sections 1 and 8.5), or (3) be
+   otherwise authorized by the Printer's administrator-configured
+   security policy to query the Subscription Object for the target job.
+   To query Per-Printer Subscription Objects of the Printer (client
+   omits the "notify-job-id" operation attribute - see section
+   11.2.5.1.1), the authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) have Operator or Administrator
+   access rights for this Printer (see [RFC2911] sections 1 and 8.5), or
+   (2) be otherwise authorized by the Printer's administrator-configured
+   security policy to query Per-Printer Subscription Objects for the
+   target Printer.  Otherwise the Printer MUST reject the operation and
+   return: the 'client-error-forbidden', 'client-error-not-
+   authenticated', or 'client-error-not-authorized' status code as
+   appropriate.  Furthermore, the Printer's security policy MAY limit
+   which attributes are returned, in a manner similar to the Get-Jobs
+   and Get-Printer-Attributes operations (see [RFC2911] end of sections
+   3.2.6.2 and 3.2.5.2).
+
+11.2.5.1.  Get-Subscriptions Request
+
+   The following groups of attributes are part of the Get-Subscriptions
+   request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 63]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.2.5.1.1.  "notify-job-id" (integer(1:MAX))
+
+   If the client specifies this attribute, the Printer returns the
+   specified attributes of all Per-Job Subscription Objects associated
+   with the Job whose "job-id" attribute value equals the value of this
+   attribute.  If the client does not specify this attribute, the
+   Printer returns the specified attributes of all Per-Printer
+   Subscription Objects.  Note: there is no way to get all Per-Job
+
+   Subscriptions known to the Printer in a single operation.  A Get-Jobs
+   operation followed by a Get-Subscriptions operation for each Job will
+   return all Per-Job Subscriptions.
+
+11.2.5.1.2.  "limit" (integer(1:MAX))
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  It is an integer value that determines the
+   maximum number of Subscription Objects that a client will receive
+   from the Printer even if the "my-subscriptions" attribute constrains
+   which Subscription Objects are returned.  The limit is a "stateless
+   limit" in that if the value supplied by the client is 'N', then only
+   the first 'N' Subscription Objects are returned in the Get-
+   Subscriptions Response.  There is no mechanism to allow for the next
+   'M' Subscription Objects after the first 'N' Subscription Objects.
+   If the client does not supply this attribute, the Printer responds
+   with all applicable Subscription Objects.
+
+11.2.5.1.3.  "requested-attributes" (1setOf type2 keyword)
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  This attribute specifies the attributes of
+   the specified Subscription Objects that the Printer MUST return in
+   the response.  Each value of this attribute is either an attribute
+   name (defined in sections 5.3 and 5.4) or an attribute group name
+   (defined in section 11.2.4.1).  If the client omits this attribute,
+   the Printer MUST respond as if the client had supplied this attribute
+   with the one value: 'notify-subscription-id'.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 64]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.2.5.1.4.  "my-subscriptions" (boolean)
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  If the value is 'false', the Printer MUST
+   consider the Subscription Objects from all users as candidates.  If
+   the value is 'true', the Printer MUST return the Subscription Objects
+   created by the requesting user of this request.  If the client does
+   not supply this attribute, the Printer MUST respond as if the client
+   had supplied the attribute with a value of 'false'.  The means for
+   authenticating the requesting user and matching the Subscription
+   Objects is similar to that for Jobs which is described in [RFC2911]
+   section 8.
+
+11.2.5.2 Get-Subscriptions Response
+
+   The Printer returns the following sets of attributes as part of the
+   Get-Subscriptions Response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      Same as for Get-Subscription-Attributes.
+
+   Groups 3 to N: Subscription Attributes
+
+      The Printer responds with one Subscription Attributes Group for
+      each requested Subscription Object (see the "notify-job-id"
+      attribute in the Operation Attributes Group of this operation).
+
+      The Printer returns Subscription Objects in any order.
+
+      If the "limit" attribute is present in the Operation Attributes
+      group of the request, the number of Subscription Attributes Groups
+      in the response MUST NOT exceed the value of the "limit"
+      attribute.
+
+      It there are no Subscription Objects associated with the specified
+      Job or Printer, the Printer MUST return zero Subscription
+      Attributes Groups and it MUST NOT treat this case as an error,
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 65]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      i.e., the status-code MUST be 'successful-ok' unless something
+      else causes the status code to have some other value.
+
+      See the Group 3 response (Subscription Attributes Group) of the
+      Get-Subscription-Attributes operation (section 11.2.4.2) for the
+      attributes that a Printer returns in this group.
+
+11.2.6.  Renew-Subscription operation
+
+   This operation allows a client to request the Printer to extend the
+   lease on a Per-Printer Subscription Object.
+
+   The Printer MUST support this operation.
+
+   The Printer MUST accept this request for a Per-Printer Subscription
+   Object in any of the target Printer's states, i.e., 'idle',
+   'processing', or 'stopped', but MUST NOT change the Printer's
+   "printer-state" attribute.
+
+   The Printer MUST reject this request for a Per-Job Subscription
+   Object because it has no lease (see section 5.4.3).  The status code
+   returned MUST be 'client-error-not-possible'.
+
+   Access Rights: The authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) be the owner of the Per-Printer
+   Subscription Object, (2) have Operator or Administrator access rights
+   for the Printer (see [RFC2911] sections 1 and 8.5), or (3) be
+   otherwise authorized by the Printer's administrator-configured
+   security policy to renew Per-Printer Subscription Objects for the
+   target Printer.  Otherwise, the Printer MUST reject the operation and
+   return: the 'client-error-forbidden', 'client-error-not-
+   authenticated', or 'client-error-not-authorized' status code as
+   appropriate.
+
+11.2.6.1.  Renew-Subscription Request
+
+   The following groups of attributes are part of the Renew-Subscription
+   Request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 66]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Requesting User Name:
+      The "requesting-user-name" (name(MAX)) attribute SHOULD be
+      supplied by the client as described in [RFC2911] section 8.3.
+
+11.2.6.1.1.  "notify-subscription-id" (integer (1:MAX))
+
+   The client MUST supply this attribute.  The Printer MUST support this
+   attribute.  This attribute specifies the Per-Printer Subscription
+   Object whose lease the Printer MUST renew.  If the client omits this
+   attribute, the Printer MUST reject this request with the 'client-
+   error-bad-request' status code.
+
+   Group 2: Subscription Template Attributes
+
+11.2.6.1.2.  "notify-lease-duration" (integer(0:MAX))
+
+   The client MAY supply this attribute.  It indicates the number of
+   seconds to renew the lease for the specified Subscription Object.  A
+   value of 0 requests an infinite lease (which MAY require Operator
+   access rights).  If the client omits this attribute, the Printer MUST
+   use the value of the Printer's "notify-lease-duration-default"
+   attribute.  See section 5.3.8 for more details.
+
+11.2.6.2.  Renew-Subscription Response
+
+   The Printer returns the following sets of attributes as part of the
+   Renew-Subscription Response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+      The following are some of the status codes returned (see
+      [RFC2911]:
+
+         successful-ok: The operation successfully renewed the lease
+            on the Subscription Object for the requested duration.
+
+         successful-ok-ignored-or-substituted-attributes: The
+            operation successfully renewed the lease on the Subscription
+            Object for some duration other than the amount requested.
+
+         client-error-not-possible: The operation failed because the
+            "notify-subscription-id" Operation attribute identified a
+            Per-Job Subscription Object.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 67]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         client-error-not-found: The operation failed because the
+            "notify-subscription-id" Operation attribute identified a
+            non-existent Subscription Object.
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.  The
+      "attributes-natural-language" MAY be the natural language of the
+      Subscription Object, rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.
+
+   Group 3: Subscription Attributes
+
+      The Printer MUST return the following Subscription Attribute:
+
+11.2.6.2.1.  "notify-lease-duration" (integer(0:MAX))
+
+   The value of this attribute MUST be the number of seconds that the
+   Printer has granted for the lease of the Subscription Object (see
+   section 5.3.8 for details, such as the value of this attribute when
+   the Printer doesn't support the requested value).
+
+11.2.7.  Cancel-Subscription operation
+
+   This operation allows a client to delete a Subscription Object and
+   stop the Printer from delivering more Event Notifications.  Once
+   performed, there is no way to reference the Subscription Object.
+
+   A Printer MUST supported this operation.
+
+   The Printer MUST accept this request in any of the target Printer's
+   states, i.e., 'idle', 'processing', or 'stopped', but MUST NOT change
+   the Printer's "printer-state" attribute.
+
+   If the specified Subscription Object is a Per-Job Subscription
+   Object, the Printer MUST accept this request in any of the target
+   Job's states, but MUST NOT change the Job's "job-state" attribute or
+   affect the Job.
+
+   Note:  There is no way to change any attributes on a Subscription
+   Object, except the "notify-lease-duration" attribute (using the
+   Renew-Subscription operation).  In order to change other attributes,
+   a client performs a Subscription Creation Operation and Cancel-
+   Subscription operation on the old Subscription Object.  If the client
+
+
+
+Herriot & Hastings          Standards Track                    [Page 68]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   wants to avoid missing Event Notifications, it performs the
+   Subscription Creation Operation first.  If this order would create
+   too many Subscription Objects on the Printer, the client reverses the
+   order.
+
+   Access Rights: The authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) be the owner of the Subscription
+   Object, (2) have Operator or Administrator access rights for the
+   Printer (see [RFC2911] sections 1 and 8.5), or (3) be otherwise
+   authorized by the Printer's administrator-configured security policy
+   to cancel the target Subscription Object.  Otherwise, the Printer
+   MUST reject the operation and return: the 'client-error-forbidden',
+   'client-error-not-authenticated', or 'client-error-not-authorized'
+   status code as appropriate.
+
+11.2.7.1.  Cancel-Subscription Request
+
+   The following groups of attributes are part of the Cancel-
+   Subscription Request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.2.7.1.1.  "notify-subscription-id" (integer (1:MAX))
+
+   The client MUST supply this attribute.  The Printer MUST support this
+   attribute.  This attribute specifies the Subscription Object that the
+   Printer MUST cancel.  If the client omits this attribute, the Printer
+   MUST reject this request with the 'client-error-bad-request' status
+   code.
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 69]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.2.7.2.  Cancel-Subscription Response
+
+   The Printer returns the following sets of attributes as part of the
+   Cancel-Subscription Response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+         The following are some of the status codes returned (see
+         [RFC2911]:
+
+         successful-ok: The operation successfully canceled
+            (deleted) the Subscription Object.
+
+         client-error-not-found: The operation failed because the
+            "notify-subscription-id" Operation attribute identified a
+            non-existent Subscription Object.
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.  The
+      "attributes-natural-language" MAY be the natural language of the
+      Subscription Object, rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.
+
+12.  Status Codes
+
+   The following status codes are defined as extensions for Notification
+   and are returned as the value of the "status-code" parameter in the
+   Operation Attributes Group of a response (see [RFC2911] section
+   3.1.6.1).  Operations in this document can also return the status
+   codes defined in section 13 of [RFC2911].  The 'successful-ok' status
+   code is an example of such a status code.
+
+12.1.  successful-ok-ignored-subscriptions (0x0003)
+
+   The Subscription Creation Operation was unable to create all
+   requested Subscription Objects.
+
+   For a Create-Job-Subscriptions or Create-Printer-Subscriptions
+   operation, this status code means that the Printer created one or
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 70]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   more Subscription Objects, but not all requested Subscription
+   Objects.
+
+   For a Job Creation operation, this status code means that the Printer
+   created the Job along with zero or more Subscription Objects.  The
+   Printer returns this status code even if other job attributes are
+   unsupported or in conflict.  That is, if an IPP Printer finds a
+   warning that would allow it to return 'successful-ok-ignored-
+   subscriptions' and either 'successful-ok-ignored-or-substituted-
+   attributes' and/or 'successful-ok-conflicting-attributes', it MUST
+   return 'successful-ok-ignored-subscriptions'.
+
+12.2.  client-error-ignored-all-subscriptions (0x0414)
+
+   This status code is the same as 'successful-ok-ignored-subscriptions'
+   except that only the Create-Job-Subscriptions and Create-Printer-
+   Subscriptions operation return it.  They return this status code only
+   when the Printer creates zero Subscription Objects.
+
+13.  Status Codes in Subscription Attributes Groups
+
+   This section contains values of the "notify-status-code" (type2 enum)
+   attribute that the Printer returns in a Subscription Attributes Group
+   in a response when the corresponding Subscription Object:
+
+   1. is not created or
+
+   2. is created and some of the client-supplied attributes are not
+      supported.
+
+   The following sections are ordered in decreasing order of importance
+   of the status-codes.
+
+13.1.  client-error-uri-scheme-not-supported (0x040C)
+
+   This status code is defined in [RFC2911].  This document extends its
+   meaning and allows it to be in a Subscription Attributes Group of a
+   response.
+
+   The scheme of the client-supplied URI in a "notify-recipient-uri"
+   Subscription Template Attribute in a Subscription Creation Operation
+   is not supported.  See section 5.3.1.
+
+13.2.  client-error-attributes-or-values-not-supported (0x040B)
+
+   This status code is defined in [RFC2911].  This document extends its
+   meaning and allows it to be in a Subscription Attributes Group of a
+   response.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 71]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   The method of the client-supplied keyword in a "notify-pull-method"
+   Subscription Template Attribute in a Subscription Creation Operation
+   is not supported.  See section 5.3.2.
+
+13.3.  client-error-too-many-subscriptions (0x0415)
+
+   The number of Subscription Objects supported by the Printer would be
+   exceeded if this Subscription Object were created (see section 5.2).
+
+13.4.  successful-ok-too-many-events (0x0005)
+
+   The client supplied more Events in the "notify-events" operation
+   attribute of a Subscription Creation Operation than the Printer
+   supports, as indicated in its "notify-max-events-supported" Printer
+   attribute (see section 5.3.3).
+
+13.5.  successful-ok-ignored-or-substituted-attributes (0x0001)
+
+   This status code is defined in [RFC2911].  This document extends its
+   meaning to include unsupported Subscription Template Attributes and
+   it can appear in a Subscription Attributes Group.
+
+14.  Encodings of Additional Attribute Tags
+
+   This section assigns values to two attributes tags as extensions to
+   the encoding defined in [RFC2910]).
+
+   The "subscription-attributes-tag" delimits Subscription Template
+   Attributes Groups in requests and Subscription Attributes Groups in
+   responses.
+
+   The "event-notification-attributes-tag" delimits Event Notifications
+   in Delivery Methods that use an IPP-like encoding.
+
+   The following table specifies the values for the delimiter tags:
+
+      Tag Value (Hex)   Meaning
+
+      0x06              "subscription-attributes-tag"
+      0x07              "event-notification-attributes-tag"
+
+15.  Conformance Requirements
+
+   It is OPTIONAL for IPP clients and Printers to implement this Event
+   Notification specification.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 72]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+15.1.  Conformance requirements for clients
+
+   If this Event Notification specification is implemented by a client,
+   the client MUST support the 'ippget' Pull Delivery Method and meet
+   the conformance requirements as defined in [RFC3996] for clients.  A
+   client MAY support additional Delivery Methods.
+
+15.2.  Conformance requirements for Printers
+
+   If this Event Notification specification is implemented by a Printer,
+   the Printer MUST:
+
+   -  meet the Conformance Requirements detailed in section 5 of
+      [RFC2911].
+
+   -  support the Subscription Template Attributes Group in requests and
+      the Subscription Attributes Group in responses.
+
+   -  support all of the following attributes:
+
+      a. REQUIRED Subscription Object attributes in section 5.
+      b. REQUIRED Printer Description object attributes in section 6.
+      c. REQUIRED attributes in Event Notification content in section 8.
+
+   -  support the 'ippget' Pull Delivery Method and meet the conformance
+      requirements as defined in [RFC3996] for Printers.  The Printer
+      MAY support additional Push and Pull Delivery Methods.
+
+   -  deliver Event Notifications that conform to the requirements of
+      section 9 and the requirements of the Delivery Method Document for
+      each supported Delivery Method (the conformance requirements for
+      Delivery Method Documents is specified in section 10).
+
+   -  for all of the Job Creation Operations that the Printer supports,
+      MUST support the REQUIRED extensions for notification defined in
+      section 11.1.3.
+
+   -  meet the conformance requirements for operations as described in
+      Table 16 and meet the requirements for Printers as specified in
+      the indicated sub-sections of section 11:
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 73]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 16 - Printer Conformance Requirements for Operations
+
+   Operation                                         Printer
+                                                     Conformance
+                                                     Requirements
+
+   Create-Printer-Subscriptions (section 11.1.2)     REQUIRED
+   Create-Job-Subscriptions (section 11.1.1)         OPTIONAL
+   Get-Subscription-Attributes (section 11.2.3)      REQUIRED
+   Get-Subscriptions (section 11.2.5)                REQUIRED
+   Renew-Subscription (section 11.2.6)               REQUIRED
+   Cancel-Subscription (section 11.2.7)              REQUIRED
+
+16.  Model for Notification with Cascading Printers (Informative)
+
+   With this model (see Figure 2 below), there is an intervening Print
+   server between the human user and the output-device.  So the system
+   effectively has two Printer objects.  There are two cases to
+   consider.
+
+   1. When the Printer 1 (in the server) generates Events, the system
+      behaves like the client and Printer in Figure 1.  In this case,
+      Printer 1 delivers Event Notifications that are shown as Event
+      Notifications (A) of  Figure 2.
+
+   2. When the Printer 2 (in the output-device) generates Events, there
+      are two possible system configurations:
+
+      a) Printer 1 forwards the client-supplied Subscription Creation
+         Operations to the downstream Printer 2 and lets Printer 2
+         deliver the Event Notifications directly to the Notification
+         Recipients supplied by the Client (Event Notifications(C) in
+         the diagram).
+
+      b) Printer 1 performs the client-supplied Subscription Creation
+         Operations and also forwards the Subscription Creation
+         Operations to Printer 2 with the Notification Recipient changed
+         to be the Printer 1.  When an Event occurs in Printer 2,
+         Printer 2 delivers the Event Notification (B) to Notification
+         Recipient of Printer 1, which relays the received Event
+         Notification (B) to the client-supplied Notification Recipient
+         (as Event Notifications(A) in the diagram).  Note, when a
+         client performs a Subscription Creation Operation, Printer 1
+         need not forward the Subscription Creation Operation to Printer
+         2 if it would create a duplicate Subscription Object on Printer
+         2.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 74]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Note: when Printer 1 is forwarding Subscription Creation Operations
+   to Printer 2, it may request Printer 2 to create additional
+   Subscription Objects (called "piggy-backing").  Piggy-backing is
+   useful when:
+
+   -  Device A is configured to accept (IPP or non-IPP) requests from
+      other servers.
+
+   -  Server S wants to receive Job Events that the client didn't
+      request and Server S wants these Events for jobs it submits and
+      not for other jobs.
+
+                              server S                       device A
+                           +------------+                 +------------+
+                           |            |                 |            |
+   +--------+ Subscription | ###########|                 | ###########|
+   | client |--Creation ----># Printer #|  Subscription   | # Printer #|
+   +--------+  Operation   | # Object 1#|---Creation------|># Object 2#|
+                           | ###|#######|   Operation     | ####|#|####|
+                           +----|---^---+                 +-----|-|----+
+   +--------+     Event         |   |                           | |
+   |Notific-|<-Notifications(A)-+   +-- Event Notifications(B)--+ |
+   |ation Re|<-------------Event Notifications(C)-----------------+
+   |cipient |
+   +--------+
+
+         Figure 2 - Model for Notification with Cascading Printers
+
+17.  Distributed Model for Notification (Informative)
+
+   A Printer implementation could use some other remote notification
+   server to provide some or most of the service.  For example, the
+   remote notification server could deliver Event Notifications using
+   Delivery Methods that are not directly supported by the output device
+   or Printer object.  Or, the remote notification server could store
+   Subscription Objects (passed to it from the output device in response
+   to Subscription Creation requests), accept Events, format the Event
+   Notification in the natural language of the Notification Recipient,
+   and deliver the Event Notifications to the Notification Recipient(s).
+
+   Figure 3 shows this partitioning.  The interface between the output
+   device (or Printer object) and the remote notification server is
+   outside the scope of this document and is intended to be transparent
+   to the client and this document.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 75]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+                                            ***********************
+                                            *
+                                            * Printer in combination
+                                            * with the distributed
+                                            * Notification Server)
+                                            *
+                                            * output device or server
+                                            * +---------------+
+      PDA, desktop, or server               * +  ###########  +
+           +--------+                       * |  #         #  |
+           | client |---IPP Subscription--------># Printer #  |
+           +--------+   Creation operation  * |  # Object  #  |
+                                            * |  #####|#####  |
+                                            * +-------|-------+
+                                            *         | Subscriptions
+                                            *         | OR Event
+        +------------+                      *         | Notifications
+        |Notification|   IPP-defined        *  +------v--------+
+        |Recipient   |<--Event Notifications---| Notification  |
+        +------------+                      *  | Server        |
+                                            *  +---------------+
+                                            *
+                                            *************************
+   *** = Implementation configuration opaque boundary
+
+     Figure 3 - Opaque Use of a Notification Server Transparent to the
+                                  Client
+
+18.  Extended Notification Recipient (Informative)
+
+   The model allows for an extended Notification Recipient that is
+   itself a notification server that forwards each Event Notification to
+   another recipient (called the Ultimate Notification Recipient in this
+   section).  The Delivery Method to the Ultimate Recipient is probably
+   different from the Delivery Method used by the Printer to the
+   extended Notification Recipient.
+
+   This extended Notification Recipient is transparent to the Printer
+   but not to the client.
+
+   When a client performs a Subscription Creation Operation, it
+   specifies the extended Notification Recipient as it would any
+   Notification Recipient.  In addition, the client specifies the
+   Ultimate Notification Recipient in the Subscription Creation
+   Operation in a manner specified by the extended Notification
+   Recipient.  Typically, it is either some bytes in the value of
+   "notify-user-data" or some additional parameter in the value of
+   "notify-recipient-uri".  The client also subscribes directly with the
+
+
+
+Herriot & Hastings          Standards Track                    [Page 76]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   extended Notification Recipient (by means outside this document),
+   since it is a notification server in its own right.
+
+   The IPP Printer treats the extended Notification Recipient like any
+   other Notification Recipient and the IPP Printer is not aware of the
+   forwarding.  The Delivery Method that the extended Notification
+   Recipient uses for delivering the Event Notification to the Ultimate
+   Notification Recipient is beyond the scope of this document and is
+   transparent to the IPP Printer.
+
+   Examples of this extended Notification Recipient are paging,
+   immediate messaging services, general notification services, and NOS
+   vendors' infrastructure.  Figure 4 shows this approach.
+
+      PDA, desktop, or server                    server or output device
+                                                      +---------------+
+          +--------+                                  |  ###########  |
+          | client |---Subscription Creation -----------># Printer #  |
+          +--------+       Operation                  |  # Object  #  |
+                                                      |  #####|#####  |
+   +------------+     +------------+   IPP-defined    +-------|-------+
+   |Ultimate    | any |Notification|<--Event Notifications----+
+   |Notification|<----|Recipient   |
+   |Recipient   |     +------------+
+   +------------+     (Notification Server)
+
+    Figure 4 - Use of an Extended Notification Recipient transparent to
+                                the Printer
+
+19.  Object Model for Notification (Normative)
+
+   This section describes the Notification object model that adds a
+   Subscription Object which together with the Job and Printer object
+   provide the complete Notification semantics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 77]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   The object relationships can be seen pictorially as:
+
+   Subscription Objects (Per-Printer Subscriptions)     Printer object
+   +----+                                               +------------+
+   | s1 |<--------------------------------------------->|            |
+   +----++                                              |            |
+    | s2 |<-------------------------------------------->|     p1     |
+    +----++                                             |            |
+     | s3 |<------------------------------------------->|            |
+     +----+                                             +------------+
+                    Job objects
+                    +---------+
+                    |         |
+     +----+         |   j1    |
+     | s4 |<------->|         |
+     +----+         |         |
+                    |         |    s4 is a Per-Job Subscription Object
+                    ++--------++
+                     |         |
+       +----+        |   j2    |
+       | s5 |<------>|         |
+       +----++       |         |
+        | s6 |<----->|         |    s5 and s6 are Per-Job Subscription
+        +----+       ++--------++                  Objects
+                      |         |
+                      |   j3    |
+                      |         |
+                      |         |         <----> indicates association
+                      +---------+
+
+               Figure 5 - Object Model for Notification
+
+   s1, s2, and s3 are Per-Printer Subscription Objects and can identify
+   Printer and/or Job Events.
+
+   s4, s5, and s6 are Per-Job Subscription Objects and can identify
+   Printer and/or Job Events.
+
+19.1.  Object relationships
+
+   This sub-section defines the object relationships between the
+   Printer, Job, and Subscription Objects by example.  Whether Per-
+   Printer Subscription Objects are actually contained in a Printer
+   object or are just bi-directionally associated with them in some way
+   is IMPLEMENTATION DEPENDENT and is transparent to the client.
+   Similarly, whether Per-Job Subscription Objects are actually
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 78]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   contained in a Job object or are just bi-directionally associated
+   with them in some way is IMPLEMENTATION DEPENDENT and is transparent
+   to the client.  The object relationships are defined as follows:
+
+19.2.  Printer Object and Per-Printer Subscription Objects
+
+   1. The Printer object contains (is associated with) zero or more
+      Per-Printer Subscription Objects (p1 contains s1-s3 Per-Printer
+      Subscription Objects).
+
+   2. Each Per-Printer Subscription Object (s1, s2, and s3) is contained
+      in (or is associated with) exactly one Printer object (p1).
+
+19.3.  Job Object and Per-Job Subscription Objects
+
+   1. A Job object (j1, j2, j3) is associated with zero or more Per-Job
+      Subscription Objects (s4-s6).  Job j1 is associated with Per-Job
+      Subscription Object s4, Job j2 is associated with Per-Job
+      Subscription Objects s5 and s6, and Job j3 is not associated with
+      any Per-Job Subscription Object.
+
+   2. Each Per-Job Subscription Object is associated with exactly one
+      Job object.
+
+20.  Per-Job versus Per-Printer Subscription Objects (Normative)
+
+   Per-Job and Per-Printer Subscription Objects are quite similar.
+   Either type of Subscription Object can subscribe to Job Events,
+   Printer Events, or both.  Both types of Subscription Objects can be
+   queried using the Get-Subscriptions and Get-Subscription-Attributes
+   operations and canceled using the Cancel-Subscription operation.
+   Both types of Subscription Objects create Subscription Objects which
+   have the same Subscription Object attributes defined.  However, there
+   are some semantic differences between Per-Job Subscription Objects
+   and Per-Printer Subscription Objects.  A Per-Job Subscription Object
+   is established by the client when submitting a job and after creating
+   the job using the Create-Job-Subscriptions operation by specifying
+   the "job-id" of the Job with the "notify-job-id" attribute.  A Per-
+   Printer Subscription Object is established between a client and a
+   Printer using the Create-Printer-Subscriptions operation.  Some
+   specific differences are:
+
+   1. A client usually creates one or more Per-Job Subscription Objects
+      as part of the Job Creation operations (Create-Job, Print-Job, and
+      Print-URI), rather than using the OPTIONAL Create-Job-
+      Subscriptions operation, especially since Printer implementations
+      NEED NOT support the Create-Job-Subscriptions operation, since it
+      is OPTIONAL.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 79]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   2. For Per-Job Subscription Objects, the Subscription Object is only
+      valid while the job is "not-complete" (see sections 5.4.3) while
+      for the Per-Printer Subscription Objects, the Subscription Object
+      is valid until the time (in seconds) that the Printer returned in
+      the "notify-lease-expiration-time" operation attribute.
+
+   3. Job Events in a Per-Job Subscription Object apply only to "one
+      job" (the Job created by the Job Creation operation or references
+      by the Create-Job-Subscriptions operation) while Job Events in a
+      Per-Printer Subscription Object apply to ALL jobs contained in the
+      IPP Printer.
+
+21.  Normative References
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119 , March 1997.
+
+   [RFC2396]         Berners-Lee, T., Fielding, R., and L. Masinter,
+                     "Uniform Resource Identifiers (URI): Generic
+                     Syntax", RFC 2396, August 1998.
+
+   [RFC2717]         Petke, R. and I. King, "Registration Procedures for
+                     URL Scheme Names", RFC 2717, November 1999.
+
+   [RFC2910]         Herriot, R., Butler, S., Moore, P., and R. Turner,
+                     "Internet Printing Protocol/1.1: Encoding and
+                     Transport", RFC 2910, September 2000.
+
+   [RFC2911]         deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
+                     and P. Powell, "Internet Printing Protocol/1.1:
+                     Model and Semantics", RFC 2911, September 2000.
+
+   [RFC3381]         Hastings, T., Lewis, H., and R. Bergman, "IPP: Job
+                     Progress Attributes", RFC 3381,  September 2002.
+
+   [RFC3996]         Herriot, R., Hastings, T., and H. Lewis, "Internet
+                     Printing Protocol (IPP): The 'ippget' Delivery
+                     Method for Event Notifications", RFC 3996, March
+                     2005.
+
+22.  Informative References
+
+   [IANA-CON]        Narten, T. and H. Alvestrand, "Guidelines for
+                     Writing an IANA Considerations Section in RFCs",
+                     BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 80]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   [RFC2565]         Herriot, R., Butler, S., Moore, P., and R. Turner,
+                     "Internet Printing Protocol/1.0: Encoding and
+                     Transport", RFC 2565, April 1999.
+
+   [RFC2566]         deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
+                     and P. Powell, "Internet Printing Protocol/1.0:
+                     Model and Semantics", RFC 2566, April 1999.
+
+   [RFC2567]         Wright, D., "Design Goals for an Internet Printing
+                     Protocol", RFC 2567, April 1999.
+
+   [RFC2568]         Zilles, S., "Rationale for the Structure and Model
+                     and Protocol for the Internet Printing Protocol",
+                     RFC 2568, April 1999.
+
+   [RFC2569]         Herriot, R., Hastings, T., Jacobs, N., and J.
+                     Martin, "Mapping between LPD and IPP Protocols",
+                     RFC 2569, April 1999.
+
+   [RFC2616]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                     Masinter, L., Leach, P., and T. Berners-Lee,
+                     "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
+                     June 1999.
+
+   [RFC3196]         Hastings, T., Manros, C., Zehler, P., Kugler, C.,
+                     and H. Holst, "Internet Printing Protocol/1.1:
+                     Implementer's Guide", RFC 3196, November 2001.
+
+   [RFC3997]         Hastings, T., Editor, deBry, R., and H. Lewis,
+                     "Internet Printing Protocol (IPP): Requirements for
+                     IPP Notifications", RFC 3997, March 2005.
+
+23.  IANA Considerations
+
+   This section contains the registration information that IANA added to
+   the IPP Registry according to the procedures defined in RFC 2911
+   [RFC2911] section 6 to cover the definitions in this document.  In
+   addition, this section defines how Events and Delivery Methods will
+   be registered when they are defined in other documents.  The
+   resulting registrations have been published in the
+   http://www.iana.org/assignments/ipp-registrations registry.
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 81]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+23.1.  Attribute Registrations
+
+   The following table lists all the attributes defined in this
+   document.  These have been registered according to the procedures in
+   RFC 2911 [RFC2911] section 6.2.
+
+   Subscription Template attributes:                 Reference  Section
+   ---------------------------------                 ---------  -------
+   notify-attributes (1setOf type2 keyword)          [RFC3995]  5.3.4
+   notify-attributes-supported (1setOf type2 keyword)
+                                                     [RFC3995]  5.3.4.1
+   notify-charset (charset)                          [RFC3995]  5.3.6
+   notify-events (1setOf type2 keyword)              [RFC3995]  5.3.3
+   notify-events-default (1setOf type2 keyword)      [RFC3995]  5.3.3.1
+   notify-events-supported (1setOf type2 keyword)    [RFC3995]  5.3.3.2
+   notify-lease-duration (integer(0:67108863))       [RFC3995]  5.3.8
+   notify-lease-duration-default (integer(0:67108863))
+                                                     [RFC3995]  5.3.8.1
+   notify-lease-duration-supported (1setOf (integer(0: 67108863) |
+          rangeOfInteger(0:67108863)))               [RFC3995]  5.3.8.2
+   notify-max-events-supported (integer(2:MAX))      [RFC3995]  5.3.3.3
+   notify-natural-language (naturalLanguage)         [RFC3995]  5.3.7
+   notify-pull-method (type2 keyword)                [RFC3995]  5.3.2
+   notify-pull-method-supported (1setOf type2 keyword)
+                                                     [RFC3995]  5.3.2.1
+   notify-recipient-uri (uri)                        [RFC3995]  5.3.1
+   notify-schemes-supported  (1setOf uriScheme)      [RFC3995]  5.3.1.1
+   notify-time-interval (integer(0:MAX))             [RFC3995]  5.3.9
+   notify-user-data (octetString(63))                [RFC3995]  5.3.5
+
+   Subscription Description Attributes:
+   notify-job-id (integer(1:MAX))                    [RFC3995]  5.4.6
+   notify-lease-expiration-time (integer(0:MAX))     [RFC3995]  5.4.3
+   notify-printer-up-time (integer(1:MAX))           [RFC3995]  5.4.4
+   notify-printer-uri (uri)                          [RFC3995]  5.4.5
+   notify-sequence-number (integer (0:MAX))          [RFC3995]  5.4.2
+   notify-subscriber-user-name (name(MAX))           [RFC3995]  5.4.7
+   notify-subscription-id  (integer (1:MAX))         [RFC3995]  5.4.1
+
+   Printer Description Attributes:
+   printer-state-change-date-time (dateTime)         [RFC3995]  6.2
+   printer-state-change-time (integer(1:MAX))        [RFC3995]  6.1
+
+   Attributes Only in Event Notifications
+   notify-subscribed-event (type2 keyword)           [RFC3995]  8.1
+   notify-text (text(MAX))                           [RFC3995]  8.2
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 82]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+23.2.  Additional Enum Attribute Value Registrations within the IPP
+       registry
+
+   The following table lists all the new enum attribute values defined
+   in this document.  These have been registered within the IPP registry
+   according to the procedures in RFC 2911 [RFC2911] section 6.1.
+
+   Attribute
+     Value      Name                                 Reference   Section
+     ------     -----------------------------        ---------   -------
+   operations-supported (1setOf type2 enum)          [RFC2911]   4.4.15
+     0x0016     Create-Printer-Subscriptions         [RFC3995]   7.1
+     0x0017     Create-Job-Subscriptions             [RFC3995]   7.1
+     0x0018     Get-Subscription-Attributes          [RFC3995]   7.1
+     0x0019     Get-Subscriptions                    [RFC3995]   7.1
+     0x001A     Renew-Subscription                   [RFC3995]   7.1
+     0x001B     Cancel-Subscription                  [RFC3995]   7.1
+
+23.3.  Operation Registrations
+
+   The following table lists all of the operations defined in this
+   document.  These have been registered according to the procedures in
+   RFC 2911 [RFC2911] section 6.4.
+
+   Operation Name                                    Reference   Section
+   ---------------------------------                 ---------   -------
+   Cancel-Subscription                               [RFC3995]   11.2.7
+   Create-Job - Extensions                           [RFC3995]   11.1.3
+   Create-Job-Subscriptions                          [RFC3995]   11.1.1
+   Create-Printer-Subscriptions                      [RFC3995]   11.1.2
+   Get-Printer-Attributes - Extensions               [RFC3995]   11.2.3
+   Get-Subscription-Attributes                       [RFC3995]   11.2.4
+   Get-Subscriptions                                 [RFC3995]   11.2.5
+   Print-Job - Extensions                            [RFC3995]   11.1.3
+   Print-URI - Extensions                            [RFC3995]   11.1.3
+   Renew-Subscription                                [RFC3995]   11.2.6
+   Validate-Job Operation - Extensions               [RFC3995]   11.2.2
+
+23.4.  Status code Registrations
+
+   The following table lists all the status codes defined in this
+   document.  These have been registered according to the procedures in
+   RFC 2911 [RFC2911] section 6.6.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 83]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Value    Status Code Name                        Reference  Section
+   -----    ----------------------------            ---------  -------
+   0x0000:0x00FF - Successful:
+   0x0003   successful-ok-ignored-subscriptions     [RFC3995]  12.1
+   0x0005   successful-ok-too-many-events           [RFC3995]  13.4
+
+   0x0400:0x04FF - Client Error:
+   0x0414   client-error-ignored-all-subscriptions  [RFC3995]  12.2
+   0x0415   client-error-too-many-subscriptions     [RFC3995]  13.3
+
+23.5.  Attribute Group tag Registrations
+
+   The following table lists all the attribute group tags defined in
+   this document.  These have been registered according to the
+   procedures in RFC 2911 [RFC2911] section 6.5.
+
+   Value    Attribute Group Tag Name                 Reference  Section
+   -----    --------------------------------         --------   -------
+   0x06     subscription-attributes-tag              [RFC3995]  14
+   0x07     event-notification-attributes-tag        [RFC3995]  14
+
+23.6.  Registration of Events
+
+   The following table lists all the Events defined in this document as
+   type2 keywords to be used with the "notify-events", "notify-events-
+   default", and "notify-events-supported" Subscription Template
+   attributes (see section 5.3.3)).  Rather than creating a separate
+   section in the IPP Registry for Events, these event keywords have
+   been registered according to the procedures of [RFC2911] section 7.1
+   as additional keyword attribute values for use with the "notify-
+   events" Subscription Template attribute (see section 5.3.3), i.e.,
+   registered as keyword values for the "notify-events", "notify-
+   events-default", and "notify-events-supported" attributes:
+
+   Attribute (attribute syntax)
+     Value                                          Reference  Section
+     ---------------------                          ---------  -------
+   notify-events (1setOf type2 keyword)             [RFC3995]  5.3.3
+   notify-events-default (1setOf type2 keyword)     [RFC3995]  5.3.3.1
+   notify-events-supported (1setOf type2 keyword)   [RFC3995]  5.3.3.2
+   notify-subscribed-event (type2 keyword)          [RFC3995]  8.1
+     No Events:
+       none                                         [RFC3995]  5.3.3.4.1
+     Printer Events:
+       printer-state-changed                        [RFC3995]  5.3.3.4.2
+       printer-restarted                            [RFC3995]  5.3.3.4.2
+       printer-shutdown                             [RFC3995]  5.3.3.4.2
+       printer-stopped                              [RFC3995]  5.3.3.4.2
+
+
+
+Herriot & Hastings          Standards Track                    [Page 84]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+       printer-config-changed                       [RFC3995]  5.3.3.4.2
+       printer-media-changed                        [RFC3995]  5.3.3.4.2
+       printer-finishings-changed                   [RFC3995]  5.3.3.4.2
+       printer-queue-order-changed                  [RFC3995]  5.3.3.4.2
+     Job Events:
+       job-state-changed                            [RFC3995]  5.3.3.4.3
+       job-created                                  [RFC3995]  5.3.3.4.3
+       job-completed                                [RFC3995]  5.3.3.4.3
+       job-stopped                                  [RFC3995]  5.3.3.4.3
+       job-config-changed                           [RFC3995]  5.3.3.4.3
+       job-progress                                 [RFC3995]  5.3.3.4.3
+
+23.7.  Registration of Event Notification Delivery Methods
+
+   This section describes the requirements and procedures for
+   registration and publication of Event Notification Delivery Methods
+   and for the submission of such proposals.
+
+23.7.1.  Requirements for Registration of Event Notification Delivery
+         Methods
+
+   Registered IPP Event Notification Delivery Methods are expected to
+   follow a number of requirements described below.
+
+23.7.1.1.  Required Characteristics
+
+   A Delivery Method Document MUST either (1) contain all of the
+   semantics of the Delivery Method or (2) contain the IPP Delivery
+   Method registration requirements and a profile of some other protocol
+   that in combination is the Delivery Method (e.g., mailto).  The
+   Delivery Method Document (and any documents it requires) MUST define
+   either (1) a URL for a Push Delivery Method that the meets the
+   requirements of [RFC2717].  or (2) a keyword for a Pull Delivery
+   method.
+
+   IPP Event Notification Delivery Method Documents MUST meet the
+   requirements of this document (see sections 9 and 10).
+
+   In addition, a Delivery Method Document MUST contain the following
+   information:
+
+      Type of registration:  IPP Event Notification Delivery Method
+      Name of this delivery method:
+      Proposed URL scheme name of this Push Delivery Method or the
+      keyword name of this Pull Delivery Method:
+      Name of proposer:
+      Address of proposer:
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 85]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      Email address of proposer:
+      Is this delivery method REQUIRED or OPTIONAL for conformance to
+      the IPP Event Notification and Subscriptions document:
+      Is this delivery method defining Machine Consumable and/or Human
+      Consumable content:
+
+23.7.1.2.  Naming Requirements
+
+   Exactly one (URL scheme or keyword) name MUST be assigned to each
+   Delivery Method.
+
+   Each assigned name MUST uniquely identify a single Delivery Method.
+   All Push Delivery Method names MUST conform to the rules for URL
+   scheme names, according to [RFC2396] and [RFC2717] for schemes in the
+   IETF tree.  All Pull Delivery Method names MUST conform to the rules
+   for keywords according to [RFC2911].
+
+23.7.1.3.  Functionality Requirements
+
+   Delivery Methods MUST function as a protocol that is capable of
+   delivering (push or pull) IPP Event Notifications to Notification
+   Recipients.
+
+23.7.1.4.  Usage and Implementation Requirements
+
+   Use of a large number of Delivery Methods may hamper
+   interoperability.  However, the use of a large number of undocumented
+   and/or unlabeled Delivery Methods hampers interoperability even more.
+
+   A Delivery Method should therefore be registered ONLY if it adds
+   significant functionality that is valuable to a large community, OR
+   if it documents existing practice in a large community.  Note that
+   Delivery Methods registered for the second reason should be
+   explicitly marked as being of limited or specialized use and should
+   only be used with prior bilateral agreement.
+
+23.7.1.5.  Publication Requirements
+
+   Delivery Method Documents MUST be published in a standards track,
+   informational, or experimental RFCs.
+
+23.7.2.  Registration Procedure
+
+   The IPP WG is developing a small number of Delivery Methods which are
+   intended to be published as standards track RFCs.  However, some
+   parties may wish to register additional Delivery Methods in the
+   future.  This section describes the procedures for these additional
+   Delivery Methods.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 86]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+23.7.2.1.  Present the proposal to the Community
+
+   First the Delivery Method Document MUST be an Internet-Draft with a
+   target category of standards track, informational, or experimental.
+   The same MUST be true for any documents that it references.
+
+   Deliver the proposed Delivery Method Document proposal to the
+   "ipp@pwg.org" mailing list.  This mailing list has been established
+   by [RFC2911] for reviewing proposed registrations and discussing
+   other IPP matters.  Proposed Delivery Method Documents are not
+   formally registered and MUST NOT be used until approved.
+
+   The intent of the public posting is to solicit comments and feedback
+   on the definition and suitability of the Delivery Method and the name
+   chosen for it over a four week period.
+
+23.7.2.2.  Delivery Method Reviewer
+
+   The Delivery Method Reviewer is the same person who has been
+   appointed by the IETF Application Area Director(s) as the IPP
+   Designated Expert according to [RFC2911] and [IANA-CON].  When the
+   four week period is over and the IPP Designated Expert is convinced
+   that consensus has been achieved, the IPP Designated Expert either
+   approves the request for registration or rejects it.  Rejection may
+   occur because of significant objections raised on the list or
+   objections raised externally.
+
+   Decisions made by the Reviewer must be posted to the ipp@pwg.org
+   mailing list within 14 days.  Decisions made by the Reviewer may be
+   appealed to the IESG.
+
+23.7.2.3.  IANA Registration
+
+   Provided that the Delivery Method registration proposal has either
+   passed review or has been successfully appealed to the IESG, the IANA
+   will be notified by the delivery method reviewer and asked to
+   register the Delivery Method and make it available to the community.
+
+23.7.3.  Delivery Method Document Registrations
+
+   Each Push Delivery Method Document defines a URI scheme.  Such a URI
+   scheme is used in a URI value of the "notification-recipient" (uri)
+   Subscription Template attribute (see section 5.3.1) and the uriScheme
+   value of the "notify-schemes-supported" (1setOf uriScheme 5.3.1.1)
+   Printer attribute(see section ).  Rather than creating a separate
+   section in the IPP Registry for Delivery Methods, Push Delivery
+   Methods will be registered as an additional value of the "notify-
+   schemes-supported" Printer attribute.  These uriScheme values will be
+
+
+
+Herriot & Hastings          Standards Track                    [Page 87]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   registered according to the procedures of [RFC2911] section 7.1 for
+   additional attribute values.  Therefore, the IPP Registry entry for a
+   Push Delivery Method will be of the form:
+
+   Attribute
+     Value                                        Ref.       Section
+     ---------------------                        --------   -------
+   notify-schemes-supported (1setOf uriScheme)    [RFC3995]  5.3.1.1
+     <scheme name>                                RFC xxxx   m.n
+
+   Each Pull Delivery Method Document defines a keyword method which is
+   registered as an additional value of the "notify-pull-method" and
+   "notify-pull-method-supported" Printer attributes.  These keyword
+   values will be registered according to the procedures of [RFC2911]
+   section 7.1 for additional attribute values.  Therefore, the IPP
+   Registry entry for a Pull Delivery Method will be of the form:
+
+   Attribute
+     Value                                        Ref.       Section
+     ---------------------                        --------   -------
+   notify-pull-method (type2 keyword)             [RFC3995]  5.3.2
+   notify-pull-method-supported (1setOf type2 keyword)
+                                                  [RFC3995]  5.3.2.1
+     <method keyword name>                        RFC xxxx    m.n
+
+23.7.4.  Registration Template
+
+   To: ipp@pwg.org
+   Subject: Registration of a new Delivery Method
+
+   Delivery Method name:
+
+   (All Push Delivery Method names must be suitable for use as the value
+   of a URL scheme in the IETF tree and all Pull Delivery Method names
+   must be suitable IPP keywords according to [RFC2911])
+
+   Published specification(s):
+
+   (A specification for the Delivery Method must be openly available
+   that accurately describes what is being registered.)
+
+   Person & email address to contact for further information:
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 88]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+24.  Internationalization Considerations
+
+   This IPP Notification specification continues support for the
+   internationalization of [RFC2911] of attributes containing text
+   strings and names.  Allowing a Subscribing Client to specify a
+   different natural language and charset for each Subscription Object
+   increases the internationalization support.
+
+   The Printer MUST be able to localize the content of Human Consumable
+   Event Notifications and to localize the value of "notify-text"
+   attribute in Machine Consumable Event Notifications that it delivers
+   to Notification Recipients.  For localization, the Printer MUST use
+   the value of the "notify-charset" attribute and the "notify-natural-
+   language" attribute in the Subscription Object supplied by the
+   Subscribing Client.
+
+25.  Security Considerations
+
+   Clients submitting Notification requests to the IPP Printer have the
+   same security issues as submitting an IPP/1.1 print job request (see
+   [RFC2911] section 3.2.1 and section 8).  The same mechanisms used by
+   IPP/1.1 can therefore be used by the client Notification submission.
+   Operations that require authentication can use the HTTP
+   authentication.  Operations that require privacy can use the HTTP/TLS
+   privacy.  As with IPP/1.1 Print Job Objects, if there is no security
+   on Subscription Objects, sequential assignment of subscription-ids
+   exposes the system to a passive traffic monitoring threat.
+
+25.1.  Client access rights
+
+   The Subscription Object access control model is the same as the
+   access control model for Job objects.  The client MUST have the
+   following access rights for the indicated Subscription operations:
+
+   1. Create-Job-Subscriptions (see section 11.1.1):  A Per-Job
+      Subscription object is associated with a Job.  To create Per-Job
+      Subscription Objects, the authenticated user (see [RFC2911]
+      section 8.3) performing this operation MUST (1) be the job owner,
+      (2) have Operator or Administrator access rights for this Printer
+      (see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized
+      by the Printer's administrator-configured security policy to
+      create Per-Job Subscription Objects for the target job.
+
+   2. Create-Printer-Subscriptions (see section 11.1.2):  A Per-Printer
+      Subscription object is associated with the Printer.  To create
+      Per-Printer Subscription Objects, the authenticated user (see
+      [RFC2911] section 8.3) performing this operation MUST (1) have
+      Operator or Administrator access rights for this Printer (see
+
+
+
+Herriot & Hastings          Standards Track                    [Page 89]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      [RFC2911] sections 1 and 8.5) or (2) be otherwise authorized by
+      the Printer's administrator-configured security policy to create
+      Per-Printer Subscription Objects for this Printer.
+
+   3. Get-Subscription-Attributes (see section 11.2.4):  The access
+      control model for this operation is the same as that of the Get-
+      Job-Attributes operation (see [RFC2911] section 3.3.4).  The
+      primary difference is that a Get-Subscription-Attributes operation
+      is directed at a Subscription Object rather than at a Job object,
+      and a returned attribute group contains Subscription Object
+      attributes rather than Job object attributes.  To query the
+      specified Subscription Object, the authenticated user (see
+      [RFC2911] section 8.3) performing this operation MUST (1) be the
+      Subscription Object owner, (2) have Operator or Administrator
+      access rights for this Printer (see [RFC2911] sections 1 and 8.5),
+      or (3) be otherwise authorized by the Printer's administrator-
+      configured security policy to query the Subscription Object for
+      the target job.  Furthermore, the Printer's security policy MAY
+      limit which attributes are returned, in a manner similar to the
+      Get-Job-Attributes operation (see [RFC2911] end of section
+      3.3.4.2).
+
+   4. Get-Subscriptions (see section 11.2.5):  The access control model
+      for this operation is the same as that of the Get-Jobs operation
+      (see [RFC2911] section 3.2.6).  The primary difference is that the
+      operation is directed at Subscription Objects rather than at Job
+      objects, and the returned attribute groups contain Subscription
+      Object attributes rather than Job object attributes.  To query
+      Per-Job Subscription Objects of the specified job (client supplied
+      the "notify-job-id" operation attribute - see section 11.2.5.1.1),
+      the authenticated user (see [RFC2911] section 8.3) performing this
+      operation MUST (1) be the Subscription Object owner, (2) have
+      Operator or Administrator access rights for this Printer (see
+      [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
+      the Printer's administrator-configured security policy to query
+      the Subscription Object for the target job.  To query Per-Printer
+      Subscription Objects of the Printer (client omits the "notify-
+      job-id" operation attribute - see section 11.2.5.1.1), the
+      authenticated user (see [RFC2911] section 8.3) performing this
+      operation MUST (1) have Operator or Administrator access rights
+      for this Printer (see [RFC2911] sections 1 and 8.5), or (2) be
+      otherwise authorized by the Printer's administrator-configured
+      security policy to query Per-Printer Subscription Objects for the
+      target Printer.  Furthermore, the Printer's security policy MAY
+      limit which attributes are returned, in a manner similar to the
+      Get-Job-Attributes operation (see [RFC2911] end of section
+      3.2.6.2).
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 90]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   5. Renew-Subscriptions (see section 11.2.6):  The authenticated user
+      (see [RFC2911] section 8.3) performing this operation MUST (1) be
+      the owner of the Per-Printer Subscription Object, (2) have
+      Operator or Administrator access rights for the Printer (see
+      [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
+      the Printer's administrator-configured security policy to renew
+      Per-Printer Subscription Objects for the target Printer
+
+   6. Cancel-Subscription (see section 11.2.7):  The authenticated user
+      (see [RFC2911] section 8.3) performing this operation MUST (1) be
+      the owner of the Subscription Object, (2) have Operator or
+      Administrator access rights for the Printer (see [RFC2911]
+      sections 1 and 8.5), or (3) be otherwise authorized by the
+      Printer's administrator-configured security policy to cancel the
+      target Subscription Object.
+
+   The standard security concerns (delivery to the right user, privacy
+   of content, tamper proof content) apply to each Delivery Method.
+   Some Delivery Methods are more secure than others.  Each Delivery
+   Method Document MUST discuss its Security Considerations.
+
+25.2.  Printer security threats
+
+   Notification trap door:  If a Printer supports the OPTIONAL "notify-
+   attributes" Subscription Template attribute (see section 5.3.4) where
+   the client can request that the Printer return any specified Job,
+   Printer, and Subscription object attributes, the Printer MUST apply
+   the same security policy to these requested attributes in the Get-
+   Notifications request as it does for the Get-Jobs, Get-Job-
+   Attributes, Get-Printer-Attributes, and Get-Subscription-Attributes
+   requests.
+
+25.3.  Notification Recipient security threats
+
+   Unwanted Events Notifications (spam):  For any Push Delivery Method,
+   by far the biggest security concern is the abuse of notification:
+   delivering unwanted Event Notifications to third parties (i.e.,
+   spam).  The problem is made worse by notification addresses that may
+   be redistributed to multiple parties.  There exist scenarios where
+   third party notification is used (see Scenario #2 and #3 in
+   [RFC3997]).  Any fully secure solution would require active agreement
+   of all recipients before delivering anything.
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 91]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+26.  Description of the base IPP documents (Informative)
+
+   The base set of IPP documents includes:
+
+   Design Goals for an Internet Printing Protocol [RFC2567]
+   Rationale for the Structure and Model and Protocol for the Internet
+      Printing Protocol [RFC2568]
+   Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+   Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+   Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+   Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
+   operations have been added to IPP/1.1 [RFC2911, RFC2910].
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF IPP working group's major decisions.
+
+   The "Internet Printing Protocol/1.1: Model and Semantics" document
+   describes a simplified model with abstract objects, their attributes,
+   and their operations.  The model introduces a Printer and a Job.  The
+   Job supports multiple documents per Job.  The model document also
+   addresses how security, internationalization, and directory issues
+   are addressed.
+
+   The "Internet Printing Protocol/1.1: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1 [RFC2616].  It also defines the
+   encoding rules for a new Internet MIME media type called
+   "application/ipp".  This document also defines the rules for
+   transporting over HTTP a message body whose Content-Type is
+   "application/ipp".  This document defines the 'ipp' scheme for
+   identifying IPP printers and jobs.
+
+   The "Internet Printing Protocol/1.1: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.1 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+
+
+
+Herriot & Hastings          Standards Track                    [Page 92]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+27.  Contributors
+
+   The following people made significant contributions to the design and
+   review of this specification:
+
+   Scott A.  Isaacson
+   Novell, Inc.
+   122 E 1700 S
+   Provo, UT  84606
+
+   Phone: 801-861-7366
+   Fax:   801-861-2517
+   EMail: sisaacson@novell.com
+
+
+   Roger deBry
+   Utah Valley State College
+   Orem, UT 84058
+
+   Phone: 801-863-8848
+   EMail: debryro@uvsc.edu
+
+
+   Jay Martin
+   Underscore Inc.
+   9 Jacqueline St.
+   Hudson, NH 03051-5308
+
+   Phone: 603-889-7000
+   Fax:   775-414-0245
+   EMail: jkm@underscore.com
+
+
+   Michael Shepherd
+   Xerox Corporation
+   800 Phillips Road  MS 128-51E
+   Webster, NY  14450
+
+   Phone: 716-422-2338
+   Fax:   716-265-8871
+   EMail: mshepherd@usa.xerox.com
+
+
+
+Herriot & Hastings          Standards Track                    [Page 93]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Ron Bergman
+   Ricoh Printing Systems America
+   1757 Tapo Canyon Road
+   Simi Valley, CA 93063-3394
+
+   Phone: 805-578-4421
+   Fax:   805-578-4001
+   EMail: ron.bergman@rpsa.ricoh.com
+
+Authors' Addresses
+
+   Robert Herriot
+   Global Workflow Solutions
+   706 Colorado Ave.
+   Palo Alto, CA 94303
+
+   Phone:  650-324-4000
+   EMail:  bob@herriot.com
+
+
+   Tom Hastings
+   Xerox Corporation
+   701 S Aviation Blvd, ESAE 242
+   El Segundo, CA  90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-6342
+   EMail: hastings@cp10.es.xerox.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 94]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 95]
+
diff --git a/standards/rfc3996.txt b/standards/rfc3996.txt
new file mode 100644
index 000000000..c2a2a86d6
--- /dev/null
+++ b/standards/rfc3996.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                         R. Herriot
+Request for Comments: 3996                     Global Workflow Solutions
+Updates: 2911                                                T. Hastings
+Category: Standards Track                                    Xerox Corp.
+                                                                H. Lewis
+                                                               IBM Corp.
+                                                              March 2005
+
+
+                   Internet Printing Protocol (IPP):
+          The 'ippget' Delivery Method for Event Notifications
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes an extension to the Internet Printing
+   Protocol1.1: Model and Semantics (RFC 2911, RFC 2910).  This document
+   specifies the 'ippget' Pull Delivery Method for use with the
+   "Internet Printing Protocol (IPP): Event Notifications and
+   Subscriptions" specification (RFC 3995).  This IPPGET Delivery Method
+   is REQUIRED for all clients and Printers that support RFC 3995.  The
+   Notification Recipient, acting as a client, fetches (pulls) Event
+   Notifications by using the Get-Notifications operation defined in
+   this document.
+
+Table of Contents
+
+   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3
+        2.1.  Conformance Terminology . . . . . . . . . . . . . . . .  4
+        2.2.  Other Terminology . . . . . . . . . . . . . . . . . . .  4
+   3.   Model and Operation . . . . . . . . . . . . . . . . . . . . .  4
+   4.   General Information . . . . . . . . . . . . . . . . . . . . .  5
+   5.   Get-Notifications Operation . . . . . . . . . . . . . . . . .  7
+        5.1.  Get-Notifications Request . . . . . . . . . . . . . . .  8
+              5.1.1.  notify-subscription-ids (1setOf integer(1:MAX))  8
+              5.1.2.  notify-sequence-numbers (1setOf integer(1:MAX))  9
+
+
+
+Herriot, et al.             Standards Track                     [Page 1]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+              5.1.3.  notify-wait (boolean) . . . . . . . . . . . . . 10
+        5.2.  Get-Notifications Response. . . . . . . . . . . . . . . 10
+              5.2.1.  notify-get-interval (integer(0:MAX)). . . . . . 13
+              5.2.2.  printer-up-time (integer(1:MAX)). . . . . . . . 14
+   6.   Additional Information about Subscription Template Attributes 17
+        6.1.  notify-pull-method (type2 keyword). . . . . . . . . . . 17
+   7.   Subscription Description Attributes . . . . . . . . . . . . . 18
+   8.   Additional Printer Description Attributes . . . . . . . . . . 18
+        8.1.  ippget-event-life (integer(15:MAX)) . . . . . . . . . . 18
+   9.   New Values for Existing Printer Description Attributes. . . . 19
+        9.1.  notify-pull-method-supported (1setOf type2 keyword) . . 19
+        9.2.  operations-supported (1setOf type2 enum). . . . . . . . 19
+   10.  New Status Codes. . . . . . . . . . . . . . . . . . . . . . . 19
+        10.1.  successful-ok-events-complete (0x0007) . . . . . . . . 20
+   11.  Encoding and Transport. . . . . . . . . . . . . . . . . . . . 20
+   12.  Conformance Requirements. . . . . . . . . . . . . . . . . . . 21
+        12.1.  Conformance for IPP Printers . . . . . . . . . . . . . 21
+        12.2.  Conformance for IPP Clients. . . . . . . . . . . . . . 22
+   13.  Normative References. . . . . . . . . . . . . . . . . . . . . 23
+   14.  Informative References. . . . . . . . . . . . . . . . . . . . 23
+   15.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
+        15.1.  Attribute Registrations. . . . . . . . . . . . . . . . 24
+        15.2.  Delivery Method and Additional Keyword Attribute Value
+               registrations for Existing Attributes. . . . . . . . . 24
+        15.3.  Additional Enum Attribute Values . . . . . . . . . . . 25
+        15.4.  Operation Registrations. . . . . . . . . . . . . . . . 25
+        15.5.  Status Code Registrations. . . . . . . . . . . . . . . 25
+   16.  Internationalization Considerations . . . . . . . . . . . . . 25
+   17.  Security Considerations . . . . . . . . . . . . . . . . . . . 26
+        17.1.  Notification Recipient Client Access Rights. . . . . . 26
+        17.2.  Printer Security Threats . . . . . . . . . . . . . . . 27
+        17.3.  Notification Recipient Security Threats. . . . . . . . 27
+        17.4.  Security Requirements for Printers . . . . . . . . . . 27
+        17.5.  Security Requirements for clients. . . . . . . . . . . 28
+   18.  Description of Base IPP Documents (Informative) . . . . . . . 28
+   19.  Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 29
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 31
+
+Table of Tables
+
+   Table 1.  Information about the Delivery Method. . . . . . . . . .  5
+   Table 2.  Combinations of "notify-wait", "status-code", and
+             "notify-get-interval". . . . . . . . . . . . . . . . . . 13
+   Table 3.  Attributes in Event Notification Content . . . . . . . . 15
+   Table 4.  Additional Attributes in Event Notification Content for
+             Job Events . . . . . . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 2]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Table 5.  Combinations of Events and Subscribed Events for "job-
+             impressions-completed" . . . . . . . . . . . . . . . . . 17
+   Table 6.  Additional Attributes in Event Notification Content for
+             Printer Events . . . . . . . . . . . . . . . . . . . . . 17
+   Table 7.  Operation-id Assignments . . . . . . . . . . . . . . . . 19
+   Table 8.  The "event-notification-attributes-tag" Value. . . . . . 21
+
+1.  Introduction
+
+   This document describes an extension to the Internet Printing
+   Protocol/1.1: Model and Semantics [RFC 2911], [RFC 2910].  This
+   document specifies the 'ippget' Pull Delivery Method for use with the
+   "Internet Printing Protocol (IPP): Event Notifications and
+   Subscriptions" specification [RFC3995].  This IPPGET Delivery Method
+   is REQUIRED for all clients and Printers that support [RFC3995].  The
+   Notification Recipient, acting as a client, fetches (pulls) Event
+   Notifications by using the Get-Notifications operation defined in
+   this document.  For a description of the base IPP documents, see
+   section 21 of this document.  For a description of the IPP Event
+   Notification Model, see [RFC3995].
+
+   With this Pull Delivery Method, when an Event occurs, the Printer
+   saves the Event Notification for a period of time called the Event
+   Life.  The Notification Recipient fetches (pulls) the Event
+   Notifications by using the Get-Notifications operation.  This
+   operation causes the Printer to return all Event Notifications held
+   for the specified Subscription object(s).  If the Notification
+   Recipient has selected the Event Wait Mode option to wait for
+   additional Event Notifications, the Printer MAY continue to return
+   Event Notifications to the Notification Recipient as asynchronous
+   Get-Notification responses as Events occur using the transaction
+   originated by the Notification Recipient.
+
+   The Notification Recipient can terminate Event Wait Mode (without
+   closing the connection) by supplying the "notify-wait" (boolean)
+   attribute with a 'false' value in a subsequent Get-Notifications
+   request.  Similarly, the Printer can terminate Event Wait Mode
+   (without closing the connection) by returning the "notify-get-
+   interval" (integer) operation attribute in a Get-Notifications
+   response that tells the Notification Recipient how long to wait
+   before trying again.
+
+2.  Terminology
+
+   This section defines the following terms that are used throughout
+   this document:
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 3]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+2.1.  Conformance Terminology
+
+   Capitalized terms such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+   NOT, MAY, NEED NOT, and OPTIONAL have special meaning relating to
+   conformance as defined in [RFC2119] and [RFC2911], section 12.1.  If
+   an implementation supports the extension defined in this document,
+   then these terms apply; otherwise, they do not.  These terms define
+   conformance to this document only; they do not affect conformance to
+   other documents, unless it is explicitly stated otherwise.
+
+2.2.  Other terminology
+
+   This document uses the same terminology as [RFC2911], including
+   "client", "Printer", "Job", "attribute", "attribute value",
+   "keyword", "operation", "request", "response", and "support", with
+   the same meanings.  This document also uses terminology defined in
+   [RFC3995], such as "Subscription (object)", "Notification Recipient",
+   "Event", "Event Notification", "Compound Event Notification", "Event
+   Life", and "Event Notification Attribute Group", with the same
+   meanings.  In addition, this document defines the following terms for
+   use in this document:
+
+   Event Wait Mode: The mode requested by a Notification Recipient
+       client in its Get-Notifications Request and granted by a Printer
+       to keep the connection open while the Printer sends subsequent
+       Get-Notification operation responses to the Notification
+       Recipient in the form of Event Notifications as they occur.
+
+3.  Model and Operation
+
+   In a Subscription Creation Operation, when the "notify-pull-method"
+   attribute is present and has the "ippget" keyword value, the client
+   is requesting that the Printer use the "ippget" Pull Delivery Method
+   for the Event Notifications associated with the new Subscription
+   Object.
+
+   When an Event occurs, the Printer MUST generate an Event Notification
+   and MUST assign it the Event Life.  The Printer MUST hold an Event
+   Notification for its assigned Event Life.
+
+   When a Notification Recipient wants to receive Event Notifications
+   for a Subscription object, it performs the Get-Notifications
+   operation supplying the Subscription object's subscription-id, which
+   causes the Printer to return all un-expired Event Notifications held
+   for that Subscription object.  If the Notification Recipient has
+   selected the Event Wait Mode option to wait for additional Event
+   Notifications, the response to the Get-Notifications request
+   continues indefinitely as the Printer continues to send Event
+
+
+
+Herriot, et al.             Standards Track                     [Page 4]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Notifications in the response as Events occur for that Subscription
+   object.
+
+   When the Notification Recipient requests Event Notifications for
+   Per-Job Subscription Objects, the Notification Recipient typically
+   performs the Get-Notifications operation within a second of
+   performing the Subscription Creation operation.  Because the Printer
+   MUST save Event Notifications for at least 15 seconds (see section
+   8.1), the Notification Recipient is unlikely to miss any Event
+   Notifications that occur between the Subscription Creation and the
+   Get-Notifications operation.
+
+   The 'ippget' Delivery Method is designed primarily for (1) a client
+   that wants to get Events (from the job's Per-Job Subscription object)
+   for a job that it has submitted and (2) a privileged client that
+   wants to get all job or printer Events from a Per-Printer
+   Subscription object.
+
+4.  General Information
+
+   If a Printer supports this Delivery Method, the following are its
+   characteristics.
+
+              Table 1.  Information about the Delivery Method
+
+   Document Method Conformance Requirement    Delivery Method
+   Realization
+
+   1.  What is the URL scheme name for the     'ippget' keyword method
+       Push Delivery Method, or the keyword     name
+       method name for the Pull Delivery
+       Method?
+
+   2.  Is the Delivery Method REQUIRED,        REQUIRED
+       RECOMMENDED, or OPTIONAL for an IPP
+       Printer to support?
+
+   3.  What transport and delivery protocols   IPP with one new
+       does the Printer use to deliver the     operation.
+       Event Notification Content; i.e.,
+       what is the entire network stack?
+
+   4.  Can several Event Notifications be      Yes.
+       combined into a Compound Event
+       Notification?
+
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 5]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   5.  Is the Delivery Method initiated by     This Delivery Method is
+       the Notification Recipient (pull),      a pull method with
+       or by the Printer (push)?               aspects of a push
+                                               method, though the
+                                               Printer does not
+                                               initiate the operation.
+
+   6.  Is the Event Notification content       Machine Consumable.
+       Machine Consumable or Human
+       Consumable?
+
+   7.  What section in this document answers   Section 5.
+       the following questions? For a Machine
+       Consumable Event Notification, what is
+       the representation and encoding of
+       values defined in section 9.1 of
+       [RFC3995], and what are the
+       conformance requirements thereof? For
+       a Human Consumable Event Notification,
+       what is the representation and
+       encoding of pieces of information
+       defined in section 9.2 of
+       [RFC3995], and the conformance
+       requirements thereof?
+
+   8.  What are the latency and reliability    Same as IPP and the
+       of the transport and delivery           underlying HTTP
+       protocol?                               transport.
+
+   9.  What are the security aspects of the    Same as IPP and the
+       transport and delivery protocol;        underlying HTTP
+       e.g., how it is handled in              transport and in the
+       firewalls?                              same direction, so no
+                                               new firewall
+                                               considerations.
+
+   10. What are the content length             None.
+       restrictions?
+
+   11. What are the additional values or       None.
+       pieces of information that a Printer
+       sends in an Event Notification content
+       and the conformance requirements
+       thereof?
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 6]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   12. What are the additional Subscription    None.
+       Template and/or Subscription
+       Description attributes and the
+       conformance requirements thereof?
+
+   13. What are the additional Printer         "ipp-event-life"
+       Description attributes and the          (integer (15: MAX))
+       conformance requirements thereof?
+
+5.  Get-Notifications Operation
+
+   This operation is issued by a client acting in the role of a
+   Notification Recipient requesting the Printer to return all Event
+   Notifications held for the identified Subscription object(s).
+
+   A Printer MUST support this operation, MUST accept the request in any
+   state (see [RFC2911] "printer-state" and "printer-state-reasons"
+   attributes), and MUST remain in the same state with the same
+   "printer-state-reasons" values.
+
+   When a Printer performs this operation, it MUST return all and only
+   those Event Notifications
+
+   1.  whose associated Subscription Object's "notify-subscription-id"
+       Subscription Description attribute equals one of the values of
+       the "notify-subscription-ids" (1setOf integer(1:MAX)) operation
+       attribute AND
+
+   2.  whose associated Subscription Object contains the "notify-pull-
+       method" attribute and it has the 'ippget' keyword value, AND
+
+   3.  whose "notify-sequence-number" is equal to or greater than the
+       corresponding value of the "notify-sequence-numbers" (1setOf
+       integer(1:MAX)) operation attribute if supplied AND
+
+   4.  whose Event Life has not yet expired AND
+
+   5.  where the Notification Recipient client has read-access rights to
+       the identified Subscription Object (see Access Rights paragraph
+       below).
+
+   The Notification Recipient client MUST either (a) request Event Wait
+   Mode by supplying the "notify-wait" operation attribute with a 'true'
+   value or (b) suppress Event Wait Mode by omitting the "notify-wait"
+   operation attribute or by supplying it with a 'false' value.  To
+   terminate Event Wait Mode subsequently, the Notification Recipient
+   client MUST close the connection.  To terminate Event Wait Mode, the
+   Printer MUST either (a) return the "notify-get-interval" operation
+
+
+
+Herriot, et al.             Standards Track                     [Page 7]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   attribute in a Get-Notifications response (RECOMMENDED behavior) or
+   (b) close the connection.  The "notify-get-interval" operation
+   attributes tell the Notification Recipient how long to wait before
+   trying a subsequent Get-Notifications request.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation MUST be (1) the owner of each Subscription
+   Object identified by the "notify-subscription-ids" operation
+   attribute (see section 5.1.1), (2) an operator or administrator of
+   the Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise
+   authorized by the Printer's administrator-configured security policy
+   to request Event Notifications from the target Subscription
+   Object(s).  Otherwise, the IPP Printer MUST reject the operation and
+   return: 'client-error-forbidden', 'client-error-not-authenticated',
+   or 'client-error-not-authorized' status code, as appropriate.
+   Furthermore, the Printer's security policy MAY limit the attributes
+   returned by the Get-Notifications operation, in a manner similar to
+   that of the Get-Job-Attributes operation (see [RFC2911], end of
+   section 3.3.4.2).
+
+5.1.  Get-Notifications Request
+
+   The following groups of attributes are part of the Get-Notifications
+   Request:
+
+   Group 1: Operation Attributes
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes, as described in [RFC2911], section 3.1.4.1.
+
+      Target:
+         The "printer-uri" (uri) operation attribute that is the target
+         for this operation as described in [RFC2911], section 3.1.5.
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client as described in [RFC2911], section 8.3.
+
+5.1.1.  notify-subscription-ids (1setOf integer(1:MAX))
+
+   This attribute identifies one or more Subscription objects for which
+   Events are requested.  The client MUST supply this attribute with at
+   least one value.  The Printer object MUST support this attribute with
+   multiple values.
+
+   If no Subscription Object exists with the supplied identifier, or if
+   the identified Subscription Object does not contain the "notify-
+
+
+
+Herriot, et al.             Standards Track                     [Page 8]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   pull-method" attribute with the 'ippget' keyword value, the Printer
+   MUST return the 'client-error-not-found' status code.
+
+         Note:  The name of both the "notify-subscription-ids" and
+         "notify-sequence-numbers" end in 's', as they are multi-valued.
+         However, there are other occurrences of these attribute names
+         without the 's' that are single valued.
+
+5.1.2.  notify-sequence-numbers (1setOf integer(1:MAX))
+
+   This attribute specifies one or more of the lowest Event Notification
+   sequence number values for the Subscription objects identified by the
+   corresponding values of the "notify-subscription-ids" operation
+   attribute.  The Notification Recipient SHOULD supply this attribute,
+   and the number of values SHOULD be the same as that of the "notify-
+   subscriptions-ids" attribute.  The Printer MUST support this
+   attribute with multiple values.
+
+   The Printer MUST NOT return Notification Events with lower sequence
+   numbers for the corresponding Subscription object.  Therefore, by
+   supplying the proper values for this attribute the Notification
+   Recipient can prevent getting the same Event Notifications from a
+   Subscription object that were returned on a previous Get-
+   Notifications request.  The Notification Recipient SHOULD remember
+   the highest "notify-sequence-number" value returned for each
+   Subscription object requested and SHOULD pass that value for each
+   requested Subscription object on the next Get-Notifications request.
+
+   If the Notification Recipient supplies fewer values for this
+   attribute (including omitting this attribute) than it does for the
+   "notify-subscription-ids" operation attribute, the Printer assumes a
+   '1' value for each missing value.  A value of '1' causes the Printer
+   to return any un-expired Event Notification for that Subscription
+   object, as '1' is the lowest possible sequence number.  If the
+   Notification Recipient supplies more values for this attribute than
+   the number of values for the "notify-subscription-ids" operation
+   attribute, the Printer ignores the extra values.
+
+   Note: If a Notification Recipient performs two consecutive Get-
+   Notifications operations with the same value for "notify-sequence-
+   number" (or omits the attribute), the time stamp value of the first
+   Event Notification in the second Get-Notifications Response may be
+   less than that of the time stamp of the last Event Notification in
+   the first Get-Notification Response.  This happens because the
+   Printer sends all unexpired Event Notifications with an equal or
+   higher sequence number according to the ordering specified in
+   [RFC3995], and some Event Notifications from the first Get-
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 9]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Notifications operation may not have expired by the time the second
+   Get-Notifications operation occurs.
+
+5.1.3.  notify-wait (boolean)
+
+   This value indicates whether the Notification Recipient wants Event
+   Wait Mode.  The client MAY supply this attribute.  The Printer object
+   MUST support both values of this attribute.
+
+   If the client supplies the 'false' value or omits this attribute, the
+   client is not requesting Event Wait Mode.  If the value is 'true',
+   the client is requesting Event Wait Mode.  See the beginning of
+   section 5.2 for the rules for Event Wait Mode.
+
+5.2.  Get-Notifications Response
+
+   The Printer has the following options for responding to a Get-
+   Notifications Request:
+
+   1.  The Printer can reject the request and return the 'server-error-
+       busy' status code if the Printer is too busy to accept this
+       operation at this time.  In this case, the Printer MUST return
+       the "get-notify-interval" operation attribute to indicate when
+       the client SHOULD try again.
+
+   2.  If the Notification Recipient did not request Event Wait Mode
+       ("notify-wait-mode" = 'false' or omitted), the Printer MUST
+       immediately return whatever Event Notifications it currently
+       holds in the requested Subscription object(s) and MUST return the
+       "notify-get-interval" operation attribute with the number of
+       seconds from now, at which the Notification Recipient SHOULD
+       repeat the Get-Notifications Request to get future Event
+       Notifications.
+
+   3.  If the Notification Recipient requested Event Wait Mode
+       ("notify-wait-mode" = 'true'), the Printer MUST immediately
+       return whatever Event Notifications it currently holds in the
+       requested Subscription object(s) and MUST continue to return
+       Event Notifications as they occur until all the requested
+       Subscription Objects are canceled.  A Subscription Object is
+       canceled either via the Cancel-Subscription operation or by the
+       Printer (e.g., the Subscription Object is canceled when the
+       associated Job completes and is no longer in the Job Retention or
+       Job History phase; see the "ippget-event-life (integer(15:MAX))"
+       attribute discussion in section 8.1).
+
+       However, the Printer MAY decide to terminate Event Wait Mode at
+       any time, including in the first response.  In this case, the
+
+
+
+Herriot, et al.             Standards Track                    [Page 10]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+       Printer MUST return the "notify-get-interval" operation
+       attribute.  This attribute indicates that the Printer wishes to
+       leave Event Wait Mode and the number of seconds in the future
+       that the Notification Recipient SHOULD try the Get-Notifications
+       operation again.  The Notification Recipient MUST accept this
+       response and MUST disconnect.  If the Notification Recipient does
+       not disconnect, the Printer SHOULD do so.
+
+   From the Notification Recipient's view, the response appears as an
+   initial burst of data, which includes the Operation Attributes Group
+   and one Event Notification Attributes Group per Event Notification
+   that the Printer is holding.  After the initial burst of data, if the
+   Notification Recipient has selected the Event Wait Mode option to
+   wait for additional Event Notifications, the Notification Recipient
+   receives occasional Event Notification Attribute Groups.  Proxy
+   servers may delay some Event Notifications or cause time-outs to
+   occur.  The client MUST be prepared to perform the Get-Notifications
+   operation again when time-outs occur.
+
+   Each attribute is encoded by using the IPP rules for encoding
+   attributes [RFC2910] and MAY be encoded in any order.  Note:  the
+   Get-Jobs response in [RFC2911] acts as a model for encoding multiple
+   groups of attributes.  See section 11 for the encoding and transport
+   rules.
+
+   The following groups of attributes are part of the Get-Notifications
+   Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:  In addition to the REQUIRED status code returned
+         in every response, the response OPTIONALLY includes a "status-
+         message" (text(255)) and/or a "detailed-status-message"
+         (text(MAX)) operation attribute, as described in [RFC2911],
+         sections 13 and 3.1.6.
+
+         The Printer can return any status codes defined in [RFC2911].
+         If the status code is not 'successful-xxx', the Printer MUST
+         NOT return any Event Notification Attribute groups.  The
+         following are descriptions of the important status codes:
+
+            successful-ok: The response contains all Event Notification
+               associated with the specified subscription-ids that had
+               been supplied in the "notify-subscription-ids" operation
+               attribute in the request.  If the requested Subscription
+               Objects have no associated Event Notification, the
+               response MUST contain zero Event Notifications.
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 11]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+            successful-ok-events-complete:  Indicates when this return
+               is the last return for all Subscription objects that
+               match the request, whether or not Event Notifications are
+               returned.  This condition occurs for Event Wait Mode with
+               Notification Recipients waiting for responses when (1)
+               the Subscription Object is canceled with a Cancel-
+               Subscription operation, (2) the Subscription Object is
+               deleted, when the Per-Printer Subscription lease time
+               expires, or (3) the 'job-completed' event occurs for a
+               Per-Job Subscription.  This condition also occurs for a
+               Get-Notifications request that a Notification Recipient
+               makes after the job completes, but before the Event Life
+               expires.  See section 10.1.
+            client-error-not-found: The Printer has no Subscription
+               Objects whose "notify-subscription-id" attribute equals
+               any of the values of the "notify-subscription-ids"
+               operation attribute supplied, or the identified
+               Subscription Object does not contain the "notify-pull-
+               method" attribute with the 'ippget' keyword value.
+            server-error-busy: The Printer is too busy to accept this
+               operation.  The Printer SHOULD return the "notify-get-
+               interval" operation attribute in the Operation Attributes
+               of the response; then the Notification Recipient SHOULD
+               wait for the number of seconds specified by the "notify-
+               get-interval" operation attribute before performing this
+               operation again.  If the "notify-get-interval" Operation
+               Attribute is not present, the Notification Recipient
+               SHOULD use the normal network back-off algorithms to
+               determine when to perform this operation again.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes, as described in [RFC2911], section 3.1.4.2.
+
+         The Printer MUST use the values of "notify-charset" and
+         "notify-natural-language", respectively, from one Subscription
+         Object associated with the Event Notifications in this
+         response.
+
+         Normally, there is only one matched Subscription Object, or the
+         value of the "notify-charset" and "notify-natural-language"
+         attributes is the same in all Subscription Objects.  If not,
+         the Printer MUST pick one Subscription Object from which to
+         obtain the value of these attributes.  The algorithm for
+         picking the Subscription Object is implementation dependent.
+         The choice of natural language is not critical, because 'text'
+         and 'name' values can override the "attributes-natural-
+         language" operation attribute.  The Printer's choice of charset
+
+
+
+Herriot, et al.             Standards Track                    [Page 12]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+         is critical because a bad choice may leave it unable to send
+         some 'text' and 'name' values accurately.
+
+5.2.1.  notify-get-interval (integer(0:MAX))
+
+   The value of this operation attribute is the number of seconds that
+   the Notification Recipient SHOULD wait before trying the Get-
+   Notifications operation again.  The Printer MUST return this
+   operation attribute if (1) it is too busy to return events, (2) the
+   Notification Recipient client did not request Event Wait Mode, or (3)
+   the Printer is terminating Event Wait Mode.  The client MUST accept
+   this attribute and SHOULD reissue the Get-Notifications operation
+   (with or without "notify-wait" = 'true') at the indicated number of
+   seconds in the future in order to get more Event Notifications  This
+   value is intended to help the client be a good network citizen.
+
+   The value of this attribute MUST be at least as large as that of the
+   Printer's "ippget-event-life" Printer Description attribute (see
+   section 8.1).  The Printer MAY return a value that is larger than
+   that of the "ippget-event-life" Printer Description attribute
+   provided that the Printer increases the Event Life for this
+   Subscription object so that Notification Recipients taking account of
+   the larger value and polling with a longer interval will not miss
+   events.  Note:  Implementing such an algorithm requires some hidden
+   attributes in the Subscription object that are IMPLEMENTATION
+   DEPENDENT.
+
+   If the Printer wants to remain in Event Wait Mode, then the Printer
+   MUST NOT return this attribute in the response.
+
+   Here is a complete table of combinations of "notify-wait", "status-
+   code", "notify-get-interval", and Event Notification Attributes
+   Groups for Get-Notification initial (Wait and No Wait) Responses and
+   subsequent Event Wait Mode Responses (which may stay in Event Wait
+   Mode or may request the Notification Recipient to leave Event Wait
+   Mode):
+
+       Table 2.  Combinations of "notify-wait", "status-code", and
+                           "notify-get-interval"
+
+         Client sends:  Printer returns:  Printer       Event
+                                          returns:      Notification
+         "notify-wait"  "status-code"     "notify-get-  Attribute
+                                          interval"     Groups
+
+         1.  'false'*   'successful-ok'   MUST return N maybe
+         2.  'false'*   'not-found'       MUST NOT      MUST NOT
+         3.  'false'*   'busy'            MUST return N MUST NOT
+
+
+
+Herriot, et al.             Standards Track                    [Page 13]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+         4.  'false'*   'events-          MUST NOT      'job-
+                        complete'                        completed'
+         5.  'true'     'successful-ok'   MUST NOT      MUST
+         6.  'true'     'successful-ok'   MUST return N maybe
+         7.  'true'     'not-found'       MUST NOT      MUST NOT
+         8.  'true'     'busy'            MUST return N MUST NOT
+         9.  'true'     'events-          MUST NOT      'job-
+                        complete'                        completed' or
+                                                         maybe other
+         * 'false' or client omits the "notify-wait" attribute.
+
+         Explanation:
+
+         1-4:  Client does not request Event Wait Mode.
+         5-9:  Client requests Event Wait Mode.
+         2,7:  Subscription object not found, or was canceled earlier;
+               client should NOT try again.
+         3,8:  Server busy, tells client to try later; client should try
+               again in N seconds.
+         4:    Client polled after job completed, but before Event Life
+               expired, and got the 'job-completed' event, so the client
+               shouldn't bother trying again; client should NOT try
+               again later.
+         5:    Printer returns one or more Event Notifications and is OK
+               to stay in Event Wait Mode; the client waits for more
+               Event Notifications to be returned.
+         6:    Printer wants to leave Event Wait mode.  Can happen on
+               the first response (with or without Event Notifications)
+               or happen on a subsequent response with or without Event
+               Notifications; the client SHOULD try again in N seconds.
+         9:    Either (1) the printer returns 'job-completed' event, or
+               (2) the Subscription Object was canceled by either a
+               Cancel-Job or a Per-Printer Subscription expired without
+               being renewed.  For case (1), at least one Event
+               Notification MUST be returned; for case (2), it is
+               unlikely that any Event Notifications are returned, and
+               the client should NOT try again.
+
+5.2.2.  printer-up-time (integer(1:MAX))
+
+   The value of this attribute is the Printer's "printer-up-time"
+   attribute at the time when the Printer sends this response.  The
+   Printer MUST return this attribute.  Because each Event Notification
+   also contains the value of this attribute when the event occurred,
+   the value of this attribute lets a Notification Recipient know when
+   each Event Notification occurred relative to the time of this
+   response.
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 14]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Group 2: Unsupported Attributes
+         See [RFC2911], section 3.1.7, for details on returning
+         Unsupported Attributes.
+
+   Group 3 through N: Event Notification Attributes
+         The Printer responds with one Event Notification Attributes
+         Group per matched Event Notification.  The entire response is
+         considered a single Compound Event Notification (see
+         [RFC3995]).  The matched Event Notifications are all un-expired
+         Event Notifications associated with the matched Subscription
+         Objects and MUST follow the "Event Notification Ordering"
+         requirements for Event Notifications within a Compound Event
+         Notification specified in [RFC3995] section 9.  In other words,
+         the Printer MUST order these Event Notification groups in
+         ascending time stamp (and sequence number) order for a
+         Subscription object.  If Event Notifications for multiple
+         Subscription objects are being returned, the Notification
+         Events for the next Subscription object follow in ascending
+         time stamp order, etc.
+
+         Each Event Notification Group MUST contain all of attributes
+         specified in section 9.1 ("Content of Machine Consumable Event
+         Notifications") of [RFC3995], with exceptions denoted by
+         asterisks in the tables below.
+
+         The tables below are identical to those in section 9.1
+         ("Content of Machine Consumable Event Notifications") of
+         [RFC3995], except that each cell in the "Sends" column is a
+         "MUST".
+
+         If more than one Event Notification is being returned and the
+         status of each is not the same, then the Printer MUST return a
+         "notify-status-code" attribute in each Event Notification
+         Attributes group to indicate the differing status values.
+
+         For an Event Notification for all Events, the Printer includes
+         the attributes shown in Table 3.
+
+               Table 3.  Attributes in Event Notification Content
+
+   Source Value                              Sends     Source Object
+
+   notify-subscription-id (integer(1:MAX))   MUST      Subscription
+   notify-printer-uri (uri)                  MUST      Subscription
+   notify-subscribed-event (type2 keyword)   MUST      Event
+                                                        Notification
+   printer-up-time (integer(1:MAX)) *        MUST      Printer
+   printer-current-time (dateTime)           MUST **   Printer
+
+
+
+Herriot, et al.             Standards Track                    [Page 15]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   notify-sequence-number (integer (0:MAX))  MUST      Subscription
+   notify-charset (charset)                  MUST      Subscription
+   notify-natural-language (naturalLanguage) MUST      Subscription
+   notify-user-data (octetString(63))        MUST ***  Subscription
+   notify-text (text)                        MUST      Event
+                                                        Notification
+   attributes from the "notify-attributes"   MUST **** Printer
+   attribute
+   attributes from the "notify-attributes"   MUST **** Job
+   attribute
+   attributes from the "notify-attributes"   MUST **** Subscription
+   attribute
+
+      * As specified in [RFC3995] section 9, the value of the
+      "printer-up-time" attribute sent in each Event Notification
+      MUST be the time at which the Event occurred, not the time at
+      which the Event Notification was sent.
+
+      ** The Printer MUST send the "printer-current-time" attribute
+      if and only if it supports the "printer-current-time" attribute
+      on the Printer object.
+
+      *** If the associated Subscription Object does not contain a
+      "notify-user-data" attribute, the Printer MUST send an
+      octet-string of length 0.
+
+      **** If the "notify-attributes" attribute is present on the
+      Subscription Object, the Printer MUST send all attributes
+      specified by the "notify-attributes" attribute.  Note:  If the
+      Printer doesn't support the "notify-attributes" attribute, it
+      is not present on the associated Subscription Object.
+
+      For Event Notifications for Job Events, the Printer includes
+      the additional attributes shown in Table 4.
+
+     Table 4.  Additional Attributes in Event Notification Content for
+                                Job Events
+
+   Source Value                                  Sends  Source Object
+
+   job-id (integer(1:MAX))                       MUST   Job
+   job-state (type1 enum)                        MUST   Job
+   job-state-reasons (1setOf type2 keyword)      MUST   Job
+   job-impressions-completed (integer(0:MAX))    MUST * Job
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 16]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+      *  The Printer MUST send the "job-impressions-completed" attribute
+      in an Event Notification only for the combinations of Events and
+      Subscribed Events shown in Table 5.
+
+        Table 5.  Combinations of Events and Subscribed Events for
+                       "job-impressions-completed"
+
+   Job Event                 Subscribed Job Event
+
+   'job-progress'            'job-progress'
+   'job-completed'           'job-completed'
+   'job-completed'           'job-state-changed'
+
+      For Event Notification for Printer Events, the Printer includes
+      the additional attributes shown in Table 6.
+
+     Table 6.  Additional Attributes in Event Notification Content for
+                              Printer Events
+
+   Source Value                                  Sends   Source
+   Object
+
+   printer-state (type1 enum)                    MUST    Printer
+   printer-state-reasons (1setOf type2 keyword)  MUST    Printer
+   printer-is-accepting-jobs (boolean)           MUST    Printer
+
+6.  Additional Information about Subscription Template Attributes
+
+   The 'ippget' Delivery Method does not define any addition
+   Subscription Template attributes and has the conformance requirements
+   for Subscription Template attributes defined in [RFC3995].  This
+   section defines additional information about Subscription Template
+   attributes defined in [RFC3995].
+
+6.1.  notify-pull-method (type2 keyword)
+
+   This Subscription Template attribute identifies the Pull Delivery
+   Method to be used for the Subscription Object (see [RFC3995]).  To
+   support the 'ippget' Pull Delivery Method defined in this document,
+   the Printer MUST support this attribute with the following keyword
+   value:
+
+     'ippget':  Indicates that the 'ippget' Pull Delivery Method is to
+       be used for this Subscription Object.
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 17]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+7.  Subscription Description Attributes
+
+   The 'ippget' Delivery Method has the conformance requirements for
+   Subscription Description attributes defined in [RFC3995].  The
+   'ippget' Delivery Method does not define any addition Subscription
+   Description attributes.
+
+8.  Additional Printer Description Attributes
+
+   This section defines additional Printer Description attributes for
+   use with the 'ippget' Delivery Method.
+
+8.1.  ippget-event-life (integer(15:MAX))
+
+   This Printer Description attribute specifies the Event Life value
+   that the Printer assigns to each Event; i.e., the number of seconds
+   after an Event occurs during which a Printer will return that Event
+   in an Event Notification in a Get-Notifications response.  After the
+   Event Life expires for the Event, the Printer MAY no longer return an
+   Event Notification for that Event in a Get-Notifications response.
+
+   The Printer MUST support this attribute if it supports the 'ippget'
+   Delivery Method.  The value MUST be 15 or more (at least 15 seconds),
+   and 60 (seconds) is the RECOMMENDED value to align with the PWG Job
+   Monitoring MIB [RFC2707] jmGeneralJobPersistence and
+   jmGeneralAttributePersistence objects.
+
+   For example, assume the following:
+
+   1.  A client performs a Job Creation operation that creates a
+       Subscription Object associated with the 'ippget' Delivery Method;
+
+   2.  An Event associated with the new Job occurs immediately after the
+       Subscription Object is created;
+
+   3.  the same client or some other client performs a Get-Notifications
+       operation so that the client is connected N seconds after the Job
+       Creation operation.
+
+   Then, if N is less than the value of this attribute, the client(s)
+   performing the Get-Notifications operations can expect not to miss
+   any Event-Notifications, barring some unforeseen lack of memory space
+   in the Printer.  Note:  The client MUST initiate the Get-
+   Notifications at a time that is sufficiently less that N seconds to
+   account for network latency so that it is connected to the Printer
+   before N seconds elapses.
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 18]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   If a Printer supports the 'ippget' Delivery Method, it MUST keep
+   'completed', 'canceled', or 'aborted' Job objects in the Job
+   Retention and/or Job History phases for at least as long as this
+   attribute's value.  The Printer MAY retain jobs longer that this
+   value.  See [RFC2911], section 4.3.7.1, and the discussion in
+   [RFC3995] (regarding the 'job-completed' event).  The latter explains
+   that a Notification Recipient can query the Job after receiving a
+   'job-completed' Event Notification in order to find out other
+   information about the job that is 'completed', 'aborted', or
+   'canceled'.  However, this attribute has no effect on the Cancel-
+   Subscription operation, which deletes the Subscription object
+   immediately whether or not it contains the "notify-pull-method"
+   attribute with the 'ippget' keyword value.  Immediately thereafter,
+   subsequent Get-Notifications Responses MUST NOT contain Event
+   Notifications associated with the canceled Subscription object.
+
+9.  New Values for Existing Printer Description Attributes
+
+   This section defines additional values for existing Printer
+   Description attributes as defined in [RFC3995].
+
+9.1.  notify-pull-method-supported (1setOf type2 keyword)
+
+   The following keyword value for the "notify-pull-method-supported"
+   attribute is added in order to support the new Delivery Method
+   defined in this document:
+
+      'ippget':   The IPP Notification Pull Delivery Method defined in
+        this document.
+
+9.2.  operations-supported (1setOf type2 enum)
+
+   Table 7 lists the "operation-id" value defined in order to support
+   the new Get-Notifications operation defined in this document.
+
+                    Table 7.  Operation-id Assignments
+
+      Value       Operation Name
+
+      0x001C      Get-Notifications
+
+10.  New Status Codes
+
+   The following status code is defined as an extension for this
+   Delivery Method and is returned as the status code of the Get-
+   Notifications operation in Group 1 or Group 3 to N (see section 5.2).
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 19]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+10.1.  successful-ok-events-complete (0x0007)
+
+   The Printer MUST return the 'successful-ok-events-complete' status
+   code to indicate when this Get-Notifications response is the last
+   response for a Subscription object, whether or not there are Event
+   Notifications being returned.  This condition occurs for Event Wait
+   Mode with Notification Recipients waiting for responses when (1) the
+   Subscription Object is canceled with a Cancel-Subscription operation,
+   (2) the Subscription object is deleted, when the Per-Printer
+   Subscription lease time expires, or (3) the 'job-completed' event
+   occurs for a Per-Job Subscription.  This condition also occurs for a
+   Get-Notifications request that a Notification Recipient makes after
+   the job completes, but before the Event Life expires.
+
+11.  Encoding and Transport
+
+   This section defines the encoding and transport considerations for
+   this Delivery Method based on [RFC2910].
+
+   The encoding of a Get-Notifications Response is modeled after the
+   Get-Jobs Response (see [RFC2911]).  In a Get-Notifications Response,
+   each Event Notification Attributes Group MUST start with an 'event-
+   notification-attributes-tag' (see the section "Encodings of
+   Additional Attribute Tags" in [RFC3995]), and end with an 'end-of-
+   attributes-tag'.  In addition, for Event Wait Mode the multi-
+   part/related is used to separate each multiple response (in time) to
+   a single Get-Notifications Request.
+
+   The Printer returns Get-Notification Response as follows:
+
+   1.  If the Notification Recipient client did not request Event Wait
+       Mode ("notify-wait" = 'false' or omitted), the Printer ends the
+       response with an 'end-of-attributes-tag' (see [RFC2911], Get-Jobs
+       encoding), as with any operation response.
+
+   2.  If the Notification Recipient client requests Event Wait Mode
+       ("notify-wait" = 'true') and the Printer wishes to honor the
+       request, the Printer MUST return the response as an
+       application/ipp part inside a multi-part/related MIME media type.
+       When one or more additional Events occur, the Printer returns
+       each as an additional Event Notification Group using a separate
+       application/ipp part under the multi-part/related type.
+
+   3.  If the client requested Event Wait Mode ("notify-wait" = 'true'),
+       but the Printer does not wish to honor the request in the initial
+       response and wants the client explicitly polled for Event
+       Notifications, the Printer MUST return the "notify-get-interval"
+       operation attribute (see section 5.2.1).  The Printer returns the
+
+
+
+Herriot, et al.             Standards Track                    [Page 20]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+       response as an application/ipp part that MAY be inside an multi-
+       part/related type.  The client MUST accept this response and
+       reissue the Get-Notifications request in the future indicated by
+       the value of the "notify-get-interval" attribute value.
+
+   4.  If the client requested Event Wait Mode ("notify-wait" = 'true'),
+       and the Printer initially honored the request but later wishes to
+       leave Event Wait Mode,  the Printer MUST return the "notify-get-
+       interval" operation attribute (see section 5.2.1).  The Printer
+       returns the response as an application/ipp part that MUST be
+       inside an multi-part/related type.
+
+   NOTE:  If a Notification Recipient fails to receive a response, it
+   can ask the Printer for the same Event Notifications again.  The
+   Notification Recipient will receive the same Event Notifications that
+   it should have received the first time, except for those Event
+   Notifications that have expired in the meantime.
+
+   The Printer MAY chunk the responses, but this has no significance to
+   the IPP semantics.
+
+   This notification delivery method uses the IPP transport and encoding
+   [RFC2910] for the Get-Notifications operation with the following
+   extension, allocated in [RFC3995]:
+
+          Table 8.  The "event-notification-attributes-tag" Value
+
+      Tag Value (Hex)   Meaning
+
+      0x07              "event-notification-attributes-tag"
+
+12.  Conformance Requirements
+
+   This section lists the conformance requirements for clients and
+   Printers.
+
+12.1.  Conformance for IPP Printers
+
+   It is OPTIONAL for a Printer to support IPP Notifications as defined
+   in [RFC3995].  However, if a Printer supports IPP Notifications, the
+   Printer MUST support the 'ippget' Delivery Method, as defined in this
+   document, as one of its Delivery Methods.  IPP Printers that conform
+   to this specification
+
+   1.  MUST meet the conformance requirements defined in [RFC3995] for a
+       Pull Delivery Method;
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 21]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   2.  MUST support the Get-Notifications operation defined in section
+       5, including Event Wait Mode;
+
+   3.  MUST support the Subscription Template object attributes, as
+       defined in section 6;
+
+   4.  MUST support the Subscription Description object attributes, as
+       defined in section 7;
+
+   5.  MUST support the "ippget-event-life" Printer Description
+       attribute defined in section 8.1, including retaining jobs in the
+       Job Retention and/or Job History phases for at least as long as
+       the value specified by the Printer's "ippget-event-life";
+
+   6.  MUST support the additional values for IPP/1.1 Printer
+       Description attributes defined in section 9;
+
+   7.  MUST support the 'successful-ok-events-complete' status code, as
+       described in section 10.1;
+
+   8.  MUST listen for the IPP Get-Notifications operation requests on
+       IANA-assigned well-known port 631, unless explicitly configured
+       by system administrators or site policies;
+
+   9.  SHOULD NOT listen for IPP Get-Notifications operation requests on
+       any other port, unless explicitly configured by system
+       administrators or site policies; and
+
+   10. MUST meet the security conformance requirements stated in section
+       18.4.
+
+12.2.  Conformance for IPP Clients
+
+   It is OPTIONAL for an IPP Client to support IPP Notifications as
+   defined in [RFC3995].  However, if a client supports IPP
+   Notifications, the client MUST support the 'ippget' Delivery Method
+   as defined in this document as one of its Delivery Methods.  IPP
+   Clients that conform to this specification:
+
+   1.  MUST create Subscription Objects by sending Subscription Creation
+       operation requests containing the "notify-pull-method" attribute
+       (as opposed to the "notify-recipient-uri" attribute) using the
+       'ippget' keyword value (see sections 6.1 and 15.2);
+
+   2.  MUST send IPP Get-Notifications operation requests (see section
+       5.1) via the port specified in the associated 'ipp' URL (if
+       present) or otherwise via IANA-assigned well-known port 631;
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 22]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   3.  MUST convert the associated 'ipp' URLs for use in IPP Get-
+       Notifications operation to their corresponding 'http' URL forms
+       for use in the HTTP layer, according to the rules in section 5,
+       "IPP URL Scheme", in [RFC2910]; and
+
+   4.  MUST meet the security conformance requirements stated in section
+       18.5.
+
+13.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2910]    Herriot, R., Butler, S., Moore, P., Turner, R., and J.
+                Wenn, "Internet Printing Protocol/1.1: Encoding and
+                Transport", RFC 2910, September 2000.
+
+   [RFC2911]    Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
+                P. Powell, "Internet Printing Protocol/1.1: Model and
+                Semantics", RFC 2911, September 2000.
+
+   [RFC3995]   Herriot, R. and T. Hastings, "Internet Printing Protocol
+                (IPP): Event Notifications and Subscriptions", RFC 3995,
+                March 2005.
+
+14.  Informative References
+
+   [RFC2565]    Herriot, R., Butler, S., Moore, P., and R. Turner,
+                "Internet Printing Protocol/1.0: Encoding and
+                Transport", RFC 2565, April 1999.
+
+   [RFC2566]    deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
+                P. Powell, "Internet Printing Protocol/1.0: Model and
+                Semantics", RFC 2566, April 1999.
+
+   [RFC2567]    Wright, F., "Design Goals for an Internet Printing
+                Protocol", RFC 2567, April 1999.
+
+   [RFC2568]    Zilles, S., "Rationale for the Structure of the Model
+                and Protocol for the Internet Printing Protocol", RFC
+                2568, April 1999.
+
+   [RFC2569]    Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
+                "Mapping between LPD and IPP Protocols", RFC 2569, April
+                1999.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 23]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   [RFC2616]    Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
+                Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+                Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2707]    Bergman, R., Hastings, T., Isaacson, S., and H. Lewis,
+                "Job Monitoring MIB - V1.0", RFC 2707, November 1999.
+
+   [RFC3196]    Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
+                Holst, "Internet Printing Protocol/1.1: Implementor's
+                Guide", RFC 3196, November 2001.
+
+   [RFC3997]    Hastings, T., Ed., deBry, R., and H. Lewis, "Internet
+                Printing Protocol (IPP): Requirements for IPP
+                Notifications", RFC 3997, March 2005.
+
+15.  IANA Considerations
+
+   This section contains the exact information that the IANA has added
+   to the IPP Registries according to the procedures defined in
+   [RFC2911], section 6.  These registrations have been published in the
+   http://www.iana.org/assignments/ipp-registrations registry.
+
+15.1.  Attribute Registrations
+
+   The following table lists the attributes defined in this document.
+   This has been registered according to the procedures in RFC 2911
+   [RFC2911] section 6.2.
+
+   Printer Description attributes:                Reference   Section
+   -------------------------------                ---------   -------
+   ippget-event-life (integer(15:MAX))            [RFC3996]   8.1
+
+15.2.  Delivery Method and Additional Keyword Attribute Value
+       Registrations for Existing Attributes
+
+   This section lists additional keyword attribute value registrations
+   for use with existing attributes defined in other documents.  These
+   have been registered according to the procedures in [RFC2911],
+   section 6.1.  According to [RFC3995], section 24.7.3, Pull Delivery
+   Method registrations are the keyword attribute value registrations
+   for the "notify-pull-method" and "notify-pull-method-supported"
+   attributes.
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 24]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Attribute (attribute syntax)
+     Values                                       Reference   Section
+     -----------------------                      ---------   -------
+   notify-pull-method (type2 keyword)             [RFC3995]   5.3.2
+   notify-pull-method-supported (1setOf type2 keyword)
+                                                  [RFC3995]   5.3.2.1
+     ippget                                       [RFC3996]   9.1
+
+15.3.  Additional Enum Attribute Values
+
+   The following table lists the enum attribute values defined in this
+   document.  These have been registered according to the procedures in
+   [RFC2911], section 6.1.
+
+   Attribute (attribute syntax)
+     Value    Name                                Reference   Section
+     ------   -----------------------------       ---------   -------
+   operations-supported (1setOf type2 enum)       [RFC2911]   4.4.15
+     0x001C   Get-Notifications                   [RFC3996]   9.2
+
+15.4.  Operation Registrations
+
+   The following table lists the operations defined in this document.
+   This has been registered according to the procedures in RFC 2911
+   [RFC2911] section 6.4.
+
+   Operations:                                    Reference   Section
+   -----------                                    ---------   -------
+   Get-Notifications                              [RFC3996]   5
+
+15.5.  Status Code Registrations
+
+   The following table lists the status codes defined in this document.
+   This has been registered according to the procedures in [RFC2911],
+   section 6.6.
+
+   Status codes:                                  Reference  Section
+   -------------                                  ---------  -------
+   successful-ok-events-complete (0x0007)         [RFC3996]  10.1
+
+16.  Internationalization Considerations
+
+   The IPP Printer MUST localize the "notify-text" attribute as
+   specified in section 14 of [RFC3995].
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 25]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   In addition, when the client receives the Get-Notifications response,
+   it is expected to localize the attributes that have the 'keyword'
+   attribute syntax according to the charset and natural language
+   requested in the Get-Notifications request.
+
+17.  Security Considerations
+
+   The IPP Model and Semantics document [RFC2911, section 8] discusses
+   high-level security requirements (Client Authentication, Server
+   Authentication and Operation Privacy).  The IPP Transport and
+   Encoding document [RFC2910, section 8] discusses the security
+   requirements for the IPP protocol.  Client Authentication is the
+   mechanism by which the client proves its identity to the server in a
+   secure manner.  Server Authentication is the mechanism by which the
+   server proves its identity to the client in a secure manner.
+   Operation Privacy is defined as a mechanism for protecting operations
+   from eavesdropping.
+
+   The 'ippget' Delivery Method with its Get-Notifications operations
+   leverages the security mechanism that are used in IPP/1.1 [RFC2910
+   and RFC2911] without adding any additional security mechanisms in
+   order to maintain the same security support as IPP/1.1.
+
+   The access control model for the Get-Notifications operation defined
+   in this document is the same as the access control model for the
+   Get-Job-Attributes operation (see [RFC2911], section 3.2.6).  The
+   primary difference is that a Get-Notifications operation is directed
+   at Subscription Objects rather than at Job objects, and a returned
+   attribute group contains Event Notification attributes rather than
+   Job object attributes.
+
+17.1.  Notification Recipient Client Access Rights
+
+   The Notification Recipient client MUST have the following access
+   rights to the Subscription object(s) targeted by the Get-
+   Notifications operation request:
+
+      The authenticated user (see [RFC2911], section 8.3) performing
+      this operation MUST be (1) the owner of each Subscription Object
+      identified by the "notify-subscription-ids" operation attribute
+      (see section 5.1.1), (2) an operator or administrator of the
+      Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise
+      authorized by the Printer's administrator-configured security
+      policy to request Event Notifications from the target Subscription
+      Object(s).  Furthermore, the Printer's security policy MAY limit
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 26]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+      the attributes returned by the Get-Notifications operation, in a
+      manner similar to that of the Get-Job-Attributes operation (see
+      [RFC2911], end of section 3.3.4.2).
+
+17.2.  Printer Security Threats
+
+   Because the Get-Notifications operation is sent in the same direction
+   as are Job Creation operations, usually by the same client, this
+   Event Notification Delivery Method poses no additional
+   authentication, authorization, privacy, firewall, or port assignment
+   issues above those for the IPP Get-Job-Attributes and Get-Printer-
+   Attributes operations (see [RFC2911], sections 3.2.6 and 3.2.5).
+
+17.3.  Notification Recipient Security Threats
+
+   Unwanted Events Notifications (spam):  Unlike Push Event Notification
+   Delivery Methods in which the IPP Printer initiates the Event
+   Notification, with the Pull Delivery Method defined in this document,
+   the Notification Recipient is the client that initiates the Get-
+   Notifications operation (see section 5).  Therefore, with this method
+   there is no chance of "spam" notifications.
+
+   Note:  When a client stays connected to a Printer by using the Event
+   Wait Mode (see section 5.1.3) in order to receive Event Notifications
+   as they occur, it can close down the IPP connection at any time and
+   so can avoid future unwanted Event Notifications at any time.
+
+   It is true that the client has control over whether to ask for Event
+   Notifications.  However, if the client subscribes to an event and
+   does a Get-Notifications request, it gets all events for the
+   Subscription Object in the sequence number range (see section 5.1.2),
+   not just those it wants.  If a client subscribes to a Per-Printer
+   Subscription job event, such as 'job-completed', and someone then
+   starts and cancels thousands of jobs, the client would have to
+   receive these events in addition to those it is interested in.  A
+   client can protect itself better by subscribing to its own jobs by
+   using a Per-Job Subscription, rather than create a Per-Printer
+   subscription whose Job events apply to all jobs.
+
+17.4.  Security Requirements for Printers
+
+   For the Get-Notifications operation defined in this document, the
+   same Printer conformance requirements apply for supporting and using
+   Client Authentication, Server Authentication and Operation Privacy as
+   stated in [RFC2910] section 8 for all IPP operations.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 27]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+17.5.  Security Requirements for Clients
+
+   For the Get-Notifications operation defined in this document, the
+   same client conformance requirements apply for supporting and using
+   Client Authentication, Server Authentication, and Operation Privacy
+   as stated in [RFC2910], section 8, for all IPP operations.
+
+18.  Description of Base IPP Documents (Informative)
+
+   The base set of IPP documents includes the following:
+
+     Design Goals for an Internet Printing Protocol [RFC2567]
+     Rationale for the Structure and Model and Protocol for the Internet
+       Printing Protocol [RFC2568]
+     Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+     Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+     Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+     Mapping between LPD and IPP Protocols [RFC2569]
+
+   "Design Goals for an Internet Printing Protocol" takes a broad look
+   at distributed printing functionality, and it enumerates real-life
+   scenarios that help clarify the features that need to be included in
+   a printing protocol for the Internet.  It identifies requirements for
+   three types of users: end users, operators, and administrators.  It
+   calls out a subset of end user requirements that are satisfied in
+   IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator operations have
+   been added to IPP/1.1.
+
+   "Rationale for the Structure and Model and Protocol for the Internet
+   Printing Protocol" describes IPP from a high-level view, defines a
+   roadmap for the various documents that form the suite of IPP
+   specification documents, and gives background and rationale for the
+   IETF working group's major decisions.
+
+   "Internet Printing Protocol/1.1: Model and Semantics" describes a
+   simplified model with abstract objects, their attributes, and their
+   operations that are independent of encoding and transport.  It
+   introduces a Printer and a Job object.  The Job object optionally
+   supports multiple documents per Job.  It also addresses security,
+   internationalization, and directory issues.
+
+   "Internet Printing Protocol/1.1: Encoding and Transport" is a formal
+   mapping of the abstract operations and attributes defined in the
+   model document onto HTTP/1.1 [RFC2616].  It defines the encoding
+   rules for a new Internet MIME media type called "application/ipp".
+   This document also defines the rules for transporting over HTTP a
+   message body whose Content-Type is "application/ipp".  This document
+   defines the 'ipp' scheme for identifying IPP printers and jobs.
+
+
+
+Herriot, et al.             Standards Track                    [Page 28]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   "Internet Printing Protocol/1.1: Implementer's Guide" gives insight
+   and advice to implementers of IPP clients and IPP objects.  It is
+   intended to help them understand IPP/1.1 and some of the
+   considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   "Mapping between LPD and IPP Protocols" gives some advice to
+   implementers of gateways between IPP and LPD (Line Printer Daemon)
+   implementations.
+
+19.  Contributors
+
+   Carl Kugler and Harry Lewis contributed the basic idea of in-band
+   "smart polling" coupled with multiple responses for a single
+   operation on the same connection, with one response for each event as
+   it occurs.  Without their continual persuasion, we would not have
+   arrived at this Delivery Method specification and would not have been
+   able to agree on a single REQUIRED Delivery Method for IPP.
+
+   Carl Kugler
+   IBM Corporation
+   6300 Diagonal Highway
+   Boulder, CO 80301
+
+   EMail: kugler@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 29]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+Authors' Addresses
+
+   Robert Herriot
+   Global Workflow Solutions
+   706 Colorado Ave.
+   Palo Alto, CA 94303
+
+   Phone: 650-324-4000
+   EMail: bob@herriot.com
+
+
+   Thomas N. Hastings
+   Xerox Corporation
+   710 S Aviation Blvd.  ESAE 242
+   El Segundo CA 90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-6342
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Harry Lewis
+   IBM Corporation
+   6300 Diagonal Hwy
+   Boulder, CO 80301
+
+   Phone: (303) 924-5337
+   EMail: harryl@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 30]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 31]
+
diff --git a/standards/rfc3997.txt b/standards/rfc3997.txt
new file mode 100644
index 000000000..3dc0e1eb5
--- /dev/null
+++ b/standards/rfc3997.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                   T. Hastings, Ed.
+Request for Comments: 3997                             Xerox Corporation
+Category: Informational                                      R. K. deBry
+                                               Utah Valley State College
+                                                                H. Lewis
+                                                         IBM Corporation
+                                                              March 2005
+
+
+                   Internet Printing Protocol (IPP):
+                   Requirements for IPP Notifications
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document is one of a set of documents that together describe all
+   aspects of the Internet Printing Protocol (IPP).  IPP is an
+   application-level protocol that can be used for distributed printing
+   on the Internet.  There are multiple parts to IPP, but the primary
+   architectural components are the Model, the Protocol, and an
+   interface to Directory Services.  This document provides a statement
+   of the requirements for notifications as an optional part of an IPP
+   Service.
+
+Table of Contents
+
+   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.   Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.   Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.   Security Considerations for IPP Notifications Requirements. . 12
+   6.   Internationalization Considerations . . . . . . . . . . . . . 13
+   7.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+   8.   References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
+        8.1.  Normative References. . . . . . . . . . . . . . . . . . 14
+        8.2.  Informative References. . . . . . . . . . . . . . . . . 14
+   9.   Appendix A: Description of the Base IPP Documents . . . . . . 15
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Hastings, et al.             Informational                      [Page 1]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+1.  Introduction
+
+   This document is one of a set of documents that together describe all
+   aspects of the Internet Printing Protocol (IPP).  IPP is an
+   application level protocol that can be used for distributed printing
+   on the Internet.  There are multiple parts to IPP, but the primary
+   architectural components are the Model, the Protocol, and an
+   interface to Directory Services.  This document provides a statement
+   of the requirements for notifications as an optional part of an IPP
+   Service.  See section 10 for a description of the base IPP documents.
+
+   The scope of this requirements document covers functionality used by
+   the following kinds of IPP Users: End Users, Print Administrators,
+   and Operators.  See [RFC3995] for the extensions to the Internet
+   Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911],
+   [RFC2910], and future versions.
+
+2.  Terminology
+
+   It is necessary to define a set of terms to be able to clearly
+   express the requirements for notification services in an IPP System.
+
+2.1.  Job-Submitting End User
+
+   A human end user who submits a print job to an IPP Printer.  This
+   person may or may not be within the same security domain as the
+   Printer.  This person may or may not be geographically near the
+   printer.
+
+2.2.  Administrator
+
+   A human user who established policy for and configures the print
+   system.
+
+2.3.  Operator
+
+   A human user who carries out the policy established by the
+   Administrator and controls the day-to-day running of the print
+   system.
+
+2.4.  Job-Submitting Application
+
+   An application (for example, a batch application), acting on behalf
+   of a Job Submitting End User, that submits a print job to an IPP
+   Printer.  The application may or may not be within the same security
+   domain as the Printer.  This application may or may not be
+   geographically near the printer.
+
+
+
+
+Hastings, et al.             Informational                      [Page 2]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+2.5.  Security Domain
+
+   For the purposes of this discussion, the set of network components
+   that can communicate without going through a proxy or firewall.  A
+   security domain may be geographically very large; for example,
+   anywhere within example.com.
+
+2.6.  IPP Client
+
+   The software component that sends IPP requests to an IPP Printer
+   object and accepts IPP responses from an IPP Printer.
+
+2.7.  Job Recipient
+
+   A human who is the ultimate consumer of the print job.  In many cases
+   this will be the same person as the Job-Submitting End User, but this
+   need not always be the case.  For example, if I use IPP to print a
+   document on a printer in a business partner's office, I am the Job-
+   Submitting End User, and the person whom I intend the document for in
+   my business partner's office is the Job Recipient.  Since one of the
+   goals of IPP is to be able to print near the Job Recipient, we would
+   normally expect that person to be in the same security domain as, and
+   geographically near, the Printer.  However, this may not always be
+   the case.  For example, I submit a print job across the Internet to a
+   XYZ's print shop.  I am both the Submitting End User and the Job
+   Recipient, but I am neither near nor in the same security domain as
+   the Printer.
+
+2.8.  Job Recipient Proxy
+
+   A person acting on behalf of the Job Recipient.  The Job Recipient
+   Proxy physically picks up the printed document from the Printer if
+   the Job Recipient cannot do so.  The Proxy is by definition
+   geographically near and in the same security domain as the printer.
+   For example, I submit a print job from home to be printed on a
+   printer at work.  I'd like my secretary to pick up the print job and
+   put it on my desk.  In this case,  I am acting as both a Job-
+   Submitting End User and a Job Recipient.  My secretary is acting as a
+   Job Recipient Proxy.
+
+2.9.  Notification Subscriber
+
+   A client that requests the IPP Printer to send Event Notifications to
+   one or more Notification Recipients.  A Notification Subscriber may
+   be a Job-Submitting End User or an End User, an Operator, or an
+   Administrator that is not submitting a job.
+
+
+
+
+
+Hastings, et al.             Informational                      [Page 3]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+2.10.  Notification Source
+
+   The entity that sends Event Notifications.
+
+2.11.  Notification Recipient
+
+   The entity that receives IPP Notifications about Job and/or Printer
+   events.  A Notification Recipient may be a Job Submitting End User, a
+   Job-Submitting Application, a Job Recipient, a Job Recipient Proxy,
+   an Operator, an Administrator, etc., and his or her representative,
+   log file, usage statistics-gathering application, or other active or
+   passive entities.
+
+2.12.  Notification Recipient Agent
+
+   A program that receives Event Notifications on behalf of the
+   Notification Recipient.  The agent may take some action on behalf of
+   the recipient, forward the notification to the recipient via some
+   alternative means (for example, page the recipient), or queue the
+   notification for later retrieval by the recipient.
+
+2.13.  Event
+
+   An Event is an occurrence (either expected or unexpected) within the
+   printing system of a change of state, condition, or configuration of
+   a Job or Printer object.
+
+2.14.  Event Notification
+
+   When an event occurs, an Event Notification is generated that fully
+   describes the event (what the event was, where it occurred, when it
+   occurred, etc.).  Event Notifications are delivered to all the
+   Notification Recipients that are subscribed to that Event, if any.
+   The Event Notification is delivered to the address of the
+   Notification Recipient by using the notification delivery method
+   defined in the subscription.  However, an Event Notification is sent
+   ONLY if there is a corresponding subscription.
+
+2.15.  Notification Subscription
+
+   A Notification Subscription is a request by a Notification Subscriber
+   to the IPP Printer to send Event Notifications to specified
+   Notification Recipient(s) when an event occurs.
+
+
+
+
+
+
+
+
+Hastings, et al.             Informational                      [Page 4]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+2.16.  Notification Attributes
+
+   IPP Objects (for example, a print job) from which notification are
+   being sent may have associated attributes.  A user may want to have
+   one or more of these returned along with a particular notification.
+   In general, these may include any attribute associated with the
+   object emitting the notification.  Examples include the following:
+
+     number-of-intervening jobs
+     job-k-octets
+     job-k-octets processed
+     job impressions
+     job-impressions-interpreted
+     job-impressions-completed
+     impressionsCompletedCurrentCopy (job MIB)
+     sheetCompletedCopyNumber (job MIB)
+     sheetsCompletedDocumentNumber (job MIB)
+     Copies-requested
+     Copy-type
+     Output-destination
+     Job-state-reasons
+     Job ID
+     Printer URI
+     Subscription ID (for job independent subscription)
+
+2.17.  Notification Delivery Method (or Delivery Method for Short)
+
+   Event Notifications are delivered by using a Delivery Method.  An
+   example of a Delivery Method is email.
+
+2.18.  Immediate Notification
+
+   Notifications sent to the Notification Recipient or the Notification
+   Recipient's agent in such a way that the notification arrives
+   immediately, within the limits of common addressing, routing, network
+   congestion, and quality of service.
+
+2.19.  Store-and-Forward Notification
+
+   Notifications that are not necessarily delivered to Notification
+   Recipients immediately but are queued for delivery by an intermediate
+   network application, for later retrieval.  Email is an example of a
+   store-and-forward notification delivery method.
+
+
+
+
+
+
+
+
+Hastings, et al.             Informational                      [Page 5]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+2.20.  Reliable Delivery of Notifications
+
+   Notifications that are delivered by a reliable delivery of packets or
+   character stream, with acknowledgement and retry, so that delivery of
+   the notification is guaranteed within determinate time limits.  For
+   example, if the Notification Recipient has logged off and gone home
+   for the day, an immediate notification cannot be guaranteed, even
+   when sent over a reliable transport, because there is nothing there
+   to catch it.  Guaranteed delivery requires both store-and-forward
+   notification and a reliable transport.
+
+2.21.  Notification over Unreliable Transport
+
+   Notifications are delivered via the fundamental transport address and
+   routing framework, but no acknowledgement or retry is required.
+   Process-to-process communications, if involved, are unconstrained.
+
+2.22.  Human-Consumable Notification
+
+   Notifications intended to be consumed by human end users only.  Email
+   would be an example of a Human-Consumable Notification, though it
+   could also contain Machine-Consumable Notification.
+
+2.23.  Machine-Consumable Notification
+
+   Notifications that are intended for consumption by a program only,
+   such as an IPP Client.  Machine-Consumable Notifications may not
+   contain human-readable information.  Do we need both human and
+   machine? Machine readable is intended for application-to-application
+   only.  The Notification Recipient could process the machine-readable
+   Event Notification into human-readable format.
+
+2.24.  Mixed Notification
+
+   A mixed notification contains both Human-Consumable and Machine-
+   Consumable information.
+
+3.  Scenarios
+
+   1.   Sitting in my office, I submit a print job to the printer down
+        the hall.  I am in the same security domain as the printer and,
+        of course, geographically near.  I want to know immediately when
+        my print job will be completed (or if there is a problem)
+        because the document I am working on is urgent.  I submit the
+        print job with the following attributes:
+
+
+
+
+
+
+Hastings, et al.             Informational                      [Page 6]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+        -  Notification Recipient: Me
+        -  Notification Events: All
+        -  Notification Attributes: Job-state-reason
+        -  Notification Type: Immediate
+
+   2.   Working from home, I submit a print job to the same printer as
+        in the previous example.  However, I am not at work, I cannot
+        physically get the print file or do anything with it.  It can
+        wait until I get to work this afternoon.  However, I'd like my
+        secretary to pick up the output and put it on my desk so that it
+        doesn't get lost or misfiled.  I'd also like a store-and-forward
+        notification sent to my email so that when I get to work I can
+        tell whether there was a problem with the print job.  I submit a
+        print job with the following attributes:
+
+        -  Notification Recipient: My secretary
+        -  Notification Events: Print complete
+        -  Notification Type: Immediate
+
+        -  Notification Recipient:  Me
+        -  Notification Events:  Print complete
+        -  Notification Attributes:  Impressions completed
+        -  Notification Type: Store and forward
+
+   3.   Sitting in my office, I submit a print job to a client at an
+        engineering firm my company works with on a daily basis.  The
+        engineering firm is in Belgium.  I would like my client to know
+        when the print job is complete so that she can pick it up from
+        the printer in her building.  It is important that she review it
+        right away and send her comments back to me.  I submit the print
+        job with the following attributes:
+
+        -  Notification Recipient: Client at engineering firm
+        -  Notification Events: Print complete
+        -  Notification Type: Immediate
+        -  Notification Language: French
+
+   4.   From a hotel room, I send a print job to a Kinko's store in the
+        town I am working in, in order to get a printed report for the
+        meeting I am attending in the morning.  As I'm going out to
+        dinner after I get this job submitted, an immediate notification
+        won't do me much good.  However, I'd like to check in the
+        morning before I drive to the Kinko's store to see whether the
+        file has been printed.  An email notification is sufficient for
+        this purpose.  I submit the print job with the following
+        attributes:
+
+
+
+
+
+Hastings, et al.             Informational                      [Page 7]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+        -  Notification Recipient: Me
+        -  Notification Events: Print complete
+        -  Notification Type: Store and forward
+
+   5.   I am printing a large, complex print file.  I want to have some
+        immediate feedback on the progress of the print job as it
+        prints.  I submit the print job with the following attributes:
+
+        -  Notification Recipient: Me
+        -  Notification Type: Immediate
+        -  Notification Events:  All state transitions
+        -  Notification Attributes: Impression completed
+
+   6.   I am an operator and one of my duties is to keep the printer
+        running.  I subscribe independently from a job submission so
+        that my subscription outlasts any particular job.  I subscribe
+        with the following attributes:
+
+        -  Notification Recipient: Me
+        -  Notification Type: Immediate
+        -  Notification Events: All Printer state transitions
+        -  Notification Attributes: Printer state, printer state
+           reasons, device powering up, device powering down
+
+   7.   I am a usage statistics gathering application.  I subscribe
+        independently from a job submission so that my subscription
+        outlasts any particular job.  My subscription may persist across
+        power cycles.  I subscribe with the following attributes:
+
+        -  Notification Recipient: Me
+        -  Notification Type: Immediate
+        -  Notification Events: Job completion
+        -  Notification Attributes: Impression completed, sheets
+           completed, time submitted, time started, time completed, job
+           owner, job size in octets, etc.
+
+   8.   I am a client application program that displays a list of jobs
+        currently queued for printing on a printer.  I display the
+        "job-name", "job-state", "job-state-reasons", "page-count", and
+        "intervening-jobs", either for the user's jobs or for all jobs.
+        The window displaying the job list remains open for an
+        independent amount of time, and it is desired that it represent
+        the current state of the queue.  It is desired that the
+        application only perform a slow poll in order to recover from
+        any missed notifications.  So the event delivery mechanism
+        provides the means to update the screen on all needed changes,
+        including querying for some attributes that may not be delivered
+        in the Notification.
+
+
+
+Hastings, et al.             Informational                      [Page 8]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+   9.   I am a client application program that displays a list of
+        printers.  For each Printer, I display the current state and
+        configuration.  The window displaying the printer list remains
+        open for an independent amount of time, and it is desired that
+        it represent the current state of each printer.  It is desired
+        that the application only need to perform a slow poll in order
+        to recover from any missed notifications.  So the event delivery
+        mechanism provides the means to update the screen on all needed
+        changes, including querying for some attributes that may not be
+        delivered in the Notification.
+
+   10.  I am an IPP Server that controls one or more devices and that
+        implements an IPP Printer object to represent each device.  I
+        want to support IPP Notification for each of the IPP Printer
+        objects that I implement.  Many of these devices do not support
+        notification (or IPP).  So I need to support the IPP
+        Notification semantics specified for each IPP Printer object
+        myself on behalf of each of the devices that each of the IPP
+        Printer objects represents.  When I accept an IPP job creation
+        requests, I convert it to what the device will accept.  In some
+        cases, I must poll the devices in order to be informed of their
+        job and device state and state changes to be able to send IPP
+        Notifications to subscribed Notification Recipients.
+
+   11.  I am an IPP Server that controls one or more devices and that
+        implements an IPP Printer object to represent each device.  I
+        want to support IPP Notification for each of the IPP Printer
+        objects that I implement.  These devices all support IPP,
+        including IPP Notification.  I would like the design choice for
+        supporting IPP Notification for these objects either (1) by
+        forwarding the notification to the IPP Printers that I, alone,
+        control and have them send the notifications to the intended
+        Notification Recipients without my involvement, or (2) by
+        replacing the notification submitted with the Job to indicate me
+        as the Notification Recipient; in turn I will forward
+        Notifications to the Notification Recipients requested by my
+        clients.  Most of the rest of the contents of the IPP Job I send
+        to the IPP Printers I control will be the same as those that I
+        receive from my IPP clients.
+
+   12.  I am an IPP Server that controls one or more devices and that
+        implements an IPP Printer object to represent each device.  I
+        want to support IPP Notification for each of the IPP Printer
+        objects that I implement.  These devices all support IPP,
+        including IPP Notification.  Because these IPP Printers MAY also
+        be controlled by other servers (using IPP or other protocols), I
+        only want job events for the jobs that I send, but I do want
+        Printer events all the time, so that I can show proper Printer
+
+
+
+Hastings, et al.             Informational                      [Page 9]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+        state to my clients.  So I subscribe to these IPP Printers for
+        Printer events with a long-standing subscription, with myself as
+        the Notification Recipient.  When I get a Job Creation request,
+        I decide to which IPP Printer to send the job.  When I do so, I
+        also add a job subscription for Job events, with me as the
+        Notification Recipient to the job's job subscriptions supplied
+        by my clients (this usage is called "piggybacking").  These IPP
+        Printers automatically remove their job subscriptions when the
+        job finishes, as for all job subscriptions, so that I no longer
+        get Job events when my jobs are completed.
+
+4.  Requirements
+
+   The following requirements are intended to be met by the IPP
+   Notification specification (not the implementation).  The following
+   are true for the resulting IPP Notification Specification document:
+
+   1.  It must indicate which of these requirements are REQUIRED and
+       which are OPTIONAL for a conforming implementation to support.
+       See [RFC2911], section 12.1, for the definition of these
+       important conformance terms.
+
+   2.  It must be designed so that an IPP Printer can transparently
+       support the IPP Notification semantics by using third-party
+       notification services that exist today or that may be
+       standardized in the future.
+
+   3.  It must define a means for a Job-Submitting End User to specify
+       zero or more Notification Recipients when submitting a print job.
+       A Submitter will not be able to prevent out-of-band subscriptions
+       from authorized persons, such as Operators.
+
+   4.  It must define a means, when specifying a Notification Recipient,
+       for a Notification Subscriber to specify one or more notification
+       events for that Notification Recipient, subject to administrative
+       and security policy restrictions.  Any of the following
+       constitute Job or Printer Events for which a Job Submitting End
+       User can specify that notifications be sent:
+
+       -  Any standard Printer MIB alert
+       -  Job Received (transition from Unknown to Pending)
+       -  Job Started (transition from Pending to Processing)
+       -  Page Complete (page is stacked)
+       -  Collated Copy Complete (last sheet of collated copy is
+          stacked)
+
+
+
+
+
+
+Hastings, et al.             Informational                     [Page 10]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+       -  Job Complete (transition from Processing or Processing-stopped
+          to Completed)
+       -  Job Aborted (transition from Pending, Pending-held,
+       -  Processing, or Processing-stopped to Aborted)
+       -  Job Canceled (transition from Pending, Pending-held,
+       -  Processing, or Processing-held to Canceled)
+       -  Other job state changes, such as paused, purged
+       -  Device problems for which the job is destined
+       -  Job (interpreter) issues
+
+   5.   It must define how an End User or Operator subscribes for
+
+        -  any set of Job Events for a specific job, or
+        -  any set of Printer Events while a specific job is not
+           complete.
+
+   6.   It must define how an End User or Operator subscribes for the
+        following without having to submit a Job:
+
+        -  Any set of Printer Events for a defined period.
+        -  Any set of Job Events for all jobs, with no control over
+           which jobs.
+
+   7.   It must define how the Notification Subscriber is able to
+        specify either immediate or store-and-forward notification
+        independently for each Notification Recipient.  The means may be
+        explicit, or implied by the method of delivery chosen by the Job
+        Submitting End User.
+
+   8.   It must define common delivery methods: e.g., email.
+
+   9.   It must define how an IPP Printer validates its ability to
+        deliver an Event by using the specified delivery scheme.  If it
+        does not support the specified scheme, or if the specified
+        scheme is invalid for some reason, then the IPP Printer accepts
+        and performs the request anyway and indicates the unsupported
+        attribute values.  There is no requirement for the IPP Printer
+        receiving the print request to validate the identity of a
+        Notification Recipient, or the ability of the system to deliver
+        an event to that recipient as requested (for example, if the
+        Notification Recipient is not at work today).
+
+   10.  It must define a class of IPP event notification delivery
+        methods that can flow through corporate firewalls.  However, an
+        IPP printer need not test to guarantee delivery of the
+        notification through a firewall before accepting a print job.
+
+
+
+
+
+Hastings, et al.             Informational                     [Page 11]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+   11.  It may define a means to deliver a notification to the
+        submitting client when the delivery of an event notification to
+        a specified Notification Recipient fails.  A fallback means of
+        subscribers to determine whether notifications have failed
+        (i.e., polling) may be provided.
+
+   12.  It must define a mechanism for localizing Human-Consumable
+        Notifications by the Notification Source.
+
+   13.  It may define a way to specify whether event delivery requires
+        acknowledgement back to the Notification Source.
+
+   14.  There must be a mechanism defined so that job-independent
+        subscriptions do not become stale and do not require human
+        intervention to be removed.  However, a subscription must not be
+        deemed stale only if it is unable to deliver an Event
+        Notification, as temporary Notification delivery problems must
+        be tolerated.
+
+   15.  A mechanism must be defined so that an Event Subscriber is able
+        to add an Event Subscription to a Job after the Job has been
+        submitted.
+
+   16.  A mechanism must be defined so that a client is able to cancel
+        an Event Subscription on a job or printer after the job has been
+        submitted.
+
+   17.  A mechanism must be defined so that a client can obtain the set
+        of current Subscriptions.
+
+5.  Security Considerations for IPP Notifications Requirements
+
+   By far the biggest security concern is the abuse of notification:
+   sending unwanted notifications sent to third parties (i.e., spam).
+   The problem is made worse by notification addresses that may be
+   redistributed to multiple parties (e.g., mailing lists).  Scenarios
+   exist in which third-party notification is required (see scenarios 2
+   and 3).  The fully secure solution would require active agreement of
+   all recipients before anything is sent out.  However, requirement 9
+   ("There is no requirement for an IPP Printer receiving the print
+   request to validate the identity of an event recipient") argues
+   against this.  Certain systems may decide to disallow third-party
+   notifications (a traditional fax model).
+
+   The same security issues are present when Clients submit notification
+   requests to the IPP Printer as when they submit an IPP/1.1 print job
+   request.  The same mechanisms used by IPP/1.1 can therefore be used
+
+
+
+
+Hastings, et al.             Informational                     [Page 12]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+   by the client notification submission.  Operations that require
+   authentication can use the HTTP authentication.  Operations that
+   require privacy can use the HTTP/TLS privacy.
+
+   The notification access control model should be similar to the IPP
+   access control model.  Creating a notification subscription is
+   associated with a user.  Only the creator or an operator can cancel
+   the subscription.  The system may limit the listing of items to items
+   owned by the user.  Some subscriptions (e.g., those that have a
+   lifetime longer than a job) can be done only by privileged users
+   (operators and/or administrators), if that is the authorization
+   policy.
+
+   The standard security concerns (delivery to the right user, privacy
+   of content, tamper-proof content) apply to the notification delivery.
+   IPP should use the security mechanism of the delivery method used.
+   Some delivery mechanisms are more secure than others.  Therefore,
+   sensitive notifications should use the delivery method that has the
+   strongest security.
+
+6.  Internationalization Considerations
+
+   The Human-Consumable Notification must be localized to the natural
+   language and charset that Notification Subscriber specifies within
+   the choice of natural languages and charsets that the IPP Printer
+   supports.
+
+   The Machine-Consumable Notification data uses the "application/ipp"
+   MIME media type.  It contains attributes whose text values are
+   required to be in the natural language and charset that the
+   Notification Subscriber specifies within the choice of natural
+   languages and charsets that the IPP Printer supports.  See [RFC2566].
+
+7.  IANA Considerations
+
+   Some notification delivery methods have been registered with IANA for
+   use in URLs.  These will be defined in other documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.             Informational                     [Page 13]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2910]   Herriot, R., Butler, S., Moore, P., Turner, R., and J.
+               Wenn, "Internet Printing Protocol/1.1: Encoding and
+               Transport", RFC 2910, September 2000.
+
+   [RFC2911]   Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
+               P. Powell, "Internet Printing Protocol/1.1: Model and
+               Semantics", RFC 2911, September 2000.
+
+   [RFC3995]   Herriot, R. and T. Hastings, "Internet Printing Protocol
+               (IPP): Event Notifications and Subscriptions", RFC 3995,
+               March 2005.
+
+8.2.  Informative References
+
+   [RFC2565]   Herriot, R., Butler, S., Moore, P., and R. Turner,
+               "Internet Printing Protocol/1.0: Encoding and Transport",
+               RFC 2565, April 1999.
+
+   [RFC2566]   deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
+               P. Powell, "Internet Printing Protocol/1.0: Model and
+               Semantics", RFC 2566, April 1999.
+
+   [RFC2567]   Wright, F., "Design Goals for an Internet Printing
+               Protocol", RFC 2567, April 1999.
+
+   [RFC2568]   Zilles, S., "Rationale for the Structure of the Model and
+               Protocol for the Internet Printing Protocol", RFC 2568,
+               April 1999.
+
+   [RFC2569]   Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
+               "Mapping between LPD and IPP Protocols", RFC 2569, April
+               1999.
+
+   [RFC2639]   Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
+               Holst, "Internet Printing Protocol/1.1: Implementor's
+               Guide", RFC 3196, November 2001.
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.             Informational                     [Page 14]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+9.  Appendix A: Description of the Base IPP Documents
+
+   The base set of IPP documents includes the following:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+        Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+      Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+      Mapping between LPD and IPP Protocols [RFC2569]
+
+   "Design Goals for an Internet Printing Protocol" takes a broad look
+   at distributed printing functionality, and it enumerates real-life
+   scenarios that help clarify the features that need to be included in
+   a printing protocol for the Internet.  It identifies requirements for
+   three types of users: end users, operators, and administrators.  It
+   calls out a subset of end-user requirements that are satisfied in
+   IPP/1.0 [RFC2566], [RFC2565].  A few OPTIONAL operator operations
+   have been added to IPP/1.1 [RFC2911], [RFC2910].
+
+   "Rationale for the Structure and Model and Protocol for the Internet
+   Printing Protocol" describes IPP from a high-level view, defines a
+   roadmap for the various documents that form the suite of IPP
+   specification documents, and gives background and rationale for the
+   IETF IPP working group's major decisions.
+
+   "Internet Printing Protocol/1.1: Model and Semantics" describes a
+   simplified model with abstract objects, their attributes, and their
+   operations.  The model introduces a Printer and a Job.  The Job
+   supports multiple documents per Job.  The model document also
+   addresses security, internationalization, and directory issues.
+
+   "Internet Printing Protocol/1.1: Encoding and Transport" is a formal
+   mapping of the abstract operations and attributes defined in the
+   model document onto HTTP/1.1 [RFC2616].  It also defines the encoding
+   rules for a new Internet MIME media type called "application/ipp".
+   This document also defines the rules for transporting over HTTP a
+   message body whose Content-Type is "application/ipp".  This document
+   defines the "ipp" scheme for identifying IPP printers and jobs.
+
+   "Internet Printing Protocol/1.1: Implementer's Guide" gives insight
+   and advice to implementers of IPP clients and IPP objects.  It is
+   intended to help them understand IPP/1.1 and some of the
+   considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+
+
+Hastings, et al.             Informational                     [Page 15]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+   "Mapping between LPD and IPP Protocols" gives some advice to
+   implementers of gateways between IPP and LPD (Line Printer Daemon )
+   implementations.
+
+Authors' Addresses
+
+   Tom Hastings (editor)
+   Xerox Corporation
+   701 S Aviation Blvd,  ESAE 242
+   El Segundo, CA   90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-6342
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Roger deBry
+   Utah Valley State College
+
+   Phone: (801) 863-8848
+   EMail: debryro@uvsc.edu
+
+
+   Harry Lewis
+   IBM Corporation
+   6300 Diagonal Hwy
+   Boulder, CO 80301
+
+   Phone: (303) 924-5337
+   EMail: harryl@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al.             Informational                     [Page 16]
+
+RFC 3997             IPP: Notification Requirements           March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hastings, et al.             Informational                     [Page 17]
+
diff --git a/standards/rfc3998.txt b/standards/rfc3998.txt
new file mode 100644
index 000000000..f2ba35f80
--- /dev/null
+++ b/standards/rfc3998.txt
@@ -0,0 +1,2579 @@
+
+
+
+
+
+
+Network Working Group                                          C. Kugler
+Request for Comments: 3998                                      H. Lewis
+Category: Standards Track                                IBM Corporation
+                                                        T. Hastings, Ed.
+                                                       Xerox Corporation
+                                                              March 2005
+
+
+                   Internet Printing Protocol (IPP):
+               Job and Printer Administrative Operations
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies the following 16 additional OPTIONAL system
+   administration operations for use with the Internet Printing
+   Protocol/1.1 (IPP), plus a few associated attributes, values, and
+   status codes, and using the IPP Printer object to manage printer
+   fan-out and fan-in.
+
+      Printer operations:                       Job operations:
+      Enable-Printer and Disable-Printer        Reprocess-Job
+      Pause-Printer-After-Current-Job           Cancel-Current-Job
+      Hold-New-Jobs and Release-Held-New-Jobs   Suspend-Current-Job
+      Deactivate-Printer and Activate-Printer   Resume-Job
+      Restart-Printer                           Promote-Job
+      Shutdown-Printer and Startup-Printer      Schedule-Job-After
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                     [Page 1]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+Table of Contents
+
+   1.  Introduction..................................................  4
+   2.  Terminology...................................................  4
+       2.1.  Conformance Terminology.................................  4
+       2.2.  Other Terminology.......................................  5
+   3.  Definition of the Printer Operations..........................  6
+       3.1.  The Disable and Enable Printer Operations...............  7
+             3.1.1.  Disable-Printer Operation.......................  7
+             3.1.2.  Enable-Printer Operation........................  8
+       3.2.  The Pause and Resume Printer Operations.................  8
+             3.2.1.  Pause-Printer-After-Current-Job Operation.......  9
+       3.3.  Hold and Release New Jobs Operations.................... 11
+             3.3.1.  Hold-New-Jobs Operation......................... 11
+             3.3.2.  Release-Held-New-Jobs Operation................. 12
+       3.4.  Deactivate and Activate Printer Operations.............. 12
+             3.4.1.  Deactivate-Printer Operation.................... 13
+             3.4.2.  Activate-Printer Operation...................... 13
+       3.5.  Restart-Printer, Shutdown-Printer,
+             and Startup-Printer Operations.......................... 14
+             3.5.1.  Restart-Printer Operation....................... 14
+             3.5.2.  Shutdown-Printer Operation...................... 14
+             3.5.3.  Startup-Printer Operation....................... 15
+   4.  Definition of the Job Operations.............................. 16
+       4.1.  Reprocess-Job Operation................................. 17
+       4.2.  Cancel-Current-Job Operation............................ 17
+       4.3.  Suspend and Resume Job Operations....................... 18
+             4.3.1.  Suspend-Current-Job Operation................... 19
+             4.3.2.  Resume-Job Operation............................ 20
+       4.4.  Job Scheduling Operations............................... 20
+             4.4.1.  Promote-Job Operation........................... 20
+             4.4.2.  Schedule-Job-After Operation.................... 21
+   5.  Additional Status Codes....................................... 23
+       5.1.  'server-error-printer-is-deactivated' (0x050A).......... 23
+   6.  Use of Operation Attributes
+       That Are Messages from the Operator........................... 23
+   7.  New Printer Description Attributes............................ 26
+       7.1.  subordinate-printers-supported (1setOf uri)............. 26
+       7.2.  parent-printers-supported (1setOf uri).................. 26
+   8.  Additional Values for
+       the "printer-state-reasons" Printer Description Attribute..... 26
+       8.1.  'hold-new-jobs' Value................................... 27
+       8.2.  'deactivated' Value..................................... 27
+   9.  Additional Values for
+       the "job-state-reasons" Job Description attribute............. 27
+       9.1.  'job-suspended' Value................................... 27
+   10. Use of the Printer Object to Represent
+       IPP Printer Fan-Out and IPP Printer Fan-In.................... 27
+
+
+
+Kugler, et al.              Standards Track                     [Page 2]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+       10.1. IPP Printer Fan-Out..................................... 28
+       10.2. IPP Printer Fan-In...................................... 28
+       10.3. Printer Object Attributes Used
+             to Represent Printer Fan-Out and Printer Fan-In......... 29
+       10.4. Subordinate Printer URI................................. 29
+       10.5. Printer Object Attributes Used
+             to Represent Output Device Fan-Out...................... 30
+       10.6. Figures to Show All Possible Configurations............. 30
+       10.7. Forwarding Requests..................................... 33
+             10.7.1. Forwarding Requests
+                     that Affect Printer Objects..................... 33
+             10.7.2. Forwarding Requests that Affect Jobs............ 35
+       10.8. Additional Attributes to Help with Fan-Out.............. 37
+             10.8.1. output-device-assigned (name(127))
+                     Job Description Attribute - from [RFC2911]...... 37
+             10.8.2. original-requesting-user-name (name(MAX))
+                     Operation and Job Description Attribute......... 37
+             10.8.3. requesting-user-name (name(MAX))
+                     Operation Attribute - Additional Semantics...... 38
+             10.8.4. job-originating-user-name (name(MAX))
+                     Job Description Attribute -
+                     Additional Semantics............................ 38
+   11. Conformance Requirements...................................... 38
+   12. Normative References.......................................... 39
+   13. Informative References........................................ 40
+   14. IANA Considerations........................................... 40
+       14.1. Attribute Registrations................................. 41
+       14.2. Attribute Value Registrations........................... 41
+       14.3. Additional Enum Attribute Value Registrations........... 41
+       14.4. Operation Registrations................................. 42
+       14.5. Status Code Registrations............................... 43
+   15. Internationalization Considerations........................... 43
+   16. Security Considerations....................................... 43
+   17. Summary of Base IPP Documents................................. 44
+   Authors' Addresses................................................ 45
+   Full Copyright Statement.......................................... 46
+
+List of Tables
+
+   Table 1.  Printer Operation Operation-Id Assignments..............  6
+   Table 2.  Pause and Resume Printer Operations.....................  9
+   Table 3.  State Transition Table for
+             Pause-Printer-After-Current-Job Operation............... 10
+   Table 4.  Job Operation Operation-Id Assignments.................. 16
+   Table 5.  Operation Attribute Support for Printer Operations...... 24
+   Table 6.  Operation Attribute Support for Job Operations.......... 25
+   Table 7.  Forwarding Operations that Affect Printer Objects....... 34
+   Table 8.  Forwarding Operations that Affect Jobs Objects.......... 36
+
+
+
+Kugler, et al.              Standards Track                     [Page 3]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Table 9.  Conformance Requirement Dependencies for Operations..... 38
+   Table 10. Conformance Requirement Dependencies
+             for "printer-state-reasons" Values...................... 39
+   Table 11. Conformance Requirement Dependencies
+             for "job-state-reasons" Values.......................... 39
+
+List of Figures
+
+   Figure 1.  Embedded Printer Object................................ 31
+   Figure 2.  Hosted Printer Object.................................. 31
+   Figure 3.  Output Device Fan-Out.................................. 31
+   Figure 4.  Chained IPP Printer Objects............................ 32
+   Figure 5.  IPP Printer Object Fan-Out............................. 32
+   Figure 6.  IPP Printer Object Fan-In.............................. 33
+
+1.  Introduction
+
+   The Internet Printing Protocol (IPP) is an application level protocol
+   that can be used for distributed printing using Internet tools and
+   technologies.  IPP version 1.1 ([RFC2911, RFC2910]) focuses on end-
+   user functionality, with a few administrative operations included.
+   This document defines additional OPTIONAL end user, operator, and
+   administrator operations used to control Jobs and Printers.  In
+   addition, this document extends the semantic model of the Printer
+   object by allowing them to be configured into trees and/or inverted
+   trees that represent Printer object Fan-Out and Printer object Fan-
+   In, respectively.  The special case of a tree with only a single
+   Subordinate node represents Chained Printers.  This document is a
+   registration proposal for an extension to IPP/1.0 and IPP/1.1
+   following the registration procedures in those documents.
+
+   The requirements and use cases for this document are defined in
+   [RFC3239].
+
+2.  Terminology
+
+   This section defines the terminology used throughout this document.
+
+2.1.  Conformance Terminology
+
+   Capitalized terms such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+   NOT, MAY, NEED NOT, and OPTIONAL have special meaning relating to
+   conformance as defined in RFC 2119 [RFC2119] and [RFC2911], section
+   12.1.  If an implementation supports the extension defined in this
+   document, then these terms apply; otherwise, they do not.  These
+   terms define conformance to this document only; they do not affect
+   conformance to other documents, unless explicitly stated otherwise.
+
+
+
+
+Kugler, et al.              Standards Track                     [Page 4]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+2.2.  Other Terminology
+
+   This document uses terms such as "client", "Printer", "Job",
+   "attributes", "keywords", "operation", and "support".  These terms
+   have special meaning and are defined in the model terminology
+   ([RFC2911], section 12.2).
+
+   In addition, the following capitalized terms are defined:
+
+   IPP Printer object (or Printer for short) - A software abstraction
+   defined by [RFC2911].
+
+   Printer Operation - An operation whose target is an IPP Printer
+   object and whose effect is on the Printer object.
+
+   Output Device - The physical imaging mechanism that an IPP Printer
+   controls.  Note: although this term is capitalized in this
+   specification (but not in [RFC2911]), there is no formal object
+   called an Output Device defined in this document (or in [RFC2911]).
+
+   Output Device Fan-Out - A configuration in which an IPP Printer
+   controls more than one Output Device.
+
+   Printer Fan-Out - A configuration in which an IPP Printer object
+   controls more than one Subordinate IPP Printer object.
+
+   Printer Fan-In - A configuration in which an IPP Printer object is
+   controlled by more than one IPP Printer object.
+
+   Subordinate Printer - An IPP Printer object that is controlled by
+   another IPP Printer object.  Such a Subordinate Printer MAY have zero
+   or more Subordinate Printers.
+
+   Leaf Printer - An IPP Printer object that has no Subordinate
+   Printers.
+
+   Non-Leaf Printer - An IPP Printer object that has one or more
+   Subordinate Printers.  A Non-Leaf Printer is also called a Parent
+   Printer.
+
+   Chained Printer - a Non-Leaf Printer that has exactly one Subordinate
+   Printer.
+
+   Job Creation operations - IPP operations that create a Job object:
+   Print-Job, Print-URI, and Create-Job.
+
+
+
+
+
+
+Kugler, et al.              Standards Track                     [Page 5]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+3.  Definition of the Printer Operations
+
+   All Printer Operations are directed at Printer objects.  A client
+   MUST always supply the "printer-uri" operation attribute in order to
+   identify the correct target of the operation.  These descriptions
+   assume all of the common semantics of the IPP/1.1 Model and Semantics
+   document ([RFC2911], section 3.1).
+
+   The Printer Operations defined in this document are summarized in
+   Table 1.
+
+   Table 1.  Printer Operation Operation-Id Assignments
+
+   Operation Name  Operation-Id  Brief Description
+   --------------------------------------------------------------------
+   Enable-Printer      0x22      Allows the target Printer to accept
+                                 Job Creation operations.
+
+   Disable-Printer     0x23      Prevents the target Printer from
+                                 accepting Job Creation operations.
+
+   Pause-Printer-      0x24      Pauses the Printer after the current
+   After-Current-                job has been sent to the Output
+   Job                           Device.
+
+   Hold-New-Jobs       0x25      Finishes processing all currently
+                                 pending jobs.  Any new jobs are
+                                 placed in the 'pending-held' state.
+
+   Release-Held-       0x26      Releases all jobs to the 'pending'
+   New-Jobs                      state that had been held by the
+                                 effect of a previous Hold-New-Jobs
+                                 operation and condition the Printer
+                                 so that it no longer holds new jobs.
+
+   Deactivate-         0x27      Puts the Printer into a read-only
+   Printer                       deactivated state.
+
+   Activate-           0x28      Restores the Printer to normal
+   Printer                       activity.
+
+   Restart-Printer     0x29      Restarts the target Printer and re-
+                                 initializes the software.
+
+   Shutdown-           0x2A      Shuts down the target Printer so that
+   Printer                       it cannot be restarted or queried.
+
+
+
+
+
+Kugler, et al.              Standards Track                     [Page 6]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Startup-Printer     0x2B      Starts up the instance of the Printer
+                                 object.
+
+   All of the operations in this document are OPTIONAL for an IPP object
+   to support.  Unless the specification of an OPTIONAL operation
+   requires support of another OPTIONAL operation, conforming
+   implementations may support any combination of these operations.
+   Many of the operations come in pairs, so both are REQUIRED if either
+   one is implemented.
+
+3.1.  The Disable and Enable Printer Operations
+
+   This section defines the OPTIONAL Disable-Printer and Enable-Printer
+   operations that stop and start the IPP Printer object from accepting
+   new IPP jobs.  If either of these operations are supported, both MUST
+   be supported.
+
+   These operations allow the operator to control whether the Printer
+   will accept new Job Creation (Print-Job, Print-URI, and Create-Job)
+   operations.  These operations have no other effect on the Printer, so
+   the Printer continues to accept all other operations and continues to
+   schedule and process jobs normally.  In other words, these operations
+   control the "input of new jobs" to the IPP Printer, and the Pause and
+   Resume operations (see section 3.2) independently control the "output
+   of new jobs" from the IPP Printer to the Output Device.
+
+3.1.1.  Disable-Printer Operation
+
+   This OPTIONAL operation allows a client to stop the Printer object
+   from accepting new jobs; i.e., it causes the Printer to reject
+   subsequent Job Creation operations and return the 'server-error-not-
+   accepting-jobs' status code.  The Printer still accepts all other
+   operations, including Validate-Job, Send-Document, and Send-URI
+   operations.  Thus a Disable-Printer operation allows a client to
+   continue submitting multiple documents of a multiple document job if
+   the Create-Job operation had already been accepted.  All previously
+   created or submitted Jobs and all Jobs currently processing continue
+   unaffected.
+
+   The IPP Printer MUST accept the request in any state.  The Printer
+   sets the value of its "printer-is-accepting-jobs" READ-ONLY Printer
+   Description attribute to 'false' (see [RFC2911], section 4.4.20), no
+   matter what the previous value was.  This operation has no immediate
+   or direct effect on the Printer's "printer-state" and "printer-
+   state-reasons" attributes.
+
+
+
+
+
+
+Kugler, et al.              Standards Track                     [Page 7]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911] sections 1 and 8.5).
+
+   The Disable-Printer Request and Disable-Printer Response have the
+   same attribute groups and attributes as do the Pause-Printer
+   operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including
+   the new "printer-message-from-operator" operation attribute (see
+   section 6).
+
+3.1.2.  Enable-Printer Operation
+
+   This OPTIONAL operation allows a client to start the Printer object
+   accepting jobs; i.e., it causes the Printer to accept subsequent Job
+   Creation operations.  The Printer still accepts all other operations.
+   All previously submitted and currently processing Jobs continue
+   unaffected.
+
+   The IPP Printer MUST accept the request in any state.  The Printer
+   sets the value of its "printer-is-accepting-jobs" READ-ONLY Printer
+   Description attribute to 'true' (see [RFC2911], section 4.4.20), no
+   matter what the previous value was.  This operation has no immediate
+   or direct effect on the Printer's "printer-state" and "printer-
+   state-reasons" attributes.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911] sections 1 and 8.5).
+
+   The Enable-Printer Request and Enable-Printer Response have the same
+   attribute groups and attributes as does the Pause-Printer operation
+   (see [RFC2911], sections 3.2.8.1 and 3.2.8.2), including the new
+   "printer-message-from-operator" operation attribute (see section 6).
+
+3.2.  The Pause and Resume Printer Operations
+
+   This section leaves the OPTIONAL IPP/1.1 Pause-Printer (see
+   [RFC2911], sections 3.2.7) ambiguous as to whether it stops the
+   Printer immediately or after the current job.  It also defines the
+   OPTIONAL Pause-Printer-After-Current-Job operation as following the
+   current job.  These operations affect the scheduling of IPP jobs.  If
+   either of these Pause Printer operations are supported, then the
+   Resume-Printer operation MUST be supported.
+
+   These operations allow the operator to control whether the Printer
+   will send new IPP jobs to the associated Output Device(s) that the
+   IPP Printer object represents.  These operations have no other effect
+   on the Printer, so the Printer continues to accept all operations.
+
+
+
+Kugler, et al.              Standards Track                     [Page 8]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   In other words, these operations control the "output of new jobs" to
+   the Output Device(s), and the Disable and Enable Printer Operations
+   (see section 3.1) independently control the "input of new jobs" to
+   the IPP Printer.
+
+   Table 2.  Pause and Resume Printer Operations
+
+   Pause and Resume Printers  Description
+   --------------------------------------------------------------------
+   IPP/1.1 Pause Printer      Stops the IPP Printer from sending
+                              new IPP Jobs to the Output Device(s)
+                              either immediately or after the
+                              current job completes, depending on
+                              implementation, as defined in
+                              [RFC2911].
+
+   Pause-Printer-After-       Stops the IPP Printer from sending
+   Current-Job                new IPP Jobs to the Output Device(s)
+                              after the current jobs finish.
+
+   Resume-Printer             Starts the IPP Printer sending IPP
+                              Jobs to the Output Device again.
+
+3.2.1.  Pause-Printer-After-Current-Job Operation
+
+   This OPTIONAL operation allows a client to stop the Printer object
+   from sending IPP jobs to any of its Output Devices or Subordinate
+   Printers.  If the IPP Printer is in the middle of sending an IPP job
+   to an Output Device or Subordinate Printer, the IPP Printer MUST
+   complete sending that Job.  However, after receiving this operation,
+   the IPP Printer MUST NOT send any additional IPP jobs to any of its
+   Output Devices or Subordinate Printers.  In addition, after having
+   received this operation, the IPP Printer MUST NOT start processing
+   any more jobs, so additional jobs MUST NOT enter the 'processing'
+   state.
+
+   If the IPP Printer is not sending an IPP Job to the Output Device or
+   Subordinate Printer (whether or not the Output Device or Subordinate
+   Printer is busy processing any jobs), the IPP Printer object
+   transitions immediately to the 'stopped' state by setting its
+   "printer-state" attribute to 'stopped', removing the 'moving-to-
+   paused' value, if present, from its "printer-state-reasons"
+   attribute, and adding the 'paused' value to its "printer-state-
+   reasons" attribute.
+
+   If the implementation will take appreciable time to complete sending
+   an IPP job that it has started sending to an Output Device or
+   Subordinate Printer, the IPP Printer adds the 'moving-to-paused'
+
+
+
+Kugler, et al.              Standards Track                     [Page 9]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   value to the Printer object's "printer-state-reasons" attribute (see
+   section [RFC2911], 4.4.12).  When the IPP Printer has completed
+   sending IPP jobs that it was in the process of sending, the Printer
+   object transitions to the 'stopped' state by setting its "printer-
+   state" attribute to 'stopped', removing the 'moving-to-paused' value,
+   if present, from its "printer-state-reasons" attribute, and adding
+   the 'paused' value to its "printer-state-reasons" attribute.
+
+   This operation MUST NOT affect the acceptance of Job Creation
+   requests (see Disable-Printer Operation, section 3.1.1).
+
+   For any jobs that are 'pending' or 'pending-held', the 'printer-
+   stopped' values of the jobs' "job-state-reasons" attribute also
+   apply.  However, the IPP Printer NEED NOT update those jobs' "job-
+   state-reasons" attributes and only have to return the 'printer-
+   stopped' value when those jobs are queried by using the Get-Job-
+   Attributes or Get-Jobs operations (so-called "lazy evaluation").
+
+   The IPP Printer MUST accept the request in any state and transition
+   the Printer to the indicated new "printer-state", and it MUST add the
+   indicated value to "printer-state-reasons" attribute before returning
+   as follows:
+
+   Table 3.  State Transition Table for Pause-Printer-After-Current-Job
+             Operation
+
+   Current      New          "printer  IPP Printer's response status
+   "printer-    "printer-    -state-   code and action (REQUIRED/
+   state"       state"       reasons"  OPTIONAL state transition for
+                                       a Printer to support):
+  --------------------------------------------------------------------
+   'idle'       'stopped'    'paused'  REQUIRED:  'successful-ok'
+
+   'processing' 'processing' 'moving-  OPTIONAL:  'successful-ok';
+                              to-      Later, when the IPP Printer
+                              paused'  has finished sending IPP jobs
+                                       to an Output Device, the
+                                       "printer-state" becomes
+                                       'stopped', and the 'paused'
+                                       value replaces the 'moving-to-
+                                       paused' value in the "printer-
+                                       state-reasons" attribute
+
+   'processing' 'stopped'    'paused'  REQUIRED:  'successful-ok';
+                                       the IPP Printer wasn't in the
+                                       middle of sending an IPP job
+                                       to an Output Device
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 10]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   'stopped'    'stopped'    'paused'  REQUIRED:  'successful-ok'
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Pause-Printer-After-Current-Job Request and Pause-Printer-After-
+   Current-Job Response have the same attribute groups and attributes as
+   does the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and
+   3.2.7.2), including the new "printer-message-from-operator" operation
+   attribute (see section 6).
+
+3.3.  Hold and Release New Jobs Operations
+
+   This section defines operations to condition the Printer to hold any
+   new jobs and to release them.
+
+3.3.1.  Hold-New-Jobs Operation
+
+   This OPTIONAL operation allows a client to condition the Printer to
+   complete the current 'pending' and 'processing' IPP Jobs but not to
+   start processing any subsequently created IPP Jobs.  If the IPP
+   Printer is in the middle of sending an IPP job to an Output Device or
+   Subordinate Printer, the IPP Printer MUST complete sending that Job.
+   Furthermore, the IPP Printer MUST send all of the current 'pending'
+   IPP Jobs to the Output Device(s) or Subordinate IPP Printer
+   object(s).  Any subsequently received Job Creation operations will
+   cause the IPP Printer to put the Job into the 'pending-held' state,
+   with the 'job-held-on-create' value being added to the job's "job-
+   state-reasons" attribute.  Thus all newly accepted jobs will be
+   automatically held by the Printer.
+
+   When the Printer completes all the 'pending' and 'processing' jobs,
+   it enters the 'idle' state as usual.  An operator monitoring Printer
+   state changes will know when the Printer has completed all current
+   jobs because the Printer enters the 'idle' state.
+
+   This operation MUST NOT affect the acceptance of Job Creation
+   requests (see Disable-Printer Operation, section 3.1.1), except to
+   put the Jobs into the 'pending-held' state, instead of the 'pending'
+   or 'processing' state.
+
+   The IPP Printer MUST accept the request in any state, MUST NOT
+   transition the Printer to any other "printer-state", and MUST add the
+   'hold-new-jobs' value to the Printer's "printer-state-reasons"
+   attribute (whether the value was present or not).
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 11]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Hold-New-Jobs Request and Hold-New-Jobs Response have the same
+   attribute groups and attributes as does the Pause-Printer operation
+   (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new
+   "printer-message-from-operator" operation attribute (see section 6).
+
+3.3.2.  Release-Held-New-Jobs Operation
+
+   This OPTIONAL operation allows a client to undo the effect of a
+   previous Hold-New-Jobs operation.  In particular, the Printer
+   releases all the jobs that it held as a consequence of a Hold-New-
+   Jobs operations; i.e., while the 'hold-new-jobs' value was present in
+   the Printer's "printer-state-reasons" attribute.  In addition, the
+   Printer MUST accept this request in any state, MUST NOT transition
+   the Printer to any other "printer-state", and MUST remove the 'hold-
+   new-jobs' value from its "printer-state-reasons" attribute (whether
+   the value was present or not) so that the Printer no longer holds
+   newly created jobs.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Release-Held-New-Jobs Request and Release-Held-New-Jobs Response
+   have the same attribute groups and attributes as the Pause-Printer
+   operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including
+   the new "printer-message-from-operator" operation attribute (see
+   section 6).
+
+3.4.  Deactivate and Activate Printer Operations
+
+   This section defines the OPTIONAL Deactivate-Printer and Activate-
+   Printer operations that stop and start the IPP Printer object from
+   accepting all requests except queries and performing work.  If either
+   of these operations are supported, both MUST be supported.
+
+   These operations allow the operator to put the Printer into a dormant
+   read-only condition and to take it out of this condition.
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 12]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+3.4.1.  Deactivate-Printer Operation
+
+   This OPTIONAL operation allows a client to stop the Printer object
+   from sending IPP jobs to any of its Output Devices or Subordinate
+   Printers (Pause-Printer-After-Current-Job) and to stop the Printer
+   object from accepting any requests but query requests.  The Printer
+   performs a Disable-Printer and a Pause-Printer-After-Current-Job
+   operation immediately.  If these two operations cannot be completed
+   immediately, it includes use of all of the "printer-state-reasons".
+   In addition, the Printer MUST immediately reject all requests, except
+   for Activate-Printer, queries (Get-Printer-Attributes, Get-Job-
+   Attributes, Get-Jobs, etc.), Send-Document, and Send-URI (so that
+   partial job submission can be completed, see section 3.1.1).  The
+   Printer MUST then return the 'server-error-service-unavailable'
+   status code.
+
+   The IPP Printer MUST accept the request in any state.  Immediately,
+   the Printer MUST set the 'deactivated' value in its "printer-state-
+   reasons" attribute.  Note: neither the Disable-Printer nor the
+   Pause-Printer-After-Current-Job set the 'deactivated' value.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Deactivate-Printer Request and Deactivate-Printer Response have
+   the same attribute groups and attributes as does the Pause-Printer
+   operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including
+   the new "printer-message-from-operator" operation attribute (see
+   section 6).
+
+3.4.2.  Activate-Printer Operation
+
+   This OPTIONAL operation allows a client to undo the effects of the
+   Deactivate-Printer; i.e., it allows the Printer object to start
+   sending IPP jobs to any of its Output Devices or Subordinate Printers
+   (Pause-Printer-After-Current-Job) and starts the Printer object from
+   accepting any requests.  The Printer performs an Enable-Printer and a
+   Resume-Printer operation immediately.  In addition, the Printer MUST
+   immediately start accepting all requests.
+
+   The IPP Printer MUST accept the request in any state.  The Printer
+   MUST immediately remove the 'deactivated' value from its "printer-
+   state-reasons" attribute (whether it is present or not).
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+
+
+Kugler, et al.              Standards Track                    [Page 13]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   The Activate-Printer Request and Activate-Printer Response have the
+   same attribute groups and attributes as the Pause-Printer operation
+   (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new
+   "printer-message-from-operator" operation attribute (see section 6).
+
+3.5.  Restart-Printer, Shutdown-Printer, and Startup-Printer Operations
+
+   This section defines the OPTIONAL Restart-Printer, Shutdown-Printer,
+   and Startup-Printer operations that initialize, shutdown, and start
+   up the Printer object, respectively.  Each of these operations is
+   OPTIONAL, and any combination MAY be supported.
+
+3.5.1.  Restart-Printer Operation
+
+   This OPTIONAL operation allows a client to restart a Printer object
+   whose operation is in need of initialization because of incorrect or
+   erratic behavior; i.e., perform the effect of a software re-boot.
+   The implementation MUST attempt to save any information about Jobs
+   and the Printer object before re-initializing.  However, this
+   operation MAY have drastic consequences on the running system, so the
+   client SHOULD first try the Deactivate-Printer operation to minimize
+   the effect on the current state of the system.  The effects of
+   previous Disable-Printer, Pause Printer, and Deactivate-Printer
+   operations are lost.
+
+   The IPP Printer MUST accept the request in any state.  The Printer
+   object MUST initialize its Printer's "printer-state" to 'idle',
+   remove the state reasons from its "printer-state-reasons" attribute,
+   and change its "printer-is-accepting-jobs" attribute to 'true'.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Restart-Printer Request and Restart-Printer Response have the
+   same attribute groups and attributes as does the Pause-Printer
+   operation (see [RFC2911], sections 3.2.8.1 and 3.2.8.2), including
+   the new "printer-message-from-operator" operation attribute (see
+   section 6).
+
+3.5.2.  Shutdown-Printer Operation
+
+   This OPTIONAL operation allows a client to shutdown a Printer; i.e.,
+   to stop processing jobs without losing any jobs and to make the
+   Printer object unavailable for any operations using the IPP protocol.
+   There is no way to bring the instance of the Printer object back to
+   being used, except for the Startup-Printer (see section 3.5.3), which
+   starts up a new instance of the Printer object for hosted
+
+
+
+Kugler, et al.              Standards Track                    [Page 14]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   implementations.  The purpose of Shutdown-Printer is to shutdown the
+   Printer for an extended period, not to reset the device(s) or modify
+   a Printer attribute.  See Restart-Printer (section 3.5.1) and
+   Startup-Printer (section 3.5.3) for the way to initialize the
+   software.  See the Disable-Printer operation (section 3.1) for a way
+   for the client to stop the Printer from accepting Job Creation
+   requests without stopping processing or shutting down.
+
+   The Printer MUST add the 'shutdown' value (see [RFC2911], section
+   4.4.11) immediately to its "printer-state-reasons" Printer
+   Description attribute.  It then performs a Deactivate-Printer
+   operation (see section 3.4.1), which in turn performs Disable-Printer
+   and Pause-Printer-After-Current-Job operations).
+
+   Note:  To shutdown the Printer after all the currently submitted jobs
+   have completed, the operator issues a Disable-Printer operation (see
+   section 3.1.1) and then waits until all the jobs have completed.  The
+   Printer goes into the 'idle' state before issuing the Shutdown-
+   Printer operation.
+
+   The Printer object MUST accept this operation in any state and
+   transition the Printer object through the "printer-states" and
+   "printer-state-reasons" defined for the Pause-Printer-After-Current-
+   Job operation until the activity is completed and the Printer object
+   disappears.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Shutdown-Printer Request and Shutdown-Printer Response have the
+   same attribute groups and attributes as does the Pause-Printer
+   operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including
+   the new "printer-message-from-operator" operation attribute (see
+   section 6).
+
+3.5.3.  Startup-Printer operation
+
+   This OPTIONAL operation allows a client to start up an instance of a
+   Printer object, provided that there isn't one already initiated.  The
+   purpose of Startup-Printer is to allow a hosted implementation of the
+   IPP Printer object (i.e., a Server that implements an IPP Printer on
+   behalf of a networked or local Output Device) to be started after the
+   host is available (by means outside this document).  See section
+   3.5.1 for the way to initialize the software or reset the Output
+   Device(s) when the IPP Printer object has already been initiated.
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 15]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   The host MUST accept this operation only when the Printer object has
+   not been initiated.  If the Printer object already exists, the host
+   must return the 'client-error-not-possible' status code.
+
+   The result of this operation MUST be with the Printer object's
+   "printer-state" set to 'idle', the state reasons removed from its
+   "printer-state-reasons" attribute, and its "printer-is-accepting-
+   jobs" attribute set to 'false'.  Then the operator can reconfigure
+   the Printer before performing an Enable-Printer operation.  However,
+   when a Printer is first powered up, it is RECOMMENDED that its
+   "printer-is-accepting-jobs" attribute be set to 'true' in order to
+   achieve easy "out of the box" operation.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Shutdown-Printer Request and Shutdown-Printer Response have the
+   same attribute groups and attributes as does the Pause-Printer
+   operation (see [RFC2911] sections 3.2.7.1 and 3.2.7.2), including the
+   new "printer-message-from-operator" operation attribute (see section
+   6).
+
+4.  Definition of the Job Operations
+
+   All Job operations are directed at Job objects.  A client MUST always
+   supply some means to identify the Job object in order to select the
+   correct target of the operation.  That job identification MAY either
+   be a single Job URI or a combination of a Printer URI and a Job ID.
+   The IPP object implementation MUST support both forms of
+   identification for every job.
+
+   The Job Operations defined in this document are summarized in Table
+   4.
+
+   Table 4.  Job Operation Operation-Id Assignments
+
+   Operation Name  Operation-Id  Brief description
+   --------------------------------------------------------------------
+   Reprocess-Job       0x2C      Creates a copy of a completed target
+                                 job with a new Job ID and processes it.
+
+   Cancel-Current-     0x2D      Cancels the current job on the target
+   Job                           Printer or the specified job if it is
+                                 the current job.
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 16]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Suspend-            0x2E      Suspends the current processing job on
+   Current-Job                   the target Printer or the specified
+                                 job if it is the current job, allowing
+                                 other jobs to be processed instead.
+
+   Resume-Job          0x2F      Resumes the suspended target job.
+
+   Promote-Job         0x30      Promotes the pending target job to be
+                                 next after the current job(s) complete.
+
+   Schedule-Job-       0x31      Schedules the target job immediately
+   After                         after the specified job, all other
+                                 scheduling factors being equal.
+
+4.1.  Reprocess-Job Operation
+
+   This OPTIONAL operation is a create job operation that allows a
+   client to re-process a copy of a job that had been retained in the
+   queue after processing was completed, canceled, or aborted (see
+   [RFC2911], section 4.3.7.2).  This operation is the same as the
+   Restart-Job operation (see [RFC2911], section 3.3.7), except that the
+   Printer creates a new job that is a copy of the target job and the
+   target job is unchanged.  New values are assigned to the "job-uri"
+   and "job-id" attributes.  The new job's Job Description attributes
+   that track job progress, such as "job-impressions-completed", "job-
+   media-sheets-completed", and "job-k-octets-processed", are
+   initialized to 0, as with any create job operation.  The target job
+   moves to the Job History after a suitable period, independent of
+   whether one or more Reprocess-Job operations have been performed upon
+   it.
+
+   If the Set-Job-Attributes operation is supported, then the "job-
+   hold-until" operation attribute MUST be supported with at least the
+   'indefinite' value, so that a client can modify the new job before it
+   is scheduled for processing by using the Set-Job-Attributes
+   operation.  After modifying the job, the client can release the job
+   for processing by using the Release-Job operation specifying the
+   newly assigned "job-uri" or "job-id" for the new job.
+
+4.2.  Cancel-Current-Job Operation
+
+   This OPTIONAL operation allows a client to cancel the current job on
+   the target Printer or the specified job if it is the current job on
+   the Printer.  See [RFC2911], section 3.3.3, for the semantics of
+   canceling a job.  Since a Job might already be marking by the time a
+   Cancel-Current-Job is received, some media sheet pages might print
+   before the job is actually terminated.
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 17]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   If the client does not supply a "job-id" operation attribute, the
+   Printer MUST accept the request and cancel the current job if there
+   is a current job in the 'processing' or 'processing-stopped' state;
+   otherwise, it MUST reject the request and return the 'client-error-
+   not-possible' status code.  If more than one job is in the
+   'processing' or 'processing-stopped' state, the one that is marking
+   is canceled, and the others are unaffected.
+
+   Warning:  On a shared printer, there is a race condition.  Between
+   the time when a user issues this operation and the time of its
+   acceptance, the current job might change to a different job.  If the
+   user or operator is authenticated to cancel the new job, the wrong
+   job is canceled.  To prevent this race from canceling the wrong job,
+   the client MAY supply the "job-id" operation attribute, which is
+   checked against the current job's job-id.  If the job identified by
+   the "job-id" attribute is not the current job on the Printer (i.e.,
+   is not in the 'processing' or 'processing-stopped' state), the
+   Printer MUST reject this operation and return the 'client-error-not-
+   possible' status code.  Otherwise, the Printer cancels the specified
+   job.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must either be the job owner (as determined
+   in the Job Creation operation) or an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Cancel-Current-Job Request and Cancel-Current-Job Response have
+   the same attribute groups and attributes as does the Resume-Printer
+   operation (see [RFC2911], section 3.2.8), including the new "job-
+   message-from-operator" operation attribute (see section 6), with the
+   addition of the following Group 1 Operation attribute in the request:
+
+   "job-id" (integer(1:MAX)):
+      The client OPTIONALLY supplies this Operation attribute to verify
+      that the identified job is still the current job on the target
+      Printer object.  The IPP object MUST support this operation
+      attribute if it supports this operation.
+
+4.3.  Suspend and Resume Job Operations
+
+   This section defines the Suspend-Current-Job and Resume-Job
+   operations.  These operations allow an operator or user to suspend a
+   job while it is processing, allowing other jobs to be processed, and
+   to resume the suspended job at a later point without losing any of
+   the output.
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 18]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   If either of these operations is supported, both MUST be supported.
+
+   The Hold-Job and Release-Job operations ([RFC2911], section 3.3.5)
+   are for holding and releasing held jobs, not suspending and resuming
+   suspended jobs.
+
+4.3.1.  Suspend-Current-Job Operation
+
+   This OPTIONAL operation allows a client to stop the current job on
+   the target Printer or the specified job if it is the current job on
+   the Printer, to allow other jobs to be processed instead.  The
+   Printer moves the current job or the target job to the 'processing-
+   stopped' state and sets the 'job-suspended' value (see section 9.1)
+   in the job's "job-state-reasons" attribute and processes other jobs.
+
+   If the client does not supply a "job-id" operation attribute, the
+   Printer MUST accept the request and suspend the current job if there
+   is a current job in the 'processing' or 'processing-stopped' state.
+   Otherwise, it MUST reject the request and return the 'client-error-
+   not-possible' status code.  If more than one job is in the
+   'processing' or 'processing-stopped' state, all of them are
+   suspended.
+
+   Warning:  On a shared printer, there is a race condition.  Between
+   the time when a user issues this operation and the time of its
+   acceptance, the current job might change to a different job.  If the
+   user or operator is authenticated to suspend the new job, the wrong
+   job is suspended.  To prevent this race from pausing the wrong job,
+   the client MAY supply the "job-id" operation attribute, which is
+   checked against the current job's job-id.  If the job identified by
+   the "job-id" attribute is not the current job on the Printer (i.e.,
+   is not in the 'processing' or 'processing-stopped' state), the
+   Printer MUST reject this operation and return the 'client-error-not-
+   possible' status code.  Otherwise, the Printer suspends the specified
+   job and processed other jobs.
+
+   The Printer MUST reject a Suspend-Current-Job request (and return the
+   'client-error-not-possible') for a job that has been suspended, i.e.,
+   for a job in the 'processing-stopped' state, with the 'job-suspended'
+   value in its "job-state-reasons" attribute.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be either the job owner (as determined
+   in the Job Creation operation) or an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 19]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   The Suspend-Current-Job Request and Suspend-Current-Job Response have
+   the same attribute groups and attributes as does the Pause-Printer
+   operation (see [RFC2911], section 3.2.8 ), including the new "job-
+   message-from-operator" operation attribute (see section 6), with the
+   addition of the following Group 1 Operation attribute in the request:
+
+   "job-id" (integer(1:MAX)):
+      The client OPTIONALLY supplies this Operation attribute to verify
+      that the identified job is still the current job on the target
+      Printer object.  The IPP object MUST support this operation
+      attribute if it supports this operation.
+
+4.3.2.  Resume-Job Operation
+
+   This OPTIONAL operation allows a client to resume the target job at
+   the point where it was suspended.  The Printer moves the target job
+   to the 'pending' state and removes the 'job-suspended' value from the
+   job's "job-state-reasons" attribute.
+
+   If the target job is not in the 'processing-stopped' state, with the
+   'job-suspended' value in the job's "job-state-reasons" attribute, the
+   Printer MUST reject the request and return the 'client-error-not-
+   possible' status code, since the job was not suspended.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be either the job owner (as determined
+   in the Job Creation operation) or an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Resume-Job Request and Resume-Job Response have the same
+   attribute groups and attributes as the Release-Job operation (see
+   [RFC2911], section 3.3.6), including the new "job-message-from-
+   operator" operation attribute (see section 6).
+
+4.4.  Job Scheduling Operations
+
+   This section defines jobs that allow an operator to control the
+   scheduling of jobs.
+
+4.4.1.  Promote-Job Operation
+
+   This OPTIONAL operation allows a client to make the pending target
+   job be processed next after the current job completes.  This
+   operation is especially useful in a production printing environment
+   where the operator is involved in job scheduling.
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 20]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   If the target job is in the 'pending' state, this operation does not
+   change the job's state but causes the job to be processed after the
+   current job(s) complete.  If the target job is not in the 'pending'
+   state, the Printer MUST reject the request and return the 'client-
+   error-not-possible' status code.
+
+   If the Printer implements the "job-priority" Job Template attribute
+   (see [RFC2911], section 4.2.1), the Printer sets the job's "job-
+   priority" to the highest value supported (so that the job will print
+   before any of the other pending jobs).  The Printer returns the
+   target job immediately after the current job(s) in a Get-Jobs
+   response (see [RFC2911], section 3.2.6) for the 'not-completed' jobs.
+
+   When the current job is completed, canceled, suspended (see section
+   4.3.1), or aborted, the target of this operation is processed next.
+
+   If a client issues this request (again) before the target of the
+   operation of the original request started processing, the target of
+   this new request is processed first.
+
+   IPP is specified not to require queues for job scheduling, as there
+   are other implementation techniques for scheduling multiple jobs,
+   such as re-evaluating a criteria function for each job on a
+   scheduling cycle.  However, if an implementation does implement
+   queues for jobs, then the Promote-Job operation puts the specified
+   job at the front of the queue.  A subsequent Promote-Job operation
+   prior to the processing of the first job puts that specified job at
+   the front of the queue, so that it is "in front" of the previously
+   promoted job.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+   The Promote-Job Request and Promote-Job Response have the same
+   attribute groups and attributes as does the Cancel-Job operation (see
+   [RFC2911], section 3.3.3), including the new "job-message-from-
+   operator" operation attribute (see section 6).
+
+4.4.2.  Schedule-Job-After Operation
+
+   This OPTIONAL operation allows a client to request that the Printer
+   schedule the target job so that it will be processed immediately
+   after the specified predecessor job, all other scheduling factors
+   being equal.  This operation is specially useful in a production
+   printing environment where the operator is involved in job
+   scheduling.
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 21]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   If the target job is in the 'pending' state, this operation does not
+   change the job's state but causes the job to be processed after the
+   preceding job completes.  The preceding job can be in the target
+   'pending', 'processing', or 'processing-stopped' state.  If the
+   target job is not in the 'pending' state, or if the predecessor job
+   is not in the 'pending', 'processing', or 'processing-stopped' state,
+   the Printer MUST reject the request, and it returns the 'client-
+   error-not-possible' status code, as the job cannot have its position
+   changed.
+
+   If the Printer implements the "job-priority" Job Template attribute
+   (see [RFC2911], section 4.2.1), the Printer sets the job's "job-
+   priority" to that of the predecessor job (so that the job will print
+   after the predecessor job).  The Printer returns the target job
+   immediately after the predecessor in a Get-Jobs response (see
+   [RFC2911], section 3.2.6) for the 'not-completed' jobs.
+
+   When the predecessor job completes processing or is canceled or
+   aborted while processing, the target of this operation is processed
+   next.
+
+   If the client does not supply a predecessor job, this operation has
+   the same semantics as Promote-Job (see section 4.4).
+
+   IPP is specified not to require queues for job scheduling, as there
+   are other implementation techniques for scheduling multiple jobs,
+   such as re-evaluating a criteria function for each job on a
+   scheduling cycle.  However, if an implementation does implement
+   queues for jobs, then the Schedule-Job-After operation puts the
+   specified job immediately after the specified job in the queue.  A
+   subsequent Schedule-Job-After operation specifying the same job will
+   cause its target job to be placed after that job, even though it is
+   between the first target job and the specified job.  For example,
+   suppose the job queue consisted of jobs A, B, C, D, and E, in that
+   order.  A Schedule-Job-After with job E as the target and B as the
+   specified job would result in the following queue:  A, B, E, C, D.  A
+   subsequent Schedule-Job-After with Job D as the target and B as the
+   specified job would result in the following queue:  A, B, D, E, C.
+
+   In other words, the link between the two jobs in a Schedule-Job-After
+   operation is not retained; i.e., there is no attribute on either job
+   that points to the other job as a result of this operation.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation must be an operator or administrator of the
+   Printer object (see [RFC2911], sections 1 and 8.5).
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 22]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   The Schedule-Job-After Request have the same attribute groups and
+   attributes as does the Cancel-Job operation (see [RFC2911], section
+   3.3.3), plus the new "job-message-from-operator" operation attribute
+   (see section 6).  In addition, the following operation attribute is
+   defined:
+
+   "predecessor-job-id":
+      The client OPTIONALLY supplies this attribute.  The Printer MUST
+      support it, if it supports this operation.  This attribute
+      specifies the job after which the target job is to be processed.
+      If the client omits this attribute, the Printer MUST process the
+      target job next, i.e., after the current job, if there is one.
+
+   The Schedule-Job-After Response has the same attribute groups,
+   attributes, and status codes as does the Cancel-Job operation (see
+   [RFC2911], section 3.3.3).  The following status codes have
+   particular meaning for this operation:
+
+   'client-error-not-possible' - The target job was not in the 'pending'
+   state, or the predecessor job was not in the 'pending', 'processing',
+   or 'processing-stopped' state.
+
+   'client-error-not-found' - Either the target job or the predecessor
+   job was not found.
+
+5.  Additional Status Codes
+
+   This section defines new status codes used by the operations defined
+   in this document.
+
+5.1.  'server-error-printer-is-deactivated' (0x050A)
+
+   The Printer has been deactivated by the Deactivate-Printer operation
+   and is only accepting the Activate-Printer (see section 3.5.1), Get-
+   Job-Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get-
+   Xxxx operations.  An operator can perform the Activate-Printer
+   operation to allow the Printer to accept other operations.
+
+6.  Use of Operation Attributes That Are Messages from the Operator
+
+   This section summarizes the usage of the "printer-message-from-
+   operator" and "job-message-from-operator" operation attributes
+   [RFC3380] that set the corresponding Printer and Job Description
+   attributes (see [RFC2911] for the definition of these).  These
+   operation attributes are defined for most of the Printer and Job
+   operations that operators are likely to perform, respectively, so
+   that operators can indicate the reasons for their actions.
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 23]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Table 5 shows the operation attributes defined for use with the
+   Printer Operations.
+
+   Table 5.  Operation Attribute Support for Printer Operations
+
+      Operation Attribute                 A      B
+      ---------------------------------------------
+      attributes-charset                 REQ    REQ
+      attributes-natural-language        REQ    REQ
+      printer-uri                        REQ    REQ
+      requesting-user-name               REQ    REQ
+      printer-message-from-operator      Note   OPT
+
+      Legend:
+      A: Get-Printer-Attributes, Set-Printer-Attributes
+      B: All other Printer administrative operations, including, but
+         not limited to, Pause-Printer, Pause-Printer-After-Current-
+         Job, Resume-Printer, Hold-New-Jobs, Release-Held-New-Jobs,
+         Purge-Jobs, Enable-Print, Disable-Printer, Restart-
+         Printer, Shutdown-Printer, and Startup-Printer.
+    REQ: REQUIRED for a Printer to support.
+    OPT: OPTIONAL for a Printer to support; the Printer ignores the
+         attribute if it is not supported.
+   Note: According to [RFC3380], the Client MUST NOT supply the
+         "printer-message-from-operator" operation attribute in a
+         Get-Printer-Attributes or Set-Printer-Attributes operation;
+         the Printer MUST ignore this operation attribute in these
+         two operations.  Instead, when it is used by an
+         operator, the client MUST supply the
+         "printer-message-from-operator" as (one of the) explicit
+         attributes being set on the Printer object with the
+         Set-Printer-Attributes operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 24]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Table 6 shows the operation attributes defined for use with the Job
+   operations.
+
+   Table 6.  Operation Attribute Support for Job Operations
+
+      Operation Attribute                 A     B     C     F
+      ---------------------------------------------------------
+      attributes-charset                 REQ   REQ   REQ   REQ
+      attributes-natural-language        REQ   REQ   REQ   REQ
+      printer-uri                        REQ   REQ   REQ   REQ
+      job-uri                            REQ         REQ   REQ
+      job-id                             REQ   REQ   REQ   REQ
+      requesting-user-name               REQ   REQ   REQ   REQ
+      job-message-from-operator          OPT   OPT   OPT   Note
+      message**                          OPT   OPT   OPT   n/a
+      job-hold-until                     n/a   n/a   OPT*  n/a
+
+      Legend:
+      A: Cancel-Job, Resume-Job, Restart-Job, Promote-Job, Schedule-Job-
+         After
+      B: Cancel-Current-Job, Suspend-Current-Job
+      C: Hold-Job, Release-Job, Reprocess-Job
+      F: Get-Job-Attributes, Set-Job-Attributes
+
+    REQ; REQUIRED for a Printer to support.
+    OPT: OPTIONAL for a Printer to support; the Printer ignores the
+         attribute if it is supplied, but not supported.
+    n/a: not applicable for use with the operation; the Printer ignores
+         the attribute.
+   Note: According to [RFC3380], the Client MUST NOT supply the "job-
+         message-from-operator" operation attribute in a Get-Job-
+         Attributes or Set-Job-Attributes operation; the Printer MUST
+         ignore this operation attribute in these two operations.
+         Instead, when used by an operator, the client MUST supply the
+         "job-message-from-operator" as (one of the) explicit attributes
+         being set on the Job object with the Set-Job-Attributes
+         operation.
+      *: The Printer MUST support the "job-hold-until" operation
+         attribute if it supports the "job-hold-until" Job Template
+         attribute.  For the Reprocess-Job operation, the client can
+         hold the job and then modify the job before releasing it to
+         be processed.
+     **: In [RFC2911], the "message" operation attribute is defined to
+         contain a message to the operator, but [RFC2911] does not
+         define a Job Description attribute to store the message.
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 25]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+7.  New Printer Description Attributes
+
+   The following new Printer Description attributes are needed to
+   support the new operations defined in this document and the concepts
+   of Printer Fan-Out (see section 10).
+
+7.1.  subordinate-printers-supported (1setOf uri)
+
+   This Printer attribute is REQUIRED if an implementation supports
+   Subordinate Printers (see section 10) and contains the URIs of the
+   immediate Subordinate Printer object(s) associated with this Printer
+   object.  Each Non-Leaf Printer object MUST support this Printer
+   Description attribute.  A Leaf Printer object either does not support
+   the "subordinate-printers-supported" attribute or does so with the
+   'no-value' out-of-band value (see [RFC2911], section 4.1), depending
+   on the implementation.
+
+   The precise format of the Subordinate Printer URIs is implementation
+   dependent (see section 10.4).
+
+   If the Printer object does not have an associated Output Device, the
+   Printer MAY automatically copy the value of the Subordinate Printer
+   object's "printer-name" attribute to the Job object's "output-
+   device-assigned" attribute (see [RFC2911], section 4.3.13).  The
+   "output-device-assigned" Job attribute identifies the Output Device
+   to which the Printer object has assigned a job; for example, when a
+   single Printer object is supporting Device Fan-Out or Printer Fan-
+   Out.
+
+7.2.  parent-printers-supported (1setOf uri)
+
+   This Printer attribute is REQUIRED if an implementation supports
+   Subordinate Printers (see section 10) and contains the URI of the
+   Non-Leaf printer object(s) for which this Printer object is the
+   immediate Subordinate; i.e., this Printer's immediate "parent" or
+   "parents".  Each Subordinate Printer object MUST support this Printer
+   Description attribute.  A Printer that has no parents either does not
+   support the "parent-printers-supported" attribute or does so with the
+   'no-value' out-of-band value (see [RFC2911], section 4.1), depending
+   on the implementation.
+
+8.  Additional Values for the "printer-state-reasons" Printer
+    Description Attribute
+
+   This section defines additional values for the "printer-state-
+   reasons" Printer Description attribute.
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 26]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+8.1.  'hold-new-jobs' Value
+
+   'hold-new-jobs': The operator has issued the Hold-New-Jobs operation
+      (see section 3.3.1) or other means, but the output-device(s) are
+      taking an appreciable time to stop.  Later, when all output has
+      stopped, the "printer-state" becomes 'stopped', and the 'paused'
+      value replaces the 'moving-to-paused' value in the "printer-
+      state-reasons" attribute.  This value MUST be supported if the
+      Hold-New-Jobs operation is supported and the implementation takes
+      significant time to pause a device in certain circumstances.
+
+8.2.  'deactivated' Value
+
+   'deactivated':  A client has issued a Deactivate-Printer operation
+      for the Printer object (see section 3.4.1), and the Printer is in
+      the process of becoming deactivated or has become deactivated.
+      The Printer MUST reject all requests except for Activate-Printer,
+      queries (Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs,
+      etc.), Send-Document, and Send-URI (so that partial job submission
+      can be completed; see section 3.1.1), and then return the
+      'server-error-service-unavailable' status code.
+
+9.  Additional Values for the "job-state-reasons" Job Description
+    Attribute
+
+   This section defines additional values for the "job-state-reasons"
+   Job Description attribute.
+
+9.1.  'job-suspended' Value
+
+   'job-suspended':  While job processing has been suspended by the
+      Suspend-Current-Job operation, other jobs can be processed on the
+      Printer.  The Job can be resumed with the Resume-Job operation,
+      which removes this value.
+
+10.  Use of the Printer Object to Represent IPP Printer Fan-Out and IPP
+     Printer Fan-In
+
+   This section defines how the Printer object MAY be used to represent
+   IPP Printer Fan-Out and IPP Printer Fan-In.  In Fan-Out, an IPP
+   Printer is used to represent other IPP Printer objects.  In Fan-In,
+   several IPP Printer objects are used to represent another IPP Printer
+   object.
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 27]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+10.1.  IPP Printer Fan-Out
+
+   The IPP/1.1 Model and Semantics introduces the semantic concept of an
+   IPP Printer object that represents more than one Output Device (see
+   [RFC2911], section 2.1).  This concept is called "Output Device Fan-
+   Out".  However, with Fan-Out there was no way to represent the
+   individual states of the Output Devices or to perform operations on a
+   specific Output Device.  This document generalizes the semantics of
+   the Printer object to represent Subordinate Fan-Out Output Devices
+   such as IPP Printer objects.  This concept is called "Printer object
+   Fan-Out".  A Printer object that has a Subordinate Printer object is
+   called a Non-Leaf Printer object.  Thus, a Non-Leaf Printer object
+   supports one or more Subordinate Printer objects in order to
+   represent Printer object Fan-Out.  A Printer object that does not
+   have any Subordinate Printer objects is called a Leaf Printer object.
+
+   Each Non-Leaf Printer object submits jobs to its immediate
+   Subordinate Printers and otherwise controls the Subordinate Printers
+   by using IPP or other protocols.  Whether pending jobs are kept in
+   the Non-Leaf Printer until a Subordinate Printer can accept them or
+   are kept in the Subordinate Printers depends on implementation and/or
+   configuration policy.  Furthermore, a Subordinate Printer object MAY,
+   in turn, have Subordinate Printer objects.  Thus a Printer object can
+   be both a Non-Leaf Printer and a Subordinate Printer.
+
+   A Subordinate Printer object MUST be a conforming Printer object, so
+   it MUST support all of the REQUIRED [RFC2911] operations and
+   attributes.  However, with access control, the Subordinate Printer
+   MAY be configured so that end-user clients are not permitted to
+   perform any operations (or just Get-Printer-Attributes) while one or
+   more Non-Leaf Printer object(s) are permitted to perform any
+   operation.
+
+10.2.  IPP Printer Fan-In
+
+   The IPP/1.1 Model and Semantics did not preclude the semantic concept
+   of multiple IPP Printer objects that represent a single Output Device
+   (see [RFC2911], section 2.1).  However, there was no way for the
+   client to determine whether there was a Fan-In configuration; nor was
+   there a way to perform operations on the Subordinate device.  This
+   specification generalizes the semantics of the Printer object to
+   allow several Non-Leaf IPP Printer objects to represent a single
+   Subordinate Printer object.  Thus a Non-Leaf Printer object MAY share
+   a Subordinate Printer object with one or more other Non-Leaf Printer
+   objects in order to represent IPP Printer Fan-In.
+
+   As with Fan-Out (see section 10.1), when a Printer object is a Non-
+   Leaf Printer, it MUST NOT have an associated Output Device.  As with
+
+
+
+Kugler, et al.              Standards Track                    [Page 28]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Fan-Out, a Leaf Printer object has one or more associated Output
+   Devices.  As with Fan-Out, the Non-Leaf Printer objects submit jobs
+   to their Subordinate Printer objects and otherwise control the
+   Subordinate Printer.  As with Fan-Out, whether pending jobs are kept
+   in the Non-Leaf Printers until the Subordinate Printer can accept
+   them or are kept in the Subordinate Printer depends on the
+   implementation and/or configuration policy.
+
+10.3.  Printer Object Attributes Used to Represent Printer Fan-Out and
+       Printer Fan-In
+
+   The following Printer Description attributes are defined to represent
+   the relationship between Printer object(s) and their Subordinate
+   Printer object(s):
+
+      1. "subordinate-printers-supported" (1setOf uri) - Contains the
+         URI of the immediate Subordinate Printer object(s).
+
+      2. "parent-printers-supported (1setOf uri) - Contains the URI of
+         the Non-Leaf printer object(s) for which this Printer object is
+         the immediate Subordinate; i.e., this Printer's immediate
+         "parent" or "parents".
+
+10.4.  Subordinate Printer URI
+
+   Each Subordinate Printer object has a URI used as the target of each
+   operation on the Subordinate Printer.  The means to configure URIs
+   for Subordinate Printer objects is implementation-dependent, as are
+   all URIs.  However, there are two distinct approaches:
+
+      a. When the implementation seeks to make sure that no operation on
+         a Subordinate Printer object "sneaks by" the parent Printer
+         object (or that no Subordinate Printer is fronting for a device
+         that is not networked), the host part of the URI specifies the
+         host of the parent Printer.  Then the parent Printer object can
+         easily reflect the state of the Subordinate Printer objects in
+         the parent's Printer object state and state reasons as the
+         operation passes "through" the parent Printer object.
+
+      b. When the Subordinate Printer is networked and the
+         implementation allows operations to go directly to the
+         Subordinate Printer (with proper access control) without
+         knowledge of the parent Printer object, the host part of the
+         URI is different from the host part of the parent Printer
+         object.  In this a case, the parent Printer object MAY keep its
+         "printer-state" and "printer-state-reasons" up to date, either
+         by polling the Subordinate Printer object or by subscribing to
+         events with the Subordinate Printer object (see [RFC3995] for
+
+
+
+Kugler, et al.              Standards Track                    [Page 29]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+         means to subscribe to event notification when the Subordinate
+         Printer object supports IPP notification).  Alternatively, the
+         parent Printer MAY wait until its "printer-state" and
+         "printer-state-reasons" attributes are queried and then query
+         all its Subordinate Printers in order to return the correct
+         values.
+
+10.5.  Printer Object Attributes Used to Represent Output Device Fan-Out
+
+   Only Leaf IPP Printer objects are allowed to have one or more
+   associated Output Devices.  Each Leaf Printer object MAY support the
+   "output-devices-supported" (1setOf name(127)) to indicate the user-
+   friendly name(s) of the Output Device(s) that the Leaf Printer object
+   represents.  It is RECOMMENDED that each Leaf Printer object have
+   only one associated Output Device, so that the individual Output
+   Devices can be represented completely and controlled completely by
+   clients.  In other words, the Leaf Printer's "output-devices-
+   supported" attribute SHOULD have only one value.
+
+   Non-Leaf Printer MUST NOT have associated Output Devices.  However, a
+   Non-Leaf Printer SHOULD support an "output-devices-supported" (1setOf
+   name(127)) Printer Description attribute that contains all the values
+   of its immediate Subordinate Printers.  As these Subordinate Printers
+   MAY be Leaf or Non-Leaf, the same rules apply to them.  Thus any
+   Non-Leaf Printer SHOULD have an "output-devices-supported" (1setOf
+   name(127)) attribute that contains all the values of the Output
+   Devices associated with Leaf Printers of its complete sub-tree.
+
+   When a configuration of Printers and Output Devices is added, moved,
+   or changed, there can be moments when the tree structure is not
+   consistent; i.e., times when a Non-Leaf Printer's "subordinate-
+   printers-supported" does not agree with the Subordinate Printer's
+   "parent-printers-supported".  Therefore, the operator SHOULD first
+   Deactivate all Printers being configured in this way, update all
+   pointer attributes, and then reactivate them.  A useful client tool
+   would validate a tree structure before Activating the Printers
+   involved.
+
+10.6.  Figures to Show All Possible Configurations
+
+   Figures 1, 2, and 3 are taken from [RFC2911] to show the
+   configurations possible with IPP/1.0 and IPP/1.1 where all Printer
+   objects are Leaf Printer objects.  The remaining figures show
+   additional configurations using Non-Leaf and Leaf Printer objects.
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 30]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Legend:
+
+   ----> indicates a network protocol with the direction of its requests
+
+   ##### indicates a Printer object that is either
+         embedded in an Output Device, or
+         hosted in a server.
+         The Printer object might or might not be capable
+         of queuing/spooling.
+
+   any   indicates any network protocol or direct
+         connect, including IPP.
+
+                                                  Output Device
+                                                +---------------+
+                                                |  ###########  |
+    O   +--------+                              |  # (Leaf)  #  |
+   /|\  | client |------------IPP-----------------># Printer #  |
+   / \  +--------+                              |  # Object  #  |
+                                                |  ###########  |
+                                                +---------------+
+
+                   Figure 1.  Embedded Printer Object
+
+
+                             ###########          Output Device
+    O   +--------+           # (Leaf)  #        +---------------+
+   /|\  | client |---IPP----># Printer #---any->|               |
+   / \  +--------+           # object  #        |               |
+                             ###########        +---------------+
+
+                   Figure 2.  Hosted Printer Object
+
+
+                                                +---------------+
+                                                |               |
+                                             +->| Output Device |
+                             ########### any/   |               |
+    O   +--------+           # (Leaf)  #   /    +---------------+
+   /|\  | client |---IPP----># Printer #--*
+   / \  +--------+           # Object  #   \    +---------------+
+                             ########### any\   |               |
+                                             +->| Output Device |
+                                                |               |
+                                                +---------------+
+
+                   Figure 3.  Output Device Fan-Out
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 31]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+                             ###########           ###########
+    O   +--------+           # Non-Leaf#           # subord. #
+   /|\  | client |---IPP----># Printer #---IPP----># Printer #
+   / \  +--------+           # object  #           # object  #
+                             ###########           ###########
+
+   The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
+   through 6, or can be a Leaf Printer, as in Figures 1 through 3.
+
+                   Figure 4.  Chained IPP Printer Objects
+
+
+                   +------IPP--------------------->###########
+                  /                           +---># subord. #
+                 /                           /     # Printer #
+                /            ###########   IPP     # object  #
+    O   +--------+           # Non-Leaf#   /       ###########
+   /|\  | client |---IPP----># Printer #--*
+   / \  +--------+           # object  #   \
+                \            ###########   IPP     ###########
+                 \                           \     # subord. #
+                  \                           +---># Printer #
+                   +------IPP---------------------># object  #
+                                                   ###########
+
+   The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
+   through 6, or can be a Leaf Printer, as in Figures 1 through 3.
+
+                   Figure 5.  IPP Printer Object Fan-Out
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 32]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+                             ###########
+                             # Non-Leaf#
+                        +---># Printer #-+
+                       /     # object  #  \
+                     IPP     ###########   \       ###########
+    O   +--------+   /                      +-IPP-># subord. #
+   /|\  | client |--+-----------IPP---------------># Printer #
+   / \  +--------+   \                      +-IPP-># object  #
+                     IPP     ###########   /       ###########
+                       \     # Non-Leaf#  /
+                        +---># Printer #-+
+                             # object  #
+                             ###########
+
+   The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
+   through 6, or can be a Leaf Printer, as in Figures 1 through 3.
+
+                    Figure 6.  IPP Printer Object Fan-In
+
+10.7.  Forwarding Requests
+
+   This section describes the forwarding of Job and Printer requests to
+   Subordinate Printer objects.
+
+10.7.1.  Forwarding Requests that Affect Printer Objects
+
+   In Printer Fan-Out, Printer Fan-In, and Chained Printers, the Non-
+   Leaf IPP Printer object MUST NOT forward the operations that affect
+   Printer objects to its Subordinate Printer objects.  If a client
+   seeks to explicitly target a Subordinate Printer, the client MUST
+   specify the URI of the Subordinate Printer.  The client can determine
+   the URI of any Subordinate Printers by querying the Printer's
+   "subordinate-printers-supported (1setOf uri) attribute (see section
+   7.1).
+
+   Table 7 lists the operations that affect Printer objects and the
+   forwarding behavior that a Non-Leaf Printer MUST exhibit to its
+   immediate Subordinate Printers.  Operations that affect jobs have a
+   different forwarding rule (see section 10.7.2 and Table 8):
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 33]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Table 7.  Forwarding Operations that Affect Printer Objects
+
+      Printer Operation     Non-Leaf Printer Action
+     ---------------------------------------------------------------
+    Printer Operations:
+
+      Enable-Printer      MUST NOT forward to any of its Subordinate
+                          Printers
+      Disable-Printer     MUST NOT forward to any of its Subordinate
+                          Printers
+      Hold-New-Jobs       MUST NOT forward to any of its Subordinate
+                          Printers
+      Release-Held-New-   MUST NOT forward to any of its Subordinate
+      Jobs                Printers
+      Deactivate-Printer  MUST NOT forward to any of its Subordinate
+                          Printers
+      Activate-Printer    MUST NOT forward to any of its Subordinate
+                          Printers
+      Restart-Printer     MUST NOT forward to any of its Subordinate
+                          Printers
+      Shutdown-Printer    MUST NOT forward to any of its Subordinate
+                          Printers
+      Startup-Printer     MUST NOT forward to any of its Subordinate
+                          Printers
+
+    IPP/1.1 Printer       See [RFC2911]
+    Operations:
+
+      Get-Printer-        MUST NOT forward to any of its Subordinate
+      Attributes          Printers
+      Pause-Printer       MUST NOT forward to any of its Subordinate
+                          Printers
+      Resume-Printer      MUST NOT forward to any of its Subordinate
+                          Printers
+
+    Set Operations:       See [RFC3380]
+
+      Set-Printer-        MUST NOT forward to any of its Subordinate
+      Attributes          Printers
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 34]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+10.7.2.  Forwarding Requests that Affect Jobs
+
+   Unlike Printer Operations that only affect Printer objects (see
+   section 10.7.1), a Non-Leaf Printer object MUST forward operations
+   that directly affect jobs to the appropriate Job object(s) in one or
+   more of its immediate Subordinate Printer objects.  Forwarding is
+   REQUIRED since the purpose of this Job operation is to affect the
+   indicated job, which may have been forwarded itself.  This forwarding
+   MAY be immediate or queued, depending on the operation and the
+   implementation.  For example, a Non-Leaf Printer object MAY
+   queue/spool jobs, feeding a job at a time to its Subordinate
+   Printer(s), or MAY forward jobs immediately to one of its Subordinate
+   Printers.  In either case, the Non-Leaf Printer object forwards Job
+   Creation operations to one of its Subordinate Printers.  Only the
+   time of forwarding of the Job Creation operations depends on whether
+   the policy is to queue/spool jobs in the Non-Leaf Printer or the
+   Subordinate Printer.
+
+   When a Non-Leaf Printer object creates a Job object in its
+   Subordinate Printer, whether that Non-Leaf Printer object keeps a
+   fully formed Job object or just keeps a mapping from the "job-ids"
+   that it assigned to those assigned by its Subordinate Printer object
+   is IMPLEMENTATION-DEPENDENT.  In either case, the Non-Leaf Printer
+   MUST be able to accept and carry out future Job operations that
+   specify the "job-id" that the Non-Leaf Printer assigned and returned
+   to the job submitting client.
+
+   Table 8 lists the operations that directly affect jobs and the
+   forwarding behavior that a Non-Leaf Printer MUST exhibit to its
+   Subordinate Printers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 35]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Table 8.  Forwarding Operations that Affect Jobs Objects
+
+      Operation         Non-Leaf Printer action
+    ---------------------------------------------------------------
+    Job operations:
+
+      Reprocess-Job     MUST forward to the appropriate Job in one of
+                        its Subordinate Printers
+      Cancel-Current-   MUST NOT forward
+      Job
+      Resume-Job        MUST forward to the appropriate Job in one of
+                        its Subordinate Printers
+      Promote-Job       MUST forward to the appropriate Job in one of
+                        its Subordinate Printers
+
+    IPP/1.1 Printer
+    operations:
+
+      Print-Job         MUST forward immediately or queue to the
+                        appropriate Subordinate Printer
+      Print-URI         MUST forward immediately or queue to the
+                        appropriate Subordinate Printer
+      Validate-Job      MUST forward to the appropriate Subordinate
+                        Printer
+      Create-Job        MUST forward immediately or queue to the
+                        appropriate Subordinate Printer
+      Get-Jobs          MUST forward to all its Subordinate Printers
+      Purge-Jobs        MUST forward to all its Subordinate Printers
+
+    IPP/1.1 Job
+    operations:
+
+      Send-Document     MUST forward immediately or queue to the
+                        appropriate Job in one of its Subordinate
+                        Printers
+      Send-URI          MUST forward immediately or queue to the
+                        appropriate Job in one of its Subordinate
+                        Printers
+      Cancel-Job        MUST forward to the appropriate Job in one of
+                        its Subordinate Printers
+      Get-Job-          MUST forward to the appropriate Job in one of
+      Attributes        its Subordinate Printers if the Non-Leaf
+                        Printer doesn't know the complete status of the
+                        Job object
+      Hold-Job          MUST forward to the appropriate Job in one of
+                        its Subordinate Printers
+      Release-Job       MUST forward to the appropriate Job in one of
+                        its Subordinate Printers
+
+
+
+Kugler, et al.              Standards Track                    [Page 36]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+      Restart-Job       MUST forward to the appropriate Job in one of
+                        its Subordinate Printers
+
+    IPP Set operations: See [RFC3380]
+
+      Set-Job-          MUST forward to the appropriate Job in one of
+      Attributes        its Subordinate Printers
+
+   When a Printer receives a request that REQUIRES forwarding, it does
+   so on a "best efforts basis" and returns a response to its client
+   without waiting for responses from any of its Subordinate Printers.
+   Such forwarded requests could fail.
+
+10.8.  Additional Attributes to Help with Fan-Out
+
+   The following operation and Job Description attributes are defined to
+   help represent Job relationships for Fan-Out and forwarding of jobs.
+
+10.8.1.  output-device-assigned (name(127)) Job Description Attribute -
+         from [RFC2911]
+
+   [RFC2911] defines "output-device-assigned" as follows:  "This
+   attribute identifies the Output Device to which the Printer object
+   has assigned this job.  If an Output Device implements an embedded
+   Printer object, the Printer object NEED NOT set this attribute.  If a
+   print server implements a Printer object, the value MAY be empty
+   (zero-length string) or not returned until the Printer object assigns
+   an Output Device to the job.  This attribute is particularly useful
+   when a single Printer object supports multiple devices (so called
+   "Device Fan-Out" see [RFC2911] section 2.1)."  See also section 10.1
+   in this specification.
+
+10.8.2.  original-requesting-user-name (name(MAX)) Operation and Job
+         Description Attribute
+
+   The operation attribute containing the user name of the original
+   user; i.e., corresponding to the "requesting-user-name" operation
+   attribute (see [RFC2911], section 3.2.1.1) that the original client
+   supplied to the first Printer object.  The Printer copies the
+   "original-requesting-user-name" operation attribute to the
+   corresponding Job Description attribute.
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 37]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+10.8.3.  requesting-user-name (name(MAX)) Operation Attribute -
+         Additional Semantics
+
+   The IPP/1.1 "requesting-user-name" operation attribute (see [RFC2911]
+   section 3.2.1.1) is updated by each client to be itself on each hop;
+   i.e., the "requesting-user-name" represents the client forwarding the
+   request, not the original client.
+
+10.8.4.  job-originating-user-name (name(MAX)) Job Description Attribute
+         - Additional Semantics
+
+   The "job-originating-user-name" Job Description attribute (see
+   [RFC2911], section 4.3.6) remains as the authenticated original user,
+   not the parent Printer's authenticated host, and is forwarded by each
+   client without changing the value.
+
+11.  Conformance Requirements
+
+   The Job and Printer Administrative operations defined in this
+   document are OPTIONAL operations.  However, some operations MUST be
+   implemented if others are implemented, as shown in Table 9.
+
+   Table 9.  Conformance Requirement Dependencies for Operations
+
+   Operations REQUIRED             If any of these operations are
+                                   supported:
+   --------------------------------------------------------------------
+   Enable-Printer                  Disable-Printer
+   Disable-Printer                 Enable-Printer
+   Pause-Printer                   Resume-Printer
+   Resume-Printer                  Pause-Printer,
+                                     Pause-Printer-After-Current-Job
+   Hold-New-Jobs                   Release-Held-New-Jobs
+   Release-Held-New-Jobs           Hold-New-Jobs
+   Activate-Printer,               Deactivate-Printer
+     Disable-Printer,
+     Pause-Printer-After-Current-Job
+   Deactivate-Printer,             Activate-Printer
+     Enable-Printer,
+     Resume-Printer
+   Restart-Printer                 none
+   Shutdown-Printer                none
+   Startup-Printer                 none
+   Reprocess-Job                   none
+   Cancel-Current-Job              none
+   Resume-Job                      Suspend-Current-Job
+   Suspend-Current-Job             Resume-Job
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 38]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Promote-Job                     none
+   Schedule-Job-After              Promote-Job
+
+   Tables 10 and 11 list the "printer-state-reasons" and "job-state-
+   reasons" values that are REQUIRED if the indicated operations are
+   supported.
+
+   Table 10.  Conformance Requirement Dependencies for
+              "printer-state-reasons" Values
+
+   "printer-state-       Conformance   If any of the following Printer
+   reasons" values:      Requirement   Operations are supported:
+   --------------------------------------------------------------------
+   'paused'              REQUIRED      Pause-Printer,
+                                       Pause-Printer-After-Current-Job,
+                                       or Deactivate-Printer
+   'hold-new-jobs'       REQUIRED      Hold-New-Jobs
+   'moving-to-paused'    OPTIONAL      Pause-Printer,
+                                       Pause-Printer-After-Current-Job,
+                                       Deactivate-Printer
+   'deactivated'         REQUIRED      Deactivate-Printer
+
+
+   Table 11.  Conformance Requirement Dependencies for "job-state-
+              reasons" Values
+
+   "job-state-reasons"   Conformance   If any of the following Job
+   values:               Requirement   operations are supported:
+
+   'job-suspended'       REQUIRED      Suspend-Current-Job
+   'printer-stopped'     REQUIRED      Always REQUIRED
+
+12.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+             RFC 2246, January 1999.
+
+   [RFC2616] Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
+             Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+             Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J.
+             Wenn, "Internet Printing Protocol/1.1: Encoding and
+             Transport", RFC 2910, September 2000.
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 39]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and P.
+             Powell, "Internet Printing Protocol/1.1: Model and
+             Semantics", RFC 2911, September 2000.
+
+   [RFC3380] Hastings, T., Herriot, R., Kugler, C., and H. Lewis,
+             "Internet Printing Protocol (IPP): Job and Printer Set
+             Operations", RFC 3380, September 2002.
+
+13.  Informative References
+
+   [RFC2567] Wright, F., "Design Goals for an Internet Printing
+             Protocol", RFC 2567, April 1999.
+
+   [RFC2568] Zilles, S., "Rationale for the Structure of the Model and
+             Protocol for the Internet Printing Protocol", RFC 2568,
+             April 1999.
+
+   [RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
+             "Mapping between LPD and IPP Protocols", RFC 2569, April
+             1999.
+
+   [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
+             Holst, "Internet Printing Protocol/1.1: Implementor's
+             Guide", RFC 3196, November 2001.
+
+   [RFC3239] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing
+             Protocol (IPP): Requirements for Job, Printer, and Device
+             Administrative Operations", RFC 3239, February 2002.
+
+   [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
+             (IPP): Event Notifications and Subscriptions", RFC 3995,
+             February 2005.
+
+14.  IANA Considerations
+
+   This section contains the registration information that IANA added to
+   the IPP Registry according to the procedures defined in [RFC2911],
+   section 6, to cover the definitions in this document.  The resulting
+   registrations have been published as additions to the
+   http://www.iana.org/assignments/ipp-registrations file.
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 40]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+14.1.  Attribute Registrations
+
+   The following table lists all the attributes defined in this
+   document.  These have been registered according to the procedures in
+   [RFC2911], section 6.2.
+
+   Name                                          Reference  Section
+   --------------------------------------        ---------  -------
+   Job Description attributes:
+   original-requesting-user-name (name(MAX))     [RFC3998]  10.8.2
+
+   Printer Description attributes:
+   subordinate-printers-supported (1setOf uri)   [RFC3998]  7.1
+   parent-printers-supported (1setOf uri)        [RFC3998]  7.2
+
+   Operation attributes:
+   original-requesting-user-name (name(MAX))     [RFC3998]  10.8.2
+
+14.2.  Attribute Value Registrations
+
+   This section lists the additional values defined in this document for
+   existing attributes.
+
+   Attribute
+     Value                                       Reference  Section
+     ---------------------                       ---------  -------
+   job-state-reasons (1setOf type2 keyword)
+     job-suspended                               [RFC3998]  9.1
+
+
+   printer-state-reasons (1setOf type2 keyword)
+     hold-new-jobs                               [RFC3998]  8.1
+     deactivated                                 [RFC3998]  8.2
+
+14.3.  Additional Enum Attribute Value Registrations
+
+   The following table lists all the new enum attribute values defined
+   in this document.  These have been registered according to the
+   procedures in [RFC2911], section 6.1.
+
+
+
+
+
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 41]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Attribute (attribute syntax)
+     Value    Name                                  Reference   Section
+   -------    --------------------                  ---------   -------
+   operations-supported (1setOf type2 enum)         [RFC2911]   4.4.1
+     0x0022   Enable-Printer                        [RFC3998]   3
+     0x0023   Disable-Printer                       [RFC3998]   3
+     0x0024   Pause-Printer-After-Current-Job       [RFC3998]   3
+     0x0025   Hold-New-Jobs                         [RFC3998]   3
+     0x0026   Release-Held-New-Jobs                 [RFC3998]   3
+     0x0027   Deactivate-Printer                    [RFC3998]   3
+     0x0028   Activate-Printer                      [RFC3998]   3
+     0x0029   Restart-Printer                       [RFC3998]   3
+     0x002A   Shutdown-Printer                      [RFC3998]   3
+     0x002B   Startup-Printer                       [RFC3998]   3
+     0x002C   Reprocess-Job                         [RFC3998]   4
+     0x002D   Cancel-Current-Job                    [RFC3998]   4
+     0x002E   Suspend-Current-Job                   [RFC3998]   4
+     0x002F   Resume-Job                            [RFC3998]   4
+     0x0030   Promote-Job                           [RFC3998]   4
+     0x0031   Schedule-Job-After                    [RFC3998]   4
+
+14.4.  Operation Registrations
+
+   The following table lists all the operations defined in this
+   document.  These have been registered according to the procedures in
+   [RFC2911], section 6.4.
+
+   Name                                         Reference   Section
+   -----------------------------                ---------   -------
+   Activate-Printer                             [RFC3998]   3.4.2
+   Cancel-Current-Job                           [RFC3998]   4.2
+   Deactivate-Printer                           [RFC3998]   3.4.1
+   Disable-Printer                              [RFC3998]   3.1.1
+   Enable-Printer                               [RFC3998]   3.1.2
+   Hold-New-Jobs                                [RFC3998]   3.3.1
+   Pause-Printer-After-Current-Job              [RFC3998]   3.2.1
+   Promote-Job                                  [RFC3998]   4.4.1
+   Release-Held-New-Jobs                        [RFC3998]   3.3.2
+   Reprocess-Job                                [RFC3998]   4.1
+   Restart-Printer                              [RFC3998]   3.5.1
+   Resume-Job                                   [RFC3998]   4.3.2
+   Schedule-Job-After                           [RFC3998]   4.4.2
+   Shutdown-Printer                             [RFC3998]   3.5.2
+   Startup-Printer                              [RFC3998]   3.5.3
+   Suspend-Current-Job                          [RFC3998]   4.3.1
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 42]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+14.5.  Status Code Registrations
+
+   The following table lists the status code defined in this document.
+   This has been registered according to the procedures in [RFC2911],
+   section 6.6.
+
+   Value   Name                                  Reference  Section
+   ------  ------------------------              ---------  -------
+   0x0000:0x00FF - "successful"
+   none at this time
+
+   0x0100:0x01FF - "informational"
+   none at this time
+
+   0x0300:0x03FF - "redirection"                 See RFC 2911 Errata
+   none at this time
+
+   0x0400:0x04FF - "client-error"
+   none at this time
+
+   0x0500:0x05FF - "server-error"
+   0x050A  server-error-printer-is-deactivated   [RFC3998]  5.1
+
+15.  Internationalization Considerations
+
+   This document has the same localization considerations as [RFC2911].
+
+16.  Security Considerations
+
+   The IPP Model and Semantics document [RFC2911] discusses high level
+   security requirements (Client Authentication, Server Authentication,
+   and Operation Privacy).  Client Authentication is the mechanism by
+   which the client proves its identity to the server in a secure
+   manner.  Server Authentication is the mechanism by which the server
+   proves its identity to the client in a secure manner.  Operation
+   Privacy is defined as a mechanism for protecting operations from
+   eavesdropping.
+
+   Printer operations defined in this specification (see section 3), as
+   well as Pause-Printer, Resume-Printer, and Purge-Job (defined in
+   [RFC2911]) are intended for use by an operator and/or administrator.
+   Job operations defined in this specification (see section 4) and
+   Cancel-Job, Hold-Job, and Release-Job (defined in [RFC2911]) are
+   intended for use by the job owner, operator, or administrator of the
+   Printer object.  These operator and administrator operations affect
+   service for all users.
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 43]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   Inappropriate use of an administrative operation by an
+   unauthenticated end user can affect the quality of service for all
+   users.  Therefore, IPP Printer implementations MUST support both
+   successful certificate-based TLS [RFC2246] client authentication and
+   successful operator/administrator authorization (see [RFC2911],
+   sections 5.2.7 and 8, and [RFC2910]) to perform the administrative
+   operations defined in this document.  [RFC2910] requires the IPP
+   Printer to support the minimum cipher suite specified for TLS/1.0.
+   The means for authorizing an operator or administrator of the Printer
+   object are outside the scope of this specification, RFC 2910, and RFC
+   2911.
+
+   The use of TLS and Client Authentication solves the Denial of
+   Service, Man in the Middle, and Masquerading security threats.
+
+17.  Summary of Base IPP Documents
+
+   The base set of IPP documents includes the following:
+
+      Design Goals for an Internet Printing Protocol [RFC2567]
+      Rationale for the Structure and Model and Protocol for the
+      Internet Printing Protocol [RFC2568]
+      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+      Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+      Mapping between LPD and IPP Protocols [RFC2569]
+
+   "Design Goals for an Internet Printing Protocol" takes a broad look
+   at distributed printing functionality, and it enumerates real-life
+   scenarios that help clarify the features that have to be included in
+   a printing protocol for the Internet.  It identifies requirements for
+   three types of users: end users, operators, and administrators.  It
+   calls out a subset of end user requirements that are satisfied in
+   IPP/1.0.  A few OPTIONAL operator operations have been added to
+   IPP/1.1.
+
+   "Rationale for the Structure and Model and Protocol for the Internet
+   Printing Protocol" describes IPP from a high level view, defines a
+   roadmap for the various documents that form the suite of IPP
+   specification documents, and gives background and rationale for the
+   IETF working group's major decisions.
+
+   "Internet Printing Protocol/1.1: Model and Semantics" describes a
+   simplified model with abstract objects, their attributes, and their
+   operations that are independent of encoding and transport.  It
+   introduces a Printer and a Job object.  The Job object optionally
+   supports multiple documents per Job.  It also addresses security,
+   internationalization, and directory issues.
+
+
+
+Kugler, et al.              Standards Track                    [Page 44]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+   "Internet Printing Protocol/1.1: Encoding and Transport" is a formal
+   mapping of the abstract operations and attributes defined in the
+   model document onto HTTP/1.1 [RFC2616].  It defines the encoding
+   rules for a new Internet MIME media type called "application/ipp".
+   This document also defines the rules for transporting over HTTP a
+   message body whose Content-Type is "application/ipp".  This document
+   defines the 'ippget' scheme for identifying IPP printers and jobs.
+
+   "Internet Printing Protocol/1.1: Implementer's Guide" gives insight
+   and advice to implementers of IPP clients and IPP objects.  It is
+   intended to help them understand IPP/1.1 and some of the
+   considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   "Mapping between LPD and IPP Protocols" gives some advice to
+   implementers of gateways between IPP and LPD (Line Printer Daemon)
+   implementations.
+
+Authors' Addresses
+
+   Carl Kugler
+   IBM Corporation, 003G
+   6300 Diagonal Hwy
+   Boulder, CO 80301
+
+   Phone: (303) 924-5060
+   EMail:  kugler@us.ibm.com
+
+
+   Tom Hastings, editor
+   Xerox Corporation
+   701 S Aviation Blvd.  ESAE 242
+   El Segundo, CA  90245
+
+   Phone: 310-333-6413
+   Fax: 310-333-6342
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Harry Lewis
+   IBM Corporation
+   6300 Diagonal Hwy
+   Boulder, CO 80301
+
+   Phone: (303) 924-5337
+   EMail: harryl@us.ibm.com
+
+
+
+Kugler, et al.              Standards Track                    [Page 45]
+
+RFC 3998            IPP: Job and Printer Operations           March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Kugler, et al.              Standards Track                    [Page 46]
+
diff --git a/standards/wd-ippmailto10-20050519.pdf b/standards/wd-ippmailto10-20050519.pdf
new file mode 100644
index 000000000..1ec8c996f
--- /dev/null
+++ b/standards/wd-ippmailto10-20050519.pdf