Import cups.org releases

git-svn-id: svn+ssh://src.apple.com/svn/cups/cups.org/tags/release-1.5b2@4306 a1ca3aef-8c08-0410-bb20-df032aa958be
2013-05-10 18:56:23 +00:00
@@ -1,13 +1,6 @@
 CHANGES-1.4.txt
 ---------------

-CHANGES IN CUPS V1.4.8
-
-	- The scheduler would delete job data files when restarted (STR #3880)
-	- The network backends could crash if a printer returned a value of 0
-	  for the maximum capacity for a supply (STR #3875)
-
-
 CHANGES IN CUPS V1.4.7

 	- Documentation changes (STR #3710, STR #3720, STR #3745, STR #3750,
@@ -16,7 +9,6 @@ CHANGES IN CUPS V1.4.7
 	  STR #3755, STR #3769, STR #3783)
 	- Configure script fixes (STR #3659, STR #3691)
 	- Compilation fixes (STR #3718, STR #3771, STR #3774)
-	- The imageto* filters could crash with bad GIF files (STR #3867)
 	- The scheduler might leave old job data files in the spool directory
 	  (STR #3795)
 	- CUPS did not work with locales using the ASCII character set
@@ -1,32 +1,6 @@
-CHANGES.txt - 2011-07-25
+CHANGES.txt - 2011-05-26
 ------------------------

-CHANGES IN CUPS V1.5.0
-
-	- Documentation updates.
-	- Localization update (STR #3865)
-	- Needed to limit TLS to v1.0 on some versions of Mac OS X.
-	- The snmp backend did not work with some printers.
-
-
-CHANGES IN CUPS V1.5rc1
-
-	- Compile fixes (STR #3849, STR #3850)
-	- The scheduler didn't check for empty values for several configuration
-	  directives (STR #3861)
-	- ipptool didn't generate valid XML when a test was skipped.
-	- Added additional error checking to the 1284 device ID code (STR #3858)
-	- Fixed some compatibility issues migrating from the old usblp backend
-	  to the libusb backend (STR #3860)
-	- Fixed the wake-from-sleep printing behavior on Mac OS X.
-	- The scheduler incorrectly allowed jobs to be held from a terminating
-	  state.
-	- The cups-driverd program could crash when a PPD was renamed.
-	- The dnssd backend took too long to discover printers on large or busy
-	  networks with the new default timeout used by lpinfo and the web
-	  interface. This resulted in "lost" printers.
-
-
 CHANGES IN CUPS V1.5b2

 	- Documentation updates.
@@ -1,4 +1,4 @@
-INSTALL - CUPS v1.5.0 - 2011-07-25
+INSTALL - CUPS v1.5b2 - 2011-05-26
 ----------------------------------

 This file describes how to compile and install CUPS from source code. For more
@@ -1,5 +1,5 @@
-README - CUPS v1.5.0 - 2011-07-25
----------------------------------
+README - CUPS v1.5b2 - 2011-05-26
+---------------------------------

 Looking for compile instructions?  Read the file "INSTALL.txt"
 instead...
@@ -44,7 +44,6 @@ typedef enum
 {
  CUPS_DEVICE_PRINTER = 0,		/* lpd://... */
  CUPS_DEVICE_IPP,			/* ipp://... */
-  CUPS_DEVICE_IPPS,			/* ipps://... */
  CUPS_DEVICE_FAX_IPP,			/* ipp://... */
  CUPS_DEVICE_PDL_DATASTREAM,		/* socket://... */
  CUPS_DEVICE_RIOUSBPRINT		/* riousbprint://... */
@@ -124,11 +123,9 @@ main(int  argc,				/* I - Number of command-line args */
 		fax_ipp_ref,		/* IPP fax service reference */
 		ipp_ref,		/* IPP service reference */
 		ipp_tls_ref,		/* IPP w/TLS service reference */
-		ipps_ref,		/* IPP service reference */
 		local_fax_ipp_ref,	/* Local IPP fax service reference */
 		local_ipp_ref,		/* Local IPP service reference */
 		local_ipp_tls_ref,	/* Local IPP w/TLS service reference */
-		local_ipps_ref,		/* Local IPP service reference */
 		local_printer_ref,	/* Local LPD service reference */
 		pdl_datastream_ref,	/* AppSocket service reference */
 		printer_ref,		/* LPD service reference */
@@ -218,10 +215,6 @@ main(int  argc,				/* I - Number of command-line args */
  DNSServiceBrowse(&ipp_tls_ref, kDNSServiceFlagsShareConnection, 0,
                   "_ipp-tls._tcp", NULL, browse_callback, devices);

-  ipps_ref = main_ref;
-  DNSServiceBrowse(&ipp_ref, kDNSServiceFlagsShareConnection, 0,
-                   "_ipps._tcp", NULL, browse_callback, devices);
-
  local_fax_ipp_ref = main_ref;
  DNSServiceBrowse(&local_fax_ipp_ref, kDNSServiceFlagsShareConnection,
                   kDNSServiceInterfaceIndexLocalOnly,
@@ -237,11 +230,6 @@ main(int  argc,				/* I - Number of command-line args */
                   kDNSServiceInterfaceIndexLocalOnly,
                   "_ipp-tls._tcp", NULL, browse_local_callback, devices);

-  local_ipps_ref = main_ref;
-  DNSServiceBrowse(&local_ipp_ref, kDNSServiceFlagsShareConnection,
-                   kDNSServiceInterfaceIndexLocalOnly,
-		   "_ipps._tcp", NULL, browse_local_callback, devices);
-
  local_printer_ref = main_ref;
  DNSServiceBrowse(&local_printer_ref, kDNSServiceFlagsShareConnection,
                   kDNSServiceInterfaceIndexLocalOnly,
@@ -268,8 +256,8 @@ main(int  argc,				/* I - Number of command-line args */
    FD_ZERO(&input);
    FD_SET(fd, &input);

-    timeout.tv_sec  = 0;
-    timeout.tv_usec = 250000;
+    timeout.tv_sec  = 1;
+    timeout.tv_usec = 0;

    if (select(fd + 1, &input, NULL, NULL, &timeout) < 0)
      continue;
@@ -292,26 +280,19 @@ main(int  argc,				/* I - Number of command-line args */
      cups_device_t *best;		/* Best matching device */
      char	device_uri[1024];	/* Device URI */
      int	count;			/* Number of queries */
-      int	sent;			/* Number of sent */
+

      for (device = (cups_device_t *)cupsArrayFirst(devices),
-               best = NULL, count = 0, sent = 0;
+               best = NULL, count = 0;
           device;
 	   device = (cups_device_t *)cupsArrayNext(devices))
-      {
-        if (device->sent)
-	  sent ++;
-
-        if (device->ref)
-	  count ++;
-
        if (!device->ref && !device->sent)
 	{
 	 /*
 	  * Found the device, now get the TXT record(s) for it...
 	  */

-          if (count < 20)
+          if (count < 10)
 	  {
 	    device->ref = main_ref;

@@ -357,8 +338,6 @@ main(int  argc,				/* I - Number of command-line args */
 	                      best->name, best->device_id, NULL);
 	    best->sent = 1;
 	    best       = device;
-
-	    sent ++;
 	  }
 	  else if (best->priority > device->priority ||
 	           (best->priority == device->priority &&
@@ -366,17 +345,10 @@ main(int  argc,				/* I - Number of command-line args */
          {
 	    best->sent = 1;
 	    best       = device;
-
-	    sent ++;
 	  }
 	  else
-	  {
 	    device->sent = 1;
-
-	    sent ++;
-	  }
        }
-      }

      if (best)
      {
@@ -389,11 +361,7 @@ main(int  argc,				/* I - Number of command-line args */
 	cupsBackendReport("network", device_uri, best->make_and_model,
 			  best->name, best->device_id, NULL);
 	best->sent = 1;
-	sent ++;
      }
-
-      if (sent == cupsArrayCount(devices))
-	break;
    }
  }

@@ -590,11 +558,9 @@ get_device(cups_array_t *devices,	/* I - Device array */

  key.name = (char *)serviceName;

-  if (!strcmp(regtype, "_ipp._tcp."))
+  if (!strcmp(regtype, "_ipp._tcp.") ||
+      !strcmp(regtype, "_ipp-tls._tcp."))
    key.type = CUPS_DEVICE_IPP;
-  else if (!strcmp(regtype, "_ipps._tcp.") ||
-	   !strcmp(regtype, "_ipp-tls._tcp."))
-    key.type = CUPS_DEVICE_IPPS;
  else if (!strcmp(regtype, "_fax-ipp._tcp."))
    key.type = CUPS_DEVICE_FAX_IPP;
  else if (!strcmp(regtype, "_printer._tcp."))
@@ -714,11 +680,9 @@ query_callback(
  if ((ptr = strstr(name, "._")) != NULL)
    *ptr = '\0';

-  if (strstr(fullName, "_ipp._tcp."))
+  if (strstr(fullName, "_ipp._tcp.") ||
+      strstr(fullName, "_ipp-tls._tcp."))
    dkey.type = CUPS_DEVICE_IPP;
-  else if (strstr(fullName, "_ipps._tcp.") ||
-           strstr(fullName, "_ipp-tls._tcp."))
-    dkey.type = CUPS_DEVICE_IPPS;
  else if (strstr(fullName, "_fax-ipp._tcp."))
    dkey.type = CUPS_DEVICE_FAX_IPP;
  else if (strstr(fullName, "_printer._tcp."))
@@ -790,16 +754,9 @@ query_callback(
 	  if (data < datanext)
 	    memcpy(value, data, datanext - data);
 	  value[datanext - data] = '\0';
-
-	  fprintf(stderr, "DEBUG2: query_callback: \"%s=%s\".\n",
-	          key, value);
 	}
 	else
-	{
-	  fprintf(stderr, "DEBUG2: query_callback: \"%s\" with no value.\n",
-	          key);
 	  continue;
-	}

        if (!_cups_strncasecmp(key, "usb_", 4))
 	{
@@ -843,7 +800,6 @@ query_callback(
 	else if (!_cups_strcasecmp(key, "priority"))
 	  device->priority = atoi(value);
 	else if ((device->type == CUPS_DEVICE_IPP ||
-	          device->type == CUPS_DEVICE_IPPS ||
 	          device->type == CUPS_DEVICE_PRINTER) &&
 		 !_cups_strcasecmp(key, "printer-type"))
 	{
@@ -65,7 +65,6 @@ backendGetDeviceID(
 #  if defined(__sun) && defined(ECPPIOC_GETDEVID)
  struct ecpp_device_id did;		/* Device ID buffer */
 #  endif /* __sun && ECPPIOC_GETDEVID */
-  char	*ptr;				/* Pointer into device ID */


  DEBUG_printf(("backendGetDeviceID(fd=%d, device_id=%p, device_id_size=%d, "
@@ -187,7 +186,7 @@ backendGetDeviceID(
      * and then limit the length to the size of our buffer...
      */

-      if (length > device_id_size || length < 14)
+      if (length > device_id_size)
 	length = (((unsigned)device_id[1] & 255) << 8) +
 		 ((unsigned)device_id[0] & 255);

@@ -225,12 +224,11 @@ backendGetDeviceID(
 	device_id[length] = '\0';
      }
    }
+#    ifdef DEBUG
    else
-    {
      DEBUG_printf(("backendGetDeviceID: ioctl failed - %s\n",
                    strerror(errno)));
-      *device_id = '\0';
-    }
+#    endif /* DEBUG */
 #  endif /* __linux */

 #   if defined(__sun) && defined(ECPPIOC_GETDEVID)
@@ -258,22 +256,6 @@ backendGetDeviceID(
 #  endif /* __sun && ECPPIOC_GETDEVID */
  }

- /*
-  * Check whether device ID is valid. Turn line breaks and tabs to spaces and
-  * reject device IDs with non-printable characters.
-  */
-
-  for (ptr = device_id; *ptr; ptr ++)
-    if (_cups_isspace(*ptr))
-      *ptr = ' ';
-    else if ((*ptr & 255) < ' ' || *ptr == 127)
-    {
-      DEBUG_printf(("backendGetDeviceID: Bad device_id character %d.",
-                    *ptr & 255));
-      *device_id = '\0';
-      break;
-    }
-
  DEBUG_printf(("backendGetDeviceID: device_id=\"%s\"\n", device_id));

  if (scheme && uri)
@@ -436,7 +436,10 @@ backendWaitLoop(
 {
  fd_set	input;			/* Input set for reading */
  time_t	curtime,		/* Current time */
-		snmp_update = 0;	/* Last SNMP status update */
+		snmp_update = 0;
+#if defined(HAVE_SIGACTION) && !defined(HAVE_SIGSET)
+  struct sigaction action;		/* Actions for POSIX signals */
+#endif /* HAVE_SIGACTION && !HAVE_SIGSET */


  fprintf(stderr, "DEBUG: backendWaitLoop(snmp_fd=%d, addr=%p, side_cb=%p)\n",
@@ -948,7 +948,7 @@ read_snmp_response(int fd)		/* I - SNMP socket file descriptor */
  debug_printf("DEBUG: request-id=%d\n", packet.request_id);
  debug_printf("DEBUG: error-status=%d\n", packet.error_status);

-  if (packet.error_status && packet.request_id != DEVICE_TYPE)
+  if (packet.error_status)
    return;

 /*
@@ -505,7 +505,6 @@ make_device_uri(
 		*mdl,			/* Model */
 		*des,			/* Description */
 		*sern;			/* Serial number */
-  size_t	mfglen;			/* Length of manufacturer string */
  char		tempmfg[256],		/* Temporary manufacturer string */
 		tempsern[256],		/* Temporary serial number string */
 		*tempptr;		/* Pointer into temp string */
@@ -585,16 +584,6 @@ make_device_uri(
    mfg = tempmfg;
  }

-  mfglen = strlen(mfg);
-
-  if (!strncasecmp(mdl, mfg, mfglen) && _cups_isspace(mdl[mfglen]))
-  {
-    mdl += mfglen + 1;
-
-    while (_cups_isspace(*mdl))
-      mdl ++;
-  }
-
 /*
  * Generate the device URI from the manufacturer, model, serial number,
  * and interface number...
@@ -747,87 +736,7 @@ print_cb(usb_printer_t *printer,	/* I - Printer */
         const char    *device_id,	/* I - IEEE-1284 device ID */
         const void    *data)		/* I - User data (make, model, S/N) */
 {
-  char	requested_uri[1024],		/* Requested URI */
-	*requested_ptr,			/* Pointer into requested URI */
-	detected_uri[1024],		/* Detected URI */
-	*detected_ptr;			/* Pointer into detected URI */
-
-
- /*
-  * If we have an exact match, stop now...
-  */
-
-  if (!strcmp((char *)data, device_uri))
-    return (1);
-
- /*
-  * Work on copies of the URIs...
-  */
-
-  strlcpy(requested_uri, (char *)data, sizeof(requested_uri));
-  strlcpy(detected_uri, device_uri, sizeof(detected_uri));
-
- /*
-  * libusb-discovered URIs can have an "interface" specification and this
-  * never happens for usblp-discovered URIs, so remove the "interface"
-  * specification from the URI which we are checking currently. This way a
-  * queue for a usblp-discovered printer can now be accessed via libusb.
-  *
-  * Similarly, strip "?serial=NNN...NNN" as needed.
-  */
-
-  if ((requested_ptr = strstr(requested_uri, "?interface=")) == NULL)
-    requested_ptr = strstr(requested_uri, "&interface=");
-  if ((detected_ptr = strstr(detected_uri, "?interface=")) == NULL)
-    detected_ptr = strstr(detected_uri, "&interface=");
-
-  if (!requested_ptr && detected_ptr)
-  {
-   /*
-    * Strip "[?&]interface=nnn" from the detected printer.
-    */
-
-    *detected_ptr = '\0';
-  }
-  else if (requested_ptr && !detected_ptr)
-  {
-   /*
-    * Strip "[?&]interface=nnn" from the requested printer.
-    */
-
-    *requested_ptr = '\0';
-  }
-
-  if ((requested_ptr = strstr(requested_uri, "?serial=?")) != NULL)
-  {
-   /*
-    * Strip "?serial=?" from the requested printer.  This is a special
-    * case, as "?serial=?" means no serial number and not the serial
-    * number '?'.  This is not covered by the checks below...
-    */
-
-    *requested_ptr = '\0';
-  }
-
-  if ((requested_ptr = strstr(requested_uri, "?serial=")) == NULL &&
-      (detected_ptr = strstr(detected_uri, "?serial=")) != NULL)
-  {
-   /*
-    * Strip "?serial=nnn" from the detected printer.
-    */
-
-    *detected_ptr = '\0';
-  }
-  else if (requested_ptr && !detected_ptr)
-  {
-   /*
-    * Strip "?serial=nnn" from the requested printer.
-    */
-
-    *requested_ptr = '\0';
-  }
-
-  return (!strcmp(requested_uri, detected_uri));
+  return (!strcmp((char *)data, device_uri));
 }


@@ -1,5 +1,5 @@
 dnl
-dnl "$Id: cups-common.m4 9839 2011-06-19 04:30:07Z mike $"
+dnl "$Id: cups-common.m4 9810 2011-05-26 12:34:56Z mike $"
 dnl
 dnl   Common configuration stuff for CUPS.
 dnl
@@ -20,7 +20,7 @@ dnl Set the name of the config header file...
 AC_CONFIG_HEADER(config.h)

 dnl Version number information...
-CUPS_VERSION="1.5.0"
+CUPS_VERSION="1.5b2"
 CUPS_REVISION=""
 #if test -z "$CUPS_REVISION" -a -d .svn; then
 #	CUPS_REVISION="-r`svnversion . | awk -F: '{print $NF}' | sed -e '1,$s/[[a-zA-Z]]*//g'`"
@@ -406,7 +406,7 @@ AC_ARG_WITH(components, [  --with-components       set components to build:

 case "$COMPONENTS" in
 	all)
-		BUILDDIRS="filter backend berkeley cgi-bin driver monitor notifier ppdc scheduler systemv conf data desktop locale man doc examples templates"
+		BUILDDIRS="filter backend berkeley cgi-bin driver monitor notifier ppdc scheduler systemv conf data locale man doc examples templates"
 		;;

 	core)
@@ -421,5 +421,5 @@ esac
 AC_SUBST(BUILDDIRS)

 dnl
-dnl End of "$Id: cups-common.m4 9839 2011-06-19 04:30:07Z mike $".
+dnl End of "$Id: cups-common.m4 9810 2011-05-26 12:34:56Z mike $".
 dnl
@@ -1,5 +1,5 @@
 dnl
-dnl "$Id: cups-compiler.m4 9818 2011-06-10 21:16:18Z mike $"
+dnl "$Id: cups-compiler.m4 9809 2011-05-26 12:24:20Z mike $"
 dnl
 dnl   Compiler stuff for CUPS.
 dnl
@@ -162,7 +162,7 @@ if test -n "$GCC"; then
 		else
 			AC_MSG_CHECKING(if GCC supports -Wno-tautological-compare)
 			OLDCFLAGS="$CFLAGS"
-			CFLAGS="$CFLAGS -Werror -Wno-tautological-compare"
+			CFLAGS="$CFLAGS -Wno-tautological-compare"
 			AC_TRY_COMPILE(,,
 				[OPTIM="$OPTIM -Wno-tautological-compare"
 				AC_MSG_RESULT(yes)],
@@ -560,5 +560,5 @@ case $uname in
 esac

 dnl
-dnl End of "$Id: cups-compiler.m4 9818 2011-06-10 21:16:18Z mike $".
+dnl End of "$Id: cups-compiler.m4 9809 2011-05-26 12:24:20Z mike $".
 dnl
@@ -1,5 +1,5 @@
 dnl
-dnl "$Id: cups-ssl.m4 9837 2011-06-16 20:12:16Z mike $"
+dnl "$Id: cups-ssl.m4 9756 2011-05-11 00:52:08Z mike $"
 dnl
 dnl   OpenSSL/GNUTLS stuff for CUPS.
 dnl
@@ -56,12 +56,6 @@ if test x$enable_ssl != xno; then
 		AC_CHECK_HEADER(Security/SecIdentitySearchPriv.h,
 		    AC_DEFINE(HAVE_SECIDENTITYSEARCHPRIV_H))

-		dnl Check for SSLSetProtocolVersionMax...
-		SAVELIBS="$LIBS"
-		LIBS="$LIBS -framework Security"
-		AC_CHECK_FUNC(SSLSetProtocolVersionMax)
-		LIBS="$SAVELIBS"
-
 		dnl Check for SecCertificateCopyData..
 		AC_MSG_CHECKING(for SecCertificateCopyData)
 		if test $uversion -ge 100; then
@@ -175,5 +169,5 @@ AC_SUBST(EXPORT_SSLLIBS)


 dnl
-dnl End of "$Id: cups-ssl.m4 9837 2011-06-16 20:12:16Z mike $".
+dnl End of "$Id: cups-ssl.m4 9756 2011-05-11 00:52:08Z mike $".
 dnl
@@ -342,13 +342,6 @@
 #undef HAVE_SECPOLICYCREATESSL


-/*
- * Do we have the SSLSetProtocolVersionMax function?
- */
-
-#undef HAVE_SSLSETPROTOCOLVERSIONMAX
-
-
 /*
 * Do we have the cssmErrorString function?
 */
@@ -270,7 +270,7 @@ cupsResolveConflicts(
 	  * Resolver loop!
 	  */

-	  DEBUG_printf(("1cupsResolveConflicts: Resolver loop with %s!",
+	  DEBUG_printf(("1ppdResolveConflicts: Resolver loop with %s!",
 	                consts->resolver));
          goto error;
 	}
@@ -278,14 +278,14 @@ cupsResolveConflicts(
        if ((resolver = ppdFindAttr(ppd, "cupsUIResolver",
 	                            consts->resolver)) == NULL)
        {
-	  DEBUG_printf(("1cupsResolveConflicts: Resolver %s not found!",
+	  DEBUG_printf(("1ppdResolveConflicts: Resolver %s not found!",
 	                consts->resolver));
 	  goto error;
 	}

        if (!resolver->value)
 	{
-	  DEBUG_printf(("1cupsResolveConflicts: Resolver %s has no value!",
+	  DEBUG_printf(("1ppdResolveConflicts: Resolver %s has no value!",
 	                consts->resolver));
 	  goto error;
 	}
@@ -507,7 +507,7 @@ cupsResolveConflicts(

    if (!changed)
    {
-      DEBUG_puts("1cupsResolveConflicts: Unable to automatically resolve "
+      DEBUG_puts("1ppdResolveConflicts: Unable to automatically resolve "
 		 "constraint!");
      goto error;
    }
@@ -39,7 +39,6 @@
 *   cupsFilePeekChar()     - Peek at the next character from a file.
 *   cupsFilePrintf()       - Write a formatted string.
 *   cupsFilePutChar()      - Write a character.
- *   cupsFilePutConf()      - Write a configuration line.
 *   cupsFilePuts()         - Write a string.
 *   cupsFileRead()         - Read from a file.
 *   cupsFileRewind()       - Set the current file position to the beginning of
@@ -53,7 +52,6 @@
 *   cupsFileWrite()        - Write to a file.
 *   cups_compress()        - Compress a buffer of data.
 *   cups_fill()            - Fill the input buffer.
- *   cups_open()            - Safely open a file for writing.
 *   cups_read()            - Read from a file descriptor.
 *   cups_write()           - Write to a file descriptor.
 */
@@ -466,7 +466,7 @@ _httpAssembleUUID(const char *server,	/* I - Server name */

  snprintf(data, sizeof(data), "%s:%d:%s:%d:%04x:%04x", server,
           port, name ? name : server, number,
-	   (unsigned)CUPS_RAND() & 0xffff, (unsigned)CUPS_RAND() & 0xffff);
+	   CUPS_RAND() & 0xffff, CUPS_RAND() & 0xffff);

  _cupsMD5Init(&md5state);
  _cupsMD5Append(&md5state, (unsigned char *)data, strlen(data));
@@ -3920,15 +3920,6 @@ http_setup_ssl(http_t *http)		/* I - Connection to server */
                  cg->expired_root, (int)error));
  }

-#    ifdef HAVE_SSLSETPROTOCOLVERSIONMAX
-  if (!error)
-  {
-    error = SSLSetProtocolVersionMax(http->tls, kTLSProtocol1);
-    DEBUG_printf(("4http_setup_ssl: SSLSetProtocolVersionMax(kTLSProtocol1), "
-                  "error=%d", (int)error));
-  }
-#    endif /* HAVE_SSLSETPROTOCOLVERSIONMAX */
-
 #    ifdef HAVE_SECCERTIFICATECOPYDATA
  if (!error)
  {
@@ -171,17 +171,16 @@ cupsCharsetToUTF8(

  if (map_to_utf8 != (iconv_t)-1)
  {
-    char *altdestptr = (char *)dest;	/* Silence bogus GCC type-punned */
-
    srclen       = strlen(src);
    outBytesLeft = maxout - 1;

-    iconv(map_to_utf8, (char **)&src, &srclen, &altdestptr, &outBytesLeft);
-    *altdestptr = '\0';
+    iconv(map_to_utf8, (char **)&src, &srclen, (char **)&destptr,
+	  &outBytesLeft);
+    *destptr = '\0';

    _cupsMutexUnlock(&map_mutex);

-    return ((int)(altdestptr - (char *)dest));
+    return ((int)(destptr - dest));
  }

  _cupsMutexUnlock(&map_mutex);
@@ -296,12 +295,10 @@ cupsUTF8ToCharset(

  if (map_from_utf8 != (iconv_t)-1)
  {
-    char *altsrc = (char *)src;		/* Silence bogus GCC type-punned */
-
    srclen       = strlen((char *)src);
    outBytesLeft = maxout - 1;

-    iconv(map_from_utf8, &altsrc, &srclen, &destptr, &outBytesLeft);
+    iconv(map_from_utf8, (char **)&src, &srclen, &destptr, &outBytesLeft);
    *destptr = '\0';

    _cupsMutexUnlock(&map_mutex);
@@ -8,7 +8,11 @@

 <H1 CLASS="title">Using Kerberos Authentication</H1>

-<P>CUPS allows you to use a Key Distribution Center (KDC) for authentication on your local CUPS server and when printing to a remote authenticated queue. This document describes how to configure CUPS to use Kerberos authentication and provides links to the MIT help pages for configuring Kerberos on your systems and network.</P>
+<P>CUPS allows you to use a Key Distribution Center (KDC) for authentication
+on your local CUPS server and when printing to a remote authenticated queue.
+This document describes how to configure CUPS to use Kerberos authentication
+and provides links to the MIT help pages for configuring Kerberos on your
+systems and network.</P>


 <H2 CLASS="title"><A NAME="REQUIREMENTS">System Requirements</A></H2>
@@ -19,31 +23,42 @@

 	<li>Heimdal Kerberos (any version) or MIT Kerberos (1.6.3 or newer)</li>

-	<li>Properly configured Domain Name System (DNS) infrastructure (for your servers):<ol type='a'>
-		<li>DNS server(s) with static IP addresses for all CUPS servers or configured to allow DHCP updates to the host addresses and</li>
+	<li>Properly configured Domain Name System (DNS)
+	infrastructure:<ol type='a'>
+		<li>DNS server(s) with static IP addresses for all CUPS clients
+		and servers or configured to allow DHCP updates to the host
+		addresses</li>
 		<li>All CUPS clients and servers configured to use the same
-DNS server(s).</li>
+		DNS server(s)</li>
 	</ol></li>

 	<li>Properly configured Kerberos infrastructure:<ol type='a'>
-		<li>KDC configured to allow CUPS servers to obtain Service Granting Tickets (SGTs) for the "host" service,</li>
-		<li>LDAP-based user accounts - both OpenDirectory and ActiveDirectory provide this with the KDC, and</li>
-		<li>CUPS clients and servers bound to the same KDC and LDAP
-	server(s).</li>
+		<li>KDC configured to allow CUPS clients and servers to obtain
+		Service Granting Tickets (SGTs) for the "ipp" service</li>
+		<li>LDAP-based user accounts - both OpenDirectory and
+		ActiveDirectory provide this with the KDC</li>
+		<li>CUPS clients and servers bound to the KDC and LDAP
+		server(s)</li>
 	</ol></li>

-	<li>A "host" Service Granting Ticket (SGT) for every CUPS server</li>
+	<li>An "ipp" Service Granting Ticket (SGT) for every CUPS client and
+	server</li>

 </ol>


 <H2 CLASS="title"><A NAME="KRB5">Configuring Kerberos on Your System</A></H2>

-<P>Before you can use Kerberos with CUPS, you will need to configure Kerberos on your system and setup a system as a KDC. Because this configuration is highly system and site-specific, please consult the following on-line resources provided by the creators of Kerberos at the Massachusetts Institute of Technology (MIT):</P>
+<P>Before you can use Kerberos with CUPS, you will need to configure
+Kerberos on your system and setup a system as a KDC. Because this
+configuration is highly system and site-specific, please consult
+the following on-line resources provided by the creators of Kerberos
+at the Massachusetts Institute of Technology (MIT):</P>

 <UL>

-	<LI><A HREF="http://web.mit.edu/kerberos/">Kerberos: The Network Authentication Protocol</A></LI>
+	<LI><A HREF="http://web.mit.edu/kerberos/">Kerberos: The Network
+	Authentication Protocol</A></LI>

 	<LI><A HREF="http://web.mit.edu/macdev/KfM/Common/Documentation/faq-osx.html">Kerberos
 	on Mac OS X Frequently Asked Questions</A></LI>
@@ -62,28 +77,46 @@ DNS server(s).</li>

 <H2 CLASS="title"><A NAME="CUPS">Configuring CUPS to Use Kerberos</A></H2>

-<P>Once youhave configured Kerberos on your system(s), you can then enable Kerberos authentication by selecting the <tt>Negotiate</tt> authentication type. The simplest way to do this is using the <tt>cupsctl(8)</tt> command on your server(s):</P>
+<P>Once you have configured Kerberos on your system(s), you can then
+enable Kerberos authentication by selecting the <tt>Negotiate</tt>
+authentication type. The simplest way to do this is using the
+<tt>cupsctl(8)</tt> command:</P>

 <PRE CLASS="command">
 <KBD>cupsctl DefaultAuthType=Negotiate</KBD>
 </PRE>

-<P>You can also enable Kerberos from the web interface by checking the <VAR>Use Kerberos Authentication</VAR> box and clicking <VAR>Change Settings</VAR>:</P>
+<P>You can also enable Kerberos from the web interface by checking the
+<VAR>Use Kerberos Authentication</VAR> box and clicking <VAR>Change
+Settings</VAR>:</P>

 <PRE CLASS="command">
-http://server.example.com:631/admin
+http://localhost:631/admin
 </PRE>

-<P>After you have enabled Kerberos authentication, use the built-in "authenticated" policy or your own custom policies with the printers you will be sharing. See <a href="policies.html">Managing Operation Policies</a> for more information.</P>
+<P>After you have enabled Kerberos authentication, use the built-in
+"authenticated" policy or your own custom policies with the printers you
+will be sharing. See <a href="policies.html">Managing Operation Policies</a>
+for more information.</P>


 <H2 CLASS="title"><A NAME="IMPLEMENT">Implementation Information</A></H2>

-<P>CUPS implements Kerberos over HTTP using GSSAPI and the service name "host". Because of limitations in the HTTP GSSAPI protocol extension, only a single domain/KDC is supported for authentication. The HTTP extension is described in <a href="http://tools.ietf.org/html/rfc4559">RFC 4559</a>.</P>
+<P>CUPS implements Kerberos over HTTP using GSSAPI and the service name
+"host". Because of limitations in the HTTP GSSAPI protocol extension, only
+a single domain/KDC is supported for authentication.</P>

-<P>When doing printing tasks that require authentication, CUPS requests single-use "tickets" from your login session to authenticate who you are. These tickets give CUPS a username of the form "user@REALM", which is then converted to just "user" for purposes of user and group checks.</P>
+<P>When doing printing tasks that require authentication, CUPS requests a
+single-use "ticket" from your login session to authenticate who you are.
+This ticket gives CUPS a username of the form "user@REALM", which is then
+converted to just "user" for purposes of user and group checks.</P>

-<P>In order to support printing to a shared printer, CUPS runs the IPP backend as the owner of the print job so it can obtain the necessary credentials.</P>
+<P>In order to support printing to a shared printer, CUPS has to ask the KDC
+for a copy of your credentials (this is called delegation) that can be sent to
+the remote server for authentication. Delegation only works when the system
+has a stable hostname which maps to the current address of the system, which
+is why you need a static IP address or DHCP that updates the DNS entry for your
+system.</P>

 </BODY>
 </HTML>
@@ -341,7 +341,7 @@ div.contents ul.subcontents li {
 <body>
 <div class='body'>
 <!--
-  "$Id: spec-ppd.html 9813 2011-06-01 17:00:27Z mike $"
+  "$Id: spec-ppd.html 9803 2011-05-26 02:11:20Z mike $"

  PPD extension documentation for CUPS.

@@ -604,10 +604,9 @@ f(x) = density * x <sup style='font-size: 100%'>gamma</sup>

 <h4>Customizing the Profile Selection Keywords</h4>

-<p>The <tt>ColorModel</tt>, <tt>MediaType</tt>, and <tt>Resolution</tt> main keywords can be reassigned to different main keywords, allowing drivers to do color profile selection based on different parameters. The <tt>cupsICCQualifier1</tt>, <tt>cupsICCQualifier2</tt>, and <tt>cupsICCQualifier3</tt> keywords define the mapping from selector to main keyword:</p>
+<p>The <tt>MediaType</tt> and <tt>Resolution</tt> main keywords can be reassigned to different main keywords, allowing drivers to do color profile selection based on different parameters. The <tt>cupsICCQualifier2</tt> and <tt>cupsICCQualifier3</tt> keywords define the mapping from selector to main keyword:</p>

 <pre class='command'>
-*cupsICCQualifier1: MainKeyword1
 *cupsICCQualifier2: MainKeyword2
 *cupsICCQualifier3: MainKeyword3
 </pre>
@@ -615,7 +614,6 @@ f(x) = density * x <sup style='font-size: 100%'>gamma</sup>
 <p>The default mapping is as follows:</p>

 <pre class='command'>
-*cupsICCQualifier1: ColorModel
 *cupsICCQualifier2: MediaType
 *cupsICCQualifier3: Resolution
 </pre>
@@ -353,7 +353,7 @@ gif_get_code(FILE *fp,			/* I - File to read from */
    * Read in another buffer...
    */

-    if ((count = gif_get_block(fp, buf + last_byte)) <= 0)
+    if ((count = gif_get_block (fp, buf + last_byte)) <= 0)
    {
     /*
      * Whoops, no more data!
@@ -582,13 +582,19 @@ gif_read_lzw(FILE *fp,			/* I - File to read from */
    gif_get_code(fp, 0, 1);

   /*
-    * Wipe the decompressor table (already mostly 0 due to the calloc above...)
+    * Wipe the decompressor table...
    */

    fresh = 1;

-    for (i = 1; i < clear_code; i ++)
+    for (i = 0; i < clear_code; i ++)
+    {
+      table[0][i] = 0;
      table[1][i] = i;
+    }
+
+    for (; i < 4096; i ++)
+      table[0][i] = table[1][0] = 0;

    sp = stack;

@@ -599,30 +605,29 @@ gif_read_lzw(FILE *fp,			/* I - File to read from */
    fresh = 0;

    do
-    {
      firstcode = oldcode = gif_get_code(fp, code_size, 0);
-    }
    while (firstcode == clear_code);

-    return (firstcode & 255);
+    return (firstcode);
  }
  else if (!table)
    return (0);

  if (sp > stack)
-    return ((*--sp) & 255);
+    return (*--sp);

-  while ((code = gif_get_code(fp, code_size, 0)) >= 0)
+  while ((code = gif_get_code (fp, code_size, 0)) >= 0)
  {
    if (code == clear_code)
    {
-     /*
-      * Clear/reset the compression table...
-      */
-
-      memset(table, 0, 2 * sizeof(gif_table_t));
-      for (i = 1; i < clear_code; i ++)
+      for (i = 0; i < clear_code; i ++)
+      {
+	table[0][i] = 0;
 	table[1][i] = i;
+      }
+
+      for (; i < 4096; i ++)
+	table[0][i] = table[1][i] = 0;

      code_size     = set_code_size + 1;
      max_code_size = 2 * clear_code;
@@ -632,11 +637,12 @@ gif_read_lzw(FILE *fp,			/* I - File to read from */

      firstcode = oldcode = gif_get_code(fp, code_size, 0);

-      return (firstcode & 255);
+      return (firstcode);
    }
-    else if (code == end_code || code > max_code)
+    else if (code == end_code)
    {
-      unsigned char	buf[260];	/* Block buffer */
+      unsigned char	buf[260];
+

      if (!gif_eof)
        while (gif_get_block(fp, buf) > 0);
@@ -646,7 +652,7 @@ gif_read_lzw(FILE *fp,			/* I - File to read from */

    incode = code;

-    if (code == max_code)
+    if (code >= max_code)
    {
      *sp++ = firstcode;
      code  = oldcode;
@@ -680,10 +686,10 @@ gif_read_lzw(FILE *fp,			/* I - File to read from */
    oldcode = incode;

    if (sp > stack)
-      return ((*--sp) & 255);
+      return (*--sp);
  }

-  return (code & 255);
+  return (code);
 }


@@ -165,10 +165,9 @@ f(x) = density * x <sup style='font-size: 100%'>gamma</sup>

 <h4>Customizing the Profile Selection Keywords</h4>

-<p>The <tt>ColorModel</tt>, <tt>MediaType</tt>, and <tt>Resolution</tt> main keywords can be reassigned to different main keywords, allowing drivers to do color profile selection based on different parameters. The <tt>cupsICCQualifier1</tt>, <tt>cupsICCQualifier2</tt>, and <tt>cupsICCQualifier3</tt> keywords define the mapping from selector to main keyword:</p>
+<p>The <tt>MediaType</tt> and <tt>Resolution</tt> main keywords can be reassigned to different main keywords, allowing drivers to do color profile selection based on different parameters. The <tt>cupsICCQualifier2</tt> and <tt>cupsICCQualifier3</tt> keywords define the mapping from selector to main keyword:</p>

 <pre class='command'>
-*cupsICCQualifier1: MainKeyword1
 *cupsICCQualifier2: MainKeyword2
 *cupsICCQualifier3: MainKeyword3
 </pre>
@@ -176,7 +175,6 @@ f(x) = density * x <sup style='font-size: 100%'>gamma</sup>
 <p>The default mapping is as follows:</p>

 <pre class='command'>
-*cupsICCQualifier1: ColorModel
 *cupsICCQualifier2: MediaType
 *cupsICCQualifier3: Resolution
 </pre>
@@ -5,7 +5,7 @@
 #
 #   Original version by Jason McMullan <jmcc@ontv.com>.
 #
-#   Copyright 2007-2011 by Apple Inc.
+#   Copyright 2007-2010 by Apple Inc.
 #   Copyright 1999-2007 by Easy Software Products, all rights reserved.
 #
 #   These coded instructions, statements, and computer programs are the
@@ -79,7 +79,7 @@ Requires: %{name}-libs = %{epoch}:%{version}

 %description
 CUPS is the standards-based, open source printing system developed by
-Apple Inc. for Mac OS® X and other UNIX®-like operating systems.
+Apple Inc. for Mac OS¨ X and other UNIX¨-like operating systems.

 %description devel
 This package provides the CUPS headers and development environment.
@@ -190,11 +190,10 @@ rm -rf $RPM_BUILD_ROOT
 %dir /usr/lib/cups
 %dir /usr/lib/cups/backend
 /usr/lib/cups/backend/http
-/usr/lib/cups/backend/https
 %attr(0700,root,root) /usr/lib/cups/backend/ipp
-/usr/lib/cups/backend/ipps
 %attr(0700,root,root) /usr/lib/cups/backend/lpd
 /usr/lib/cups/backend/parallel
+/usr/lib/cups/backend/scsi
 /usr/lib/cups/backend/serial
 /usr/lib/cups/backend/snmp
 /usr/lib/cups/backend/socket
@@ -204,7 +203,6 @@ rm -rf $RPM_BUILD_ROOT
 %dir /usr/lib/cups/daemon
 /usr/lib/cups/daemon/cups-deviced
 /usr/lib/cups/daemon/cups-driverd
-/usr/lib/cups/daemon/cups-exec
 /usr/lib/cups/daemon/cups-polld
 %dir /usr/lib/cups/driver
 %dir /usr/lib/cups/filter
@@ -290,6 +288,8 @@ rm -rf $RPM_BUILD_ROOT
 /usr/share/man/man5/*.conf.5.gz
 /usr/share/man/man5/ipptoolfile.5.gz
 /usr/share/man/man5/mime.*.5.gz
+%dir /usr/share/man/man7
+/usr/share/man/man7/drv*
 %dir /usr/share/man/man8
 /usr/share/man/man8/accept.8.gz
 /usr/share/man/man8/cupsaddsmb.8.gz
@@ -3220,7 +3220,7 @@ encrypt_client(cupsd_client_t *con)	/* I - Client to encrypt */
  gnutls_certificate_set_x509_key_file(*credentials, ServerCertificate,
 				       ServerKey, GNUTLS_X509_FMT_PEM);

-  gnutls_init(&con->http.tls, GNUTLS_SERVER);
+  gnutls_init(&con->http.tls), GNUTLS_SERVER);
  gnutls_set_default_priority(con->http.tls);
  gnutls_credentials_set(con->http.tls, GNUTLS_CRD_CERTIFICATE, *credentials);
  gnutls_transport_set_ptr(con->http.tls, (gnutls_transport_ptr)HTTP(con));
@@ -2593,11 +2593,11 @@ read_configuration(cups_file_t *fp)	/* I - File to read from */
 		      "FaxRetryLimit is deprecated; use "
 		      "JobRetryLimit on line %d.", linenum);
    }
-    else if ((!_cups_strcasecmp(line, "Port") || !_cups_strcasecmp(line, "Listen")
+    else if (!_cups_strcasecmp(line, "Port") || !_cups_strcasecmp(line, "Listen")
 #ifdef HAVE_SSL
             || !_cups_strcasecmp(line, "SSLPort") || !_cups_strcasecmp(line, "SSLListen")
 #endif /* HAVE_SSL */
-	     ) && value)
+	     )
    {
     /*
      * Add listening address(es) to the list...
@@ -3740,12 +3740,6 @@ read_location(cups_file_t *fp,		/* I - Configuration file */
    else if (!_cups_strcasecmp(line, "</Limit>") ||
             !_cups_strcasecmp(line, "</LimitExcept>"))
      loc = parent;
-    else if (!value)
-    {
-      cupsdLogMessage(CUPSD_LOG_ERROR, "Missing value on line %d.", linenum);
-      if (FatalErrors & CUPSD_FATAL_CONFIG)
-	return (0);
-    }
    else if (!parse_aaa(loc, line, value, linenum))
    {
      cupsdLogMessage(CUPSD_LOG_ERROR,
@@ -3895,12 +3889,6 @@ read_policy(cups_file_t *fp,		/* I - Configuration file */

      op = NULL;
    }
-    else if (!value)
-    {
-      cupsdLogMessage(CUPSD_LOG_ERROR, "Missing value on line %d.", linenum);
-      if (FatalErrors & CUPSD_FATAL_CONFIG)
-	return (0);
-    }
    else if (!_cups_strcasecmp(line, "JobPrivateAccess") ||
 	     !_cups_strcasecmp(line, "JobPrivateValues") ||
 	     !_cups_strcasecmp(line, "SubscriptionPrivateAccess") ||
@@ -750,11 +750,8 @@ compare_ppds(const ppd_info_t *p0,	/* I - First PPD file */
  else if ((diff = cupsdCompareNames(p0->record.make_and_model,
                                     p1->record.make_and_model)) != 0)
    return (diff);
-  else if ((diff = strcmp(p0->record.languages[0],
-                          p1->record.languages[0])) != 0)
-    return (diff);
  else
-    return (compare_names(p0, p1));
+    return (strcmp(p0->record.languages[0], p1->record.languages[0]));
 }


@@ -1411,9 +1408,7 @@ load_drv(const char  *filename,		/* I - Actual filename */
  * Add a dummy entry for the file...
  */

-  httpAssembleURIf(HTTP_URI_CODING_ALL, uri, sizeof(uri), "drv", "", "", 0,
-		   "/%s", name);
-  add_ppd(name, uri, "", "", "", "", "", "", mtime, size, 0,
+  add_ppd(name, name, "", "", "", "", "", "", mtime, size, 0,
          PPD_TYPE_DRV, "drv");
  ChangedPPD = 1;

@@ -8885,22 +8885,6 @@ hold_job(cupsd_client_t  *con,		/* I - Client connection */
    return;
  }

- /*
-  * See if the job is in a state that allows holding...
-  */
-
-  if (job->state_value > IPP_JOB_STOPPED)
-  {
-   /*
-    * Return a "not-possible" error...
-    */
-
-    send_ipp_status(con, IPP_NOT_POSSIBLE,
-		    _("Job #%d is finished and cannot be altered."),
-		    job->id);
-    return;
-  }
-
 /*
  * Hold the job and return...
  */
@@ -1343,22 +1343,17 @@ cupsdDeleteJob(cupsd_job_t       *job,	/* I - Job */
    free(job->compressions);
    free(job->filetypes);

-    if (action == CUPSD_JOB_PURGE)
+    while (job->num_files > 0)
    {
-      while (job->num_files > 0)
-      {
-	snprintf(filename, sizeof(filename), "%s/d%05d-%03d", RequestRoot,
-		 job->id, job->num_files);
-	if (Classification)
-	  cupsdRemoveFile(filename);
-	else
-	  unlink(filename);
+      snprintf(filename, sizeof(filename), "%s/d%05d-%03d", RequestRoot,
+	       job->id, job->num_files);
+      if (Classification)
+	cupsdRemoveFile(filename);
+      else
+	unlink(filename);

-	job->num_files --;
-      }
+      job->num_files --;
    }
-    else
-      job->num_files = 0;
  }

  if (job->history)
@@ -2335,14 +2330,14 @@ cupsdSetJobState(
  if (!cupsdLoadJob(job))
    return;

- /*
-  * Don't do anything if the state is unchanged and we aren't purging the
-  * job...
-  */
+  /*
+   * Don't do anything if the state is unchanged and we aren't purging the
+   * job...
+   */

-  oldstate = job->state_value;
-  if (newstate == oldstate && action != CUPSD_JOB_PURGE)
-    return;
+   oldstate = job->state_value;
+   if (newstate == oldstate && action != CUPSD_JOB_PURGE)
+     return;

 /*
  * Stop any processes that are working on the current job...
@@ -76,9 +76,6 @@
 #ifdef HAVE_SYS_VFS_H
 #  include <sys/vfs.h>
 #endif /* HAVE_SYS_VFS_H */
-#ifdef __APPLE__
-#  include <asl.h>
-#endif /* __APPLE__ */


 /*
@@ -93,7 +90,6 @@ static int	compare_printers(void *first, void *second, void *data);
 static void	delete_printer_filters(cupsd_printer_t *p);
 static void	dirty_printer(cupsd_printer_t *p);
 static void	load_ppd(cupsd_printer_t *p);
-static void	log_ipp_conformance(cupsd_printer_t *p, const char *reason);
 static ipp_t	*new_media_col(_pwg_size_t *size, const char *source,
 		               const char *type);
 #ifdef __sgi
@@ -2761,10 +2757,6 @@ cupsdSetPrinterReasons(

      if (i >= p->num_reasons)
      {
-        if (!strncmp(reason, "cups-ipp-missing-", 17) ||
-	    !strncmp(reason, "cups-ipp-wrong-", 15))
-	  log_ipp_conformance(p, reason);
-
        if (i >= (int)(sizeof(p->reasons) / sizeof(p->reasons[0])))
 	{
 	  cupsdLogMessage(CUPSD_LOG_ALERT,
@@ -5082,81 +5074,6 @@ load_ppd(cupsd_printer_t *p)		/* I - Printer */
 }


-/*
- * 'log_ipp_conformance()' - Log an IPP conformance issue with a printer.
- */
-
-static void
-log_ipp_conformance(
-    cupsd_printer_t *p,			/* I - Printer */
-    const char      *reason)		/* I - Printer state reason */
-{
-  const char	*message;		/* Message to log */
-#ifdef __APPLE__
-  aslmsg	aslm;			/* Apple System Log message */
-#endif /* __APPLE__ */
-
-
- /*
-  * Strip the leading "cups-ipp-" from the reason and create a log message for
-  * it...
-  */
-
-  reason += 9;
-  if (!strcmp(reason, "missing-cancel-job"))
-    message = "Printer does not support REQUIRED Cancel-Job operation.";
-  else if (!strcmp(reason, "missing-get-job-attributes"))
-    message = "Printer does not support REQUIRED Get-Job-Attributes operation.";
-  else if (!strcmp(reason, "missing-print-job"))
-    message = "Printer does not support REQUIRED Print-Job operation.";
-  else if (!strcmp(reason, "missing-validate-job"))
-    message = "Printer does not support REQUIRED Validate-Job operation.";
-  else if (!strcmp(reason, "missing-get-printer-attributes"))
-    message = "Printer does not support REQUIRED Get-Printer-Attributes operation.";
-  else if (!strcmp(reason, "missing-job-history"))
-    message = "Printer does not provide REQUIRED job history.";
-  else if (!strcmp(reason, "missing-job-id"))
-    message = "Printer does not provide REQUIRED job-id attribute.";
-  else if (!strcmp(reason, "missing-job-state"))
-    message = "Printer does not provide REQUIRED job-state attribute.";
-  else if (!strcmp(reason, "missing-operations-supported"))
-    message = "Printer does not provide REQUIRED operations-supported "
-              "attribute.";
-  else if (!strcmp(reason, "missing-printer-is-accepting-jobs"))
-    message = "Printer does not provide REQUIRED printer-is-accepting-jobs "
-              "attribute.";
-  else if (!strcmp(reason, "missing-printer-state-reasons"))
-    message = "Printer does not provide REQUIRED printer-state-reasons "
-              "attribute.";
-  else if (!strcmp(reason, "wrong-http-version"))
-    message = "Printer does not use REQUIRED HTTP/1.1 transport.";
-  else
-    message = "Unknown IPP conformance failure.";
-
-  cupsdLogMessage(CUPSD_LOG_WARN, "%s: %s", p->name, message);
-
-#ifdef __APPLE__
- /*
-  * Report the failure information to Apple if the user opts into providing
-  * feedback to Apple...
-  */
-
-  aslm = asl_new(ASL_TYPE_MSG);
-  if (aslm)
-  {
-    asl_set(aslm, "com.apple.message.domain", "com.apple.printing.ipp.conformance");
-    asl_set(aslm, "com.apple.message.domain_scope", "com.apple.printing.ipp.conformance");
-    asl_set(aslm, "com.apple.message.signature", reason);
-    asl_set(aslm, "com.apple.message.signature2",
-	    p->make_model ? p->make_model : "Unknown");
-    asl_log(NULL, aslm, ASL_LEVEL_NOTICE, "%s: %s",
-            p->make_model ? p->make_model : "Unknown", message);
-    asl_free(aslm);
-  }
-#endif /* __APPLE__ */
-}
-
-
 /*
 * 'new_media_col()' - Create a media-col collection value.
 */
@@ -196,10 +196,6 @@ cupsdSetBusyState(void)
  if (job)
    newbusy |= 2;

-  cupsdLogMessage(CUPSD_LOG_DEBUG,
-                  "cupsdSetBusyState: newbusy=\"%s\", busy=\"%s\"",
-                  busy_text[newbusy], busy_text[busy]);
-
 /*
  * Manage state changes...
  */
@@ -217,23 +213,25 @@ cupsdSetBusyState(void)
      vtran = 0;
    }
 #endif /* HAVE_VPROC_TRANSACTION_BEGIN */
-  }

 #ifdef kIOPMAssertionTypeDenySystemSleep
-  if (cupsArrayCount(PrintingJobs) > 0 && !dark_wake)
-  {
-    cupsdLogMessage(CUPSD_LOG_DEBUG, "Asserting dark wake.");
-    IOPMAssertionCreateWithName(kIOPMAssertionTypeDenySystemSleep,
-				kIOPMAssertionLevelOn,
-				CFSTR("org.cups.cupsd"), &dark_wake);
-  }
-  else if (cupsArrayCount(PrintingJobs) == 0 && dark_wake)
-  {
-    cupsdLogMessage(CUPSD_LOG_DEBUG, "Releasing dark wake assertion.");
-    IOPMAssertionRelease(dark_wake);
-    dark_wake = 0;
-  }
+    if ((busy & 2) && !dark_wake)
+    {
+      cupsdLogMessage(CUPSD_LOG_DEBUG2, "Asserting dark wake.");
+      IOPMAssertionCreateWithName(kIOPMAssertionTypeDenySystemSleep,
+			          kIOPMAssertionLevelOn,
+				  CFSTR("org.cups.cupsd"), &dark_wake);
+    }
+    else if (!(busy & 2) && dark_wake)
+    {
+      cupsdLogMessage(CUPSD_LOG_DEBUG2, "Releasing dark wake assertion.");
+      IOPMAssertionRelease(dark_wake);
+      dark_wake = 0;
+    }
 #endif /* kIOPMAssertionTypeDenySystemSleep */
+
+    cupsdLogMessage(CUPSD_LOG_DEBUG, "cupsdSetBusyState: %s", busy_text[busy]);
+  }
 }


@@ -0,0 +1,163 @@
+#
+# "$Id$"
+#
+#   Standards makefile for CUPS.
+#
+#   Copyright 2007-2010 by Apple Inc.
+#   Copyright 2006 by Easy Software Products.
+#
+#   These coded instructions, statements, and computer programs are the
+#   property of Apple Inc. and are protected by Federal copyright
+#   law.  Distribution and use rights are outlined in the file "LICENSE.txt"
+#   which should have been included with this file.  If this file is
+#   file is missing or damaged, see the license at "http://www.cups.org/".
+#
+
+include ../Makedefs
+
+
+#
+# Standards...
+#
+
+RFCS	=	\
+		rfc1155.txt \
+		rfc1157.txt \
+		rfc1179.txt \
+		rfc1213.txt \
+		rfc1321.txt \
+		rfc2222.txt \
+		rfc2246.txt \
+		rfc2487.txt \
+		rfc2554.txt \
+		rfc2567.txt \
+		rfc2568.txt \
+		rfc2569.txt \
+		rfc2578.txt \
+		rfc2595.txt \
+		rfc2616.txt \
+		rfc2617.txt \
+		rfc2712.txt \
+		rfc2790.txt \
+		rfc2817.txt \
+		rfc2818.txt \
+		rfc2821.txt \
+		rfc2822.txt \
+		rfc2910.txt \
+		rfc2911.txt \
+		rfc2965.txt \
+		rfc3196.txt \
+		rfc3239.txt \
+		rfc3380.txt \
+		rfc3381.txt \
+		rfc3382.txt \
+		rfc3391.txt \
+		rfc3510.txt \
+		rfc3712.txt \
+		rfc3805.txt \
+		rfc3875.txt \
+		rfc3986.txt \
+		rfc3995.txt \
+		rfc3996.txt \
+		rfc3997.txt \
+		rfc3998.txt \
+		rfc4122.txt \
+		rfc4234.txt
+
+.SUFFIXES:	.html .txt
+.txt.html:	rfctohtml
+	echo Converting $< to HTML...
+	./rfctohtml $< ../doc/help/$@
+
+
+#
+# Make everything...
+#
+
+all:	rfctohtml $(RFCS:.txt=.html)
+
+
+#
+# Make library targets...
+#
+
+libs:
+
+
+#
+# Make unit tests...
+#
+
+unittests:
+
+
+#
+# Clean all config and object files...
+#
+
+clean:
+	$(RM) rfctohtml rfctohtml.o
+	$(RM) $(RFCS:.txt=.html)
+
+
+#
+# Dummy depend target...
+#
+
+depend:
+
+
+#
+# Install all targets...
+#
+
+install:	all install-data install-headers install-libs install-exec
+
+
+#
+# Install data files...
+#
+
+install-data:
+
+
+#
+# Install programs...
+#
+
+install-exec:
+
+
+#
+# Install headers...
+#
+
+install-headers:
+
+
+#
+# Install libraries...
+#
+
+install-libs:
+
+
+#
+# Uninstall files...
+#
+
+uninstall:
+
+
+#
+# rfctohtml - make html versions of RFCs...
+#
+
+rfctohtml:	rfctohtml.o ../cups/$(LIBCUPSSTATIC)
+	$(CC) $(ARCHFLAGS) $(LDFLAGS) -o $@ rfctohtml.o ../cups/$(LIBCUPSSTATIC) \
+		$(LIBGSSAPI) $(SSLLIBS) $(DNSSDLIBS) $(COMMONLIBS) $(LIBZ)
+
+
+#
+# End of "$Id$".
+#
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -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]
+
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      H. Alvestrand
+Request for Comments: 3282                                 Cisco Systems
+Obsoletes: 1766                                                 May 2002
+Category: Standards Track
+
+
+                       Content Language Headers
+
+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 a "Content-language:" header, for use in cases
+   where one desires to indicate the language of something that has RFC
+   822-like headers, like MIME body parts or Web documents, and an
+   "Accept-Language:" header for use in cases where one wishes to
+   indicate one's preferences with regard to language.
+
+1. Introduction
+
+   There are a number of languages presently or previously used by human
+   beings in this world.
+
+   A great number of these people would prefer to have information
+   presented in a language which they understand.
+
+   In some contexts, it is possible to have information available in
+   more than one language, or it might be possible to provide tools
+   (such as dictionaries) to assist in the understanding of a language.
+
+   In other cases, it may be desirable to use a computer program to
+   convert information from one format (such as plaintext) into another
+   (such as computer-synthesized speech, or Braille, or high-quality
+   print renderings).
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 1]
+
+RFC 3282                Content Language Headers                May 2002
+
+
+   A prerequisite for any such function is a means of labelling the
+   information content with an identifier for the language that is used
+   in this information content, such as is defined by [TAGS].  This
+   document specifies a protocol element for use with protocols that use
+   RFC 822-like headers for carrying language tags as defined in [TAGS].
+
+   The keywords "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].
+
+2. The Content-language header
+
+   The "Content-Language" header is intended for use in the case where
+   one desires to indicate the language(s) of something that has RFC
+   822-like headers, such as MIME body parts or Web documents.
+
+   The RFC 822 EBNF of the Content-Language header is:
+
+      Content-Language = "Content-Language" ":" 1#Language-tag
+
+   In the more strict RFC 2234 ABNF:
+
+      Content-Language = "Content-Language" ":" [CFWS] Language-List
+      Language-List = Language-Tag [CFWS]
+                         *("," [CFWS] Language-Tag [CFWS])
+
+   The Content-Language header may list several languages in a comma-
+   separated list.
+
+   The CFWS construct is intended to function like the whitespace
+   convention in RFC 822, which means also that one can place
+   parenthesized comments anywhere in the language sequence, or use
+   continuation lines.  A formal definition is given in RFC 2822
+   [RFC2822].
+
+   In keeping with the tradition of RFC 2822, a more liberal "obsolete"
+   grammar is also given:
+
+      obs-content-language = "Content-Language" *WSP ":"
+                              [CFWS] Language-List
+
+   Like RFC 2822, this specification says that conforming
+   implementations MUST accept the obs-content-language syntax, but MUST
+   NOT generate it; all generated headers MUST conform to the Content-
+   Language syntax.
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 2]
+
+RFC 3282                Content Language Headers                May 2002
+
+
+2.1 Examples of Content-language values
+
+   Voice recording from Liverpool downtown
+
+      Content-type: audio/basic
+      Content-Language: en-scouse
+
+   Document in Mingo, an American Indian language which does not have an
+   ISO 639 code:
+
+      Content-type: text/plain
+      Content-Language: i-mingo
+
+   A English-French dictionary
+
+      Content-type: application/dictionary
+      Content-Language: en, fr (This is a dictionary)
+
+   An official European Commission document (in a few of its official
+   languages):
+
+      Content-type: multipart/alternative
+      Content-Language: da, de, el, en, fr, it
+
+   An excerpt from Star Trek
+
+      Content-type: video/mpeg
+      Content-Language: i-klingon
+
+3. The Accept-Language header
+
+   The "Accept-Language" header is intended for use in cases where a
+   user or a process desires to identify the preferred language(s) when
+   RFC 822-like headers, such as MIME body parts or Web documents, are
+   used.
+
+   The RFC 822 EBNF of the Accept-Language header is:
+
+      Accept-Language = "Accept-Language" ":"
+                             1#( language-range [ ";" "q" "=" qvalue ] )
+
+   A slightly more restrictive RFC 2234 ABNF definition is:
+
+      Accept-Language = "Accept-Language:" [CFWS] language-q
+                        *( "," [CFWS] language-q )
+      language-q = language-range [";" [CFWS] "q=" qvalue ] [CFWS]
+      qvalue         = ( "0" [ "." 0*3DIGIT ] )
+                     / ( "1" [ "." 0*3("0") ] )
+
+
+
+Alvestrand                  Standards Track                     [Page 3]
+
+RFC 3282                Content Language Headers                May 2002
+
+
+
+   A more liberal RFC 2234 ABNF definition is:
+
+      Obs-accept-language = "Accept-Language" *WSP ":" [CFWS]
+           obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]
+      obs-language-q = language-range
+            [ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]
+
+   Like RFC 2822, this specification says that conforming
+   implementations MUST accept the obs-accept-language syntax, but MUST
+   NOT generate it; all generated messages MUST conform to the Accept-
+   Language syntax.
+
+   The syntax and semantics of language-range is defined in [TAGS].  The
+   Accept-Language header may list several language-ranges in a comma-
+   separated list, and each may include a quality value Q.  If no Q
+   values are given, the language-ranges are given in priority order,
+   with the leftmost language-range being the most preferred language;
+   this is an extension to the HTTP/1.1 rules, but matches current
+   practice.
+
+   If Q values are given, refer to HTTP/1.1 [RFC 2616] for the details
+   on how to evaluate it.
+
+4. Security Considerations
+
+   The only security issue that has been raised with language tags since
+   the publication of RFC 1766, which stated that "Security issues are
+   believed to be irrelevant to this memo", is a concern with language
+   ranges used in content negotiation - that they may be used to infer
+   the nationality of the sender, and thus identify potential targets
+   for surveillance.
+
+   This is a special case of the general problem that anything you send
+   is visible to the receiving party; it is useful to be aware that such
+   concerns can exist in some cases.
+
+   The exact magnitude of the threat, and any possible countermeasures,
+   is left to each application protocol.
+
+5. Character set considerations
+
+   This document adds no new considerations beyond what is mentioned in
+   [TAGS].
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 4]
+
+RFC 3282                Content Language Headers                May 2002
+
+
+6. Acknowledgements
+
+   This document has benefited from many rounds of review and comments
+   in various fora of the IETF and the Internet working groups.
+
+   Any list of contributors is bound to be incomplete; please regard the
+   following as only a selection from the group of people who have
+   contributed to make this document what it is today.
+
+   In alphabetical order:
+
+   Tim Berners-Lee, Nathaniel Borenstein, Sean M. Burke, John Clews, Jim
+   Conklin, John Cowan, Dave Crocker, Martin Duerst, Michael Everson,
+   Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Paul
+   Hoffman, Olle Jarnefors, John Klensin, Bruce Lilly, Keith Moore,
+   Chris Newman, Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley,
+   Misha Wolf, Francois Yergeau and many, many others.
+
+   Special thanks must go to Michael Everson, who has served as language
+   tag reviewer for almost the entire period, since the publication of
+   RFC 1766, and has provided a great deal of input to this revision.
+   Bruce Lilly did a special job of reading and commenting on my ABNF
+   definitions.
+
+7. References
+
+   [TAGS]      Alvestrand, H., "Tags for the Identification of
+               Languages", BCP 47, RFC 3066
+
+   [ISO 639]   ISO 639:1988 (E/F) - Code for the representation of names
+               of languages - The International Organization for
+               Standardization, 1st edition, 1988-04-01 Prepared by
+               ISO/TC 37 - Terminology (principles and coordination).
+               Note that a new version (ISO 639-1:2000) is in
+               preparation at the time of this writing.
+
+   [ISO 639-2] ISO 639-2:1998 - Codes for the representation of names of
+               languages -- Part 2: Alpha-3 code  - edition 1, 1998-11-
+               01, 66 pages, prepared by ISO/TC 37/SC 2
+
+   [ISO 3166]  ISO 3166:1988 (E/F) - Codes for the representation of
+               names of countries - The International Organization for
+               Standardization, 3rd edition, 1988-08-15.
+
+   [ISO 15924] ISO/DIS 15924 - Codes for the representation of names of
+               scripts (under development by ISO TC46/SC2)
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 5]
+
+RFC 3282                Content Language Headers                May 2002
+
+
+   [RFC 2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC 2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part Two: Media Types", RFC 2046,
+               November 1996.
+
+   [RFC 2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+               Part Three: Message Header Extensions for Non-ASCII
+               Text", RFC 2047, November 1996.
+
+   [RFC 2048]  Freed, N., Klensin, J. and J. Postel, "Multipurpose
+               Internet Mail Extensions (MIME) Part Four: Registration
+               Procedures", RFC 2048, November 1996.
+
+   [RFC 2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part Five: Conformance Criteria and
+               Examples", RFC 2049, November 1996.
+
+   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC 2616]  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.
+
+   [RFC 2822]  Resnick, P., "Internet Message Format", RFC 2822, April
+               2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 6]
+
+RFC 3282                Content Language Headers                May 2002
+
+
+Appendix A: Changes from RFC 1766
+
+   The definition of the language tags has been split, and is now RFC
+   3066.  The differences parameter to multipart/alternative is no
+   longer part of this standard, because no implementations of the
+   function were ever found.  Consult RFC 1766 if you need the
+   information.
+
+   The ABNF for content-language has been updated to use the RFC 2234
+   ABNF.
+
+Author's Address
+
+   Harald Tveit Alvestrand
+   Cisco Systems
+   Weidemanns vei 27
+   7043 Trondheim
+   NORWAY
+
+   EMail: Harald@Alvestrand.no
+   Phone: +47 73 50 33 52
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 7]
+
+RFC 3282                Content Language Headers                May 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 8]
+
@@ -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]
+
@@ -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]
+
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                        I. McDonald
+Request for Comments: 3808                                    High North
+Category: Informational                                        June 2004
+
+
+                            IANA Charset MIB
+
+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 (2004).
+
+Abstract
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   This IANA Charset MIB is now an IANA registry.  In particular, a
+   single textual convention 'IANACharset' is defined that may be used
+   to specify charset labels in MIB objects.  'IANACharset' was
+   extracted from Printer MIB v2 (RFC 3805).  'IANACharset' was
+   originally defined (and mis-named) as 'CodedCharSet' in Printer MIB
+   v1 (RFC 1759).  A tool has been written in C, that may be used by
+   IANA to regenerate this IANA Charset MIB, when future charsets are
+   registered in accordance with the IANA Charset Registration
+   Procedures (RFC 2978).
+
+Table of Contents
+
+   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
+       1.1.  Conformance Terminology . . . . . . . . . . . . . . . .   2
+       1.2.  Charset Terminology . . . . . . . . . . . . . . . . . .   2
+   2.  The Internet-Standard Management Framework. . . . . . . . . .   2
+   3.  Generation of IANA Charset MIB. . . . . . . . . . . . . . . .   3
+   4.  Definition of IANA Charset MIB. . . . . . . . . . . . . . . .   3
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
+   6.  Internationalization Considerations . . . . . . . . . . . . .  10
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
+   8.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  11
+   9.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  11
+       9.1.  Normative References. . . . . . . . . . . . . . . . . .  11
+       9.2.  Informative References. . . . . . . . . . . . . . . . .  12
+   10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  13
+   11. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  14
+
+
+
+McDonald                     Informational                      [Page 1]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+1.  Introduction
+
+   This IANA Charset MIB [CHARMIB] module defines the single textual
+   convention 'IANACharset'.  Once adopted, all future versions of the
+   IANA Charset MIB [CHARMIB] may be machine-generated whenever the IANA
+   Charset Registry [CHARSET] is updated by IANA staff according to the
+   procedures defined in [RFC2978], using the utility [CHARGEN]
+   described in section 3 of this document or any other machine-
+   generation method.
+
+   It is strongly recommended that future updates to the IANA Charset
+   MIB [CHARMIB] be machine-generated (rather than hand-edited) to avoid
+   asynchrony between the IANA Charset Registry [CHARSET] and the IANA
+   Charset MIB [CHARMIB].
+
+   Note:  Questions and comments on this IANA Charset MIB [CHARMIB]
+   should be sent to the editor (imcdonald@sharplabs.com) and IANA
+   (iana@iana.org) with a copy to the IETF Charsets mailing list (ietf-
+   charset@iana.org).
+
+1.1.  Conformance 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 BCP 14, RFC 2119
+   [RFC2119].
+
+1.2.  Charset Terminology
+
+   The following terms are used in this specification, exactly as
+   defined in section 1 'Definitions and Notation' of the IANA Charset
+   Registration Procedures [RFC2978]:  "character", "charset", "coded
+   character set (CCS)", and "character encoding scheme (CES)".
+
+2.  The Internet-Standard Management Framework
+
+   For a detailed overview of the documents that describe the current
+   Internet-Standard Management Framework, please refer to section 7 of
+   RFC 3410 [RFC3410].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  MIB objects are generally
+   accessed through the Simple Network Management Protocol (SNMP).
+   Objects in the MIB are defined using the mechanisms defined in the
+   Structure of Management Information (SMI).  This memo specifies a MIB
+   module that is compliant to the SMIv2, which is described in STD 58,
+   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580
+   [RFC2580].
+
+
+
+McDonald                     Informational                      [Page 2]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+3.  Generation of IANA Charset MIB
+
+   Intellectual Property:  The C language utility 'ianachar.c' [CHARGEN]
+   and the IANA Charset MIB template file [CHARTEMP] are hereby donated
+   by the author (Ira McDonald) to IANA, in perpetuity, free of license
+   or any other restraint.
+
+   The [CHARGEN] utility may be used to generate an updated version of
+   the 'IANACharset' textual convention by reading and parsing the
+   (currently plaintext) IANA Charset Registry [CHARSET].
+
+   This utility parses each charset registration, finding (in order):
+
+   1) The 'Name' field (which is saved for a fallback - see below);
+
+   2) The 'MIBenum' field (which contains the IANA-assigned positive
+      decimal enum value); and
+
+   3) The (usually present) 'Alias' field that begins with 'cs' (that
+      contains the IANA-assigned enum label).  If an 'Alias' field is
+      not found, the utility constructs one from the 'Name' field by:
+
+      -  Beginning the enum label with a lowercase 'cs' prefix;
+
+      -  Copying _only_ alpha/numeric characters from the 'Name' field
+         to the enum label (ignoring punctuation, whitespace, etc.).
+
+4.  Definition of IANA Charset MIB
+
+IANA-CHARSET-MIB DEFINITIONS ::= BEGIN
+--  http://www.iana.org/assignments/ianacharset-mib
+
+IMPORTS
+    MODULE-IDENTITY,
+        mib-2
+            FROM SNMPv2-SMI                              -- [RFC2578]
+    TEXTUAL-CONVENTION
+            FROM SNMPv2-TC;                              -- [RFC2579]
+
+ianaCharsetMIB MODULE-IDENTITY
+    LAST-UPDATED    "200406080000Z"
+    ORGANIZATION    "IANA"
+    CONTACT-INFO    "       Internet Assigned Numbers Authority
+
+                    Postal: ICANN
+                            4676 Admiralty Way, Suite 330
+                            Marina del Rey, CA 90292
+
+
+
+
+McDonald                     Informational                      [Page 3]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+                    Tel:    +1 310 823 9358
+                    E-Mail: iana@iana.org"
+
+    DESCRIPTION     "This MIB module defines the IANACharset
+                    TEXTUAL-CONVENTION.  The IANACharset TC is used to
+                    specify the encoding of string objects defined in
+                    a MIB.
+
+                    Each version of this MIB will be released based on
+                    the IANA Charset Registry file (see RFC 2978) at
+                    http://www.iana.org/assignments/character-sets.
+
+                    Note:  The IANACharset TC, originally defined in
+                    RFC 1759, was inaccurately named CodedCharSet.
+
+                    Note:  Best practice is to define new MIB string
+                    objects with invariant UTF-8 (RFC 3629) syntax
+                    using the SnmpAdminString TC (defined in RFC 3411)
+                    in accordance with IETF Policy on Character Sets and
+                    Languages (RFC 2277).
+
+                    Copyright (C) The Internet Society (2004).  The
+                    initial version of this MIB module was published
+                    in RFC 3808; for full legal notices see the RFC
+                    itself.  Supplementary information may be
+                    available on
+                    http://www.ietf.org/copyrights/ianamib.html."
+
+    --  revision history
+
+    REVISION        "200406080000Z"
+    DESCRIPTION     "Original version transferred from Printer MIB,
+                    generated from the IANA maintained assignments
+                    http://www.iana.org/assignments/character-sets."
+
+    ::= { mib-2 106 }
+
+IANACharset ::= TEXTUAL-CONVENTION
+    STATUS  current
+    DESCRIPTION
+        "Specifies an IANA registered 'charset' - coded character set
+        (CCS) plus optional character encoding scheme (CES) - terms
+        defined in 'IANA Charset Registration Procedures' (RFC 2978).
+
+        Objects of this syntax are used to specify the encoding for
+        string objects defined in one or more MIBs.  For example, the
+        prtLocalizationCharacterSet, prtInterpreterDefaultCharSetIn, and
+        prtInterpreterDefaultCharSetOut objects defined in Printer MIB.
+
+
+
+McDonald                     Informational                      [Page 4]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+        The current list of 'charset' names and enumerated values
+        is contained in the IANA Character Set Registry at:
+
+           http://www.iana.org/assignments/character-sets
+
+        Enum names are derived from the IANA Charset Registry 'Alias'
+        fields that begin with 'cs' (for character set).
+        Enum values are derived from the parallel 'MIBenum' fields."
+    SYNTAX  INTEGER {
+        other(1),   -- used if the designated
+                    -- character set is not currently
+                    -- registered by IANA
+        unknown(2), -- used as a default value
+        csASCII(3),
+        csISOLatin1(4),
+        csISOLatin2(5),
+        csISOLatin3(6),
+        csISOLatin4(7),
+        csISOLatinCyrillic(8),
+        csISOLatinArabic(9),
+        csISOLatinGreek(10),
+        csISOLatinHebrew(11),
+        csISOLatin5(12),
+        csISOLatin6(13),
+        csISOTextComm(14),
+        csHalfWidthKatakana(15),
+        csJISEncoding(16),
+        csShiftJIS(17),
+        csEUCPkdFmtJapanese(18),
+        csEUCFixWidJapanese(19),
+        csISO4UnitedKingdom(20),
+        csISO11SwedishForNames(21),
+        csISO15Italian(22),
+        csISO17Spanish(23),
+        csISO21German(24),
+        csISO60DanishNorwegian(25),
+        csISO69French(26),
+        csISO10646UTF1(27),
+        csISO646basic1983(28),
+        csINVARIANT(29),
+        csISO2IntlRefVersion(30),
+        csNATSSEFI(31),
+        csNATSSEFIADD(32),
+        csNATSDANO(33),
+        csNATSDANOADD(34),
+        csISO10Swedish(35),
+        csKSC56011987(36),
+        csISO2022KR(37),
+
+
+
+McDonald                     Informational                      [Page 5]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+        csEUCKR(38),
+        csISO2022JP(39),
+        csISO2022JP2(40),
+        csISO13JISC6220jp(41),
+        csISO14JISC6220ro(42),
+        csISO16Portuguese(43),
+        csISO18Greek7Old(44),
+        csISO19LatinGreek(45),
+        csISO25French(46),
+        csISO27LatinGreek1(47),
+        csISO5427Cyrillic(48),
+        csISO42JISC62261978(49),
+        csISO47BSViewdata(50),
+        csISO49INIS(51),
+        csISO50INIS8(52),
+        csISO51INISCyrillic(53),
+        csISO54271981(54),
+        csISO5428Greek(55),
+        csISO57GB1988(56),
+        csISO58GB231280(57),
+        csISO61Norwegian2(58),
+        csISO70VideotexSupp1(59),
+        csISO84Portuguese2(60),
+        csISO85Spanish2(61),
+        csISO86Hungarian(62),
+        csISO87JISX0208(63),
+        csISO88Greek7(64),
+        csISO89ASMO449(65),
+        csISO90(66),
+        csISO91JISC62291984a(67),
+        csISO92JISC62991984b(68),
+        csISO93JIS62291984badd(69),
+        csISO94JIS62291984hand(70),
+        csISO95JIS62291984handadd(71),
+        csISO96JISC62291984kana(72),
+        csISO2033(73),
+        csISO99NAPLPS(74),
+        csISO102T617bit(75),
+        csISO103T618bit(76),
+        csISO111ECMACyrillic(77),
+        csa71(78),
+        csa72(79),
+        csISO123CSAZ24341985gr(80),
+        csISO88596E(81),
+        csISO88596I(82),
+        csISO128T101G2(83),
+        csISO88598E(84),
+        csISO88598I(85),
+
+
+
+McDonald                     Informational                      [Page 6]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+        csISO139CSN369103(86),
+        csISO141JUSIB1002(87),
+        csISO143IECP271(88),
+        csISO146Serbian(89),
+        csISO147Macedonian(90),
+        csISO150(91),
+        csISO151Cuba(92),
+        csISO6937Add(93),
+        csISO153GOST1976874(94),
+        csISO8859Supp(95),
+        csISO10367Box(96),
+        csISO158Lap(97),
+        csISO159JISX02121990(98),
+        csISO646Danish(99),
+        csUSDK(100),
+        csDKUS(101),
+        csKSC5636(102),
+        csUnicode11UTF7(103),
+        csISO2022CN(104),
+        csISO2022CNEXT(105),
+        csUTF8(106),
+        csISO885913(109),
+        csISO885914(110),
+        csISO885915(111),
+        csISO885916(112),
+        csGBK(113),
+        csGB18030(114),
+        csOSDEBCDICDF0415(115),
+        csOSDEBCDICDF03IRV(116),
+        csOSDEBCDICDF041(117),
+        csUnicode(1000),
+        csUCS4(1001),
+        csUnicodeASCII(1002),
+        csUnicodeLatin1(1003),
+        csUnicodeIBM1261(1005),
+        csUnicodeIBM1268(1006),
+        csUnicodeIBM1276(1007),
+        csUnicodeIBM1264(1008),
+        csUnicodeIBM1265(1009),
+        csUnicode11(1010),
+        csSCSU(1011),
+        csUTF7(1012),
+        csUTF16BE(1013),
+        csUTF16LE(1014),
+        csUTF16(1015),
+        csCESU8(1016),
+        csUTF32(1017),
+        csUTF32BE(1018),
+
+
+
+McDonald                     Informational                      [Page 7]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+        csUTF32LE(1019),
+        csBOCU1(1020),
+        csWindows30Latin1(2000),
+        csWindows31Latin1(2001),
+        csWindows31Latin2(2002),
+        csWindows31Latin5(2003),
+        csHPRoman8(2004),
+        csAdobeStandardEncoding(2005),
+        csVenturaUS(2006),
+        csVenturaInternational(2007),
+        csDECMCS(2008),
+        csPC850Multilingual(2009),
+        csPCp852(2010),
+        csPC8CodePage437(2011),
+        csPC8DanishNorwegian(2012),
+        csPC862LatinHebrew(2013),
+        csPC8Turkish(2014),
+        csIBMSymbols(2015),
+        csIBMThai(2016),
+        csHPLegal(2017),
+        csHPPiFont(2018),
+        csHPMath8(2019),
+        csHPPSMath(2020),
+        csHPDesktop(2021),
+        csVenturaMath(2022),
+        csMicrosoftPublishing(2023),
+        csWindows31J(2024),
+        csGB2312(2025),
+        csBig5(2026),
+        csMacintosh(2027),
+        csIBM037(2028),
+        csIBM038(2029),
+        csIBM273(2030),
+        csIBM274(2031),
+        csIBM275(2032),
+        csIBM277(2033),
+        csIBM278(2034),
+        csIBM280(2035),
+        csIBM281(2036),
+        csIBM284(2037),
+        csIBM285(2038),
+        csIBM290(2039),
+        csIBM297(2040),
+        csIBM420(2041),
+        csIBM423(2042),
+        csIBM424(2043),
+        csIBM500(2044),
+        csIBM851(2045),
+
+
+
+McDonald                     Informational                      [Page 8]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+        csIBM855(2046),
+        csIBM857(2047),
+        csIBM860(2048),
+        csIBM861(2049),
+        csIBM863(2050),
+        csIBM864(2051),
+        csIBM865(2052),
+        csIBM868(2053),
+        csIBM869(2054),
+        csIBM870(2055),
+        csIBM871(2056),
+        csIBM880(2057),
+        csIBM891(2058),
+        csIBM903(2059),
+        csIBBM904(2060),
+        csIBM905(2061),
+        csIBM918(2062),
+        csIBM1026(2063),
+        csIBMEBCDICATDE(2064),
+        csEBCDICATDEA(2065),
+        csEBCDICCAFR(2066),
+        csEBCDICDKNO(2067),
+        csEBCDICDKNOA(2068),
+        csEBCDICFISE(2069),
+        csEBCDICFISEA(2070),
+        csEBCDICFR(2071),
+        csEBCDICIT(2072),
+        csEBCDICPT(2073),
+        csEBCDICES(2074),
+        csEBCDICESA(2075),
+        csEBCDICESS(2076),
+        csEBCDICUK(2077),
+        csEBCDICUS(2078),
+        csUnknown8BiT(2079),
+        csMnemonic(2080),
+        csMnem(2081),
+        csVISCII(2082),
+        csVIQR(2083),
+        csKOI8R(2084),
+        csHZGB2312(2085),
+        csIBM866(2086),
+        csPC775Baltic(2087),
+        csKOI8U(2088),
+        csIBM00858(2089),
+        csIBM00924(2090),
+        csIBM01140(2091),
+        csIBM01141(2092),
+        csIBM01142(2093),
+
+
+
+McDonald                     Informational                      [Page 9]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+        csIBM01143(2094),
+        csIBM01144(2095),
+        csIBM01145(2096),
+        csIBM01146(2097),
+        csIBM01147(2098),
+        csIBM01148(2099),
+        csIBM01149(2100),
+        csBig5HKSCS(2101),
+        csIBM1047(2102),
+        csPTCP154(2103),
+        csAmiga1251(2104),
+        csKOI7switched(2105),
+        cswindows1250(2250),
+        cswindows1251(2251),
+        cswindows1252(2252),
+        cswindows1253(2253),
+        cswindows1254(2254),
+        cswindows1255(2255),
+        cswindows1256(2256),
+        cswindows1257(2257),
+        cswindows1258(2258),
+        csTIS620(2259),
+        reserved(3000)
+    }
+END
+
+5.  IANA Considerations
+
+   IANA has assigned a base arc in the 'mgmt' (standards track) OID tree
+   for the 'ianaCharset' MODULE-IDENTITY defined in the IANA Charset MIB
+   [CHARMIB].
+
+   Whenever any 'charset' is added to the IANA Charset Registry
+   [CHARSET], a new version of the IANA Charset MIB [CHARMIB] may be
+   machine-generated using the C language utility [CHARGEN], described
+   in section 3 of this document or some other utility.
+
+6.  Internationalization Considerations
+
+   The IANA Charset MIB [CHARMIB] defines the 'IANACharset' textual
+   convention that may be used in a given MIB module to supply explicit
+   character set labels for one or more text string objects defined in
+   that MIB module.
+
+   For example, the Printer MIB [RFC1759] defines the three character
+   set label objects 'prtLocalizationCharacterSet' (for description and
+   console strings), 'prtInterpreterDefaultCharSetIn' (for received
+
+
+
+
+McDonald                     Informational                     [Page 10]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+   print job input data), and 'prtIntpreterDefaultCharSetOut' (for
+   processed print job output data).
+
+   The IANA Charset MIB [CHARMIB] supports implementation of the best
+   practices specified in "IETF Policy on Character Sets and Languages"
+   [RFC2277].
+
+   Note:  The use of the 'SnmpAdminString' textual convention defined in
+   [RFC3411], which has a fixed character set of UTF-8 [RFC3629], is
+   STRONGLY RECOMMENDED in defining new MIB modules.  The IANA Charset
+   MIB [CHARMIB] supports locale-specific MIB objects with variable
+   character sets.
+
+7.  Security Considerations
+
+   This MIB module does not define any management objects.  Instead, it
+   defines a (set of) textual convention(s) which may be used by other
+   MIB modules to define management objects.
+
+   Meaningful security considerations can only be written in the MIB
+   modules that define management objects.  Therefore, this document has
+   no impact on the security of the Internet.
+
+8.  Acknowledgements
+
+   The editor would like to thank:  Bert Wijnen (Lucent) for his
+   original suggestion that the 'IANACharset' textual convention should
+   be extracted from Printer MIB v2 [RFC3805]; Ron Bergman (Hitachi
+   Printing Solutions) and Harry Lewis (IBM) for their many years of
+   effort as editors of Printer MIB v2 [RFC3805].
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2277]    Alvestrand, H., "IETF Policy on Character Sets and
+                Languages", RFC 2277, January 1998.
+
+   [RFC2578]    McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+                "Structure of Management Information Version 2 (SMIv2)",
+                STD 58, RFC 2578, April 1999.
+
+   [RFC2579]    McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+                "Textual Conventions for SMIv2", STD 58, RFC 2579, April
+                1999.
+
+
+
+McDonald                     Informational                     [Page 11]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+   [RFC2580]    McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+                "Conformance Statements for SMIv2", STD 58, RFC 2580,
+                April 1999.
+
+   [RFC2978]    Freed, N. and J. Postel, "IANA Charset Registration
+                Procedures", BCP 19, RFC 2978, October 2000.
+
+   [RFC3411]    Harrington, D., Presuhn, R., and B. Wijnen, "An
+                Architecture for Describing SNMP Network Management
+                Frameworks", STD 62, RFC 3411, December 2002.
+
+   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", RFC 3629, November 2003.
+
+9.2.  Informative References
+
+   [CHARGEN]    IANA Charset MIB Generation Utility (archived at):
+                ftp://www.pwg.org/pub/pwg/pmp/tools/ianachar.c
+
+   [CHARMIB]    IANA Charset MIB (in the future, to be archived at):
+                http://www.iana.org/assignments/ianacharset-mib
+
+   [CHARSET]    IANA Charset Registry (archived at):
+                http://www.iana.org/assignments/character-sets
+
+   [CHARTEMP]   IANA Charset MIB template file (archived at):
+                ftp://www.pwg.org/pub/pwg/pmp/tools/ianachar.dat
+
+   [RFC1759]    Smith, R., Wright, F., Hastings, T., Zilles, S., and J.
+                Gyllenskog.  "Printer MIB", RFC 1759, March 1995.
+
+   [RFC3805]    Bergman, R.,  Lewis, H., and I. McDonald, "Printer MIB
+                v2", RFC 3805, June 2004.
+
+   [RFC3410]    Case, J., Mundy, P., Partain, D., and B. Stewart,
+                "Introduction and Applicability Statements for
+                Internet-Standard Network Management Framework", RFC
+                3410, December 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald                     Informational                     [Page 12]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+10.  Authors' Addresses
+
+   Ira McDonald
+   High North Inc
+   221 Ridge Ave
+   Grand Marais, MI  49839
+   USA
+
+   Phone: +1 906 494 2434
+   EMail: imcdonald@sharplabs.com
+
+
+   Internet Assigned Numbers Authority (IANA)
+   ICANN
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA  90292
+   USA
+
+   Phone: +1 310 823 9358
+   EMail: iana@iana.org
+
+   Note:  Questions and comments on this IANA Charset MIB [CHARMIB]
+   should be sent to the editor (imcdonald@sharplabs.com) and IANA
+   (iana@iana.org) with a copy to the IETF Charsets mailing list
+   (ietf-charset@iana.org).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald                     Informational                     [Page 13]
+
+RFC 3808                    IANA Charset MIB                   June 2004
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+
+
+
+
+
+
+
+McDonald                     Informational                     [Page 14]
+
@@ -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]
+
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                    D. Crocker, Ed.
+Request for Comments: 4234                   Brandenburg InternetWorking
+Obsoletes: 2234                                               P. Overell
+Category: Standards Track                                      THUS plc.
+                                                            October 2005
+
+
+             Augmented BNF for Syntax Specifications: ABNF
+
+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
+
+   Internet technical specifications often need to define a formal
+   syntax.  Over the years, a modified version of Backus-Naur Form
+   (BNF), called Augmented BNF (ABNF), has been popular among many
+   Internet specifications.  The current specification documents ABNF.
+   It balances compactness and simplicity, with reasonable
+   representational power.  The differences between standard BNF and
+   ABNF involve naming rules, repetition, alternatives, order-
+   independence, and value ranges.  This specification also supplies
+   additional rule definitions and encoding for a core lexical analyzer
+   of the type common to several Internet specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                     [Page 1]
+
+RFC 4234                          ABNF                      October 2005
+
+
+Table of Contents
+
+   1. INTRODUCTION ....................................................2
+   2. RULE DEFINITION .................................................3
+      2.1. Rule Naming ................................................3
+      2.2. Rule Form ..................................................3
+      2.3. Terminal Values ............................................4
+      2.4. External Encodings .........................................5
+   3. OPERATORS .......................................................6
+      3.1. Concatenation:  Rule1 Rule2 ................................6
+      3.2. Alternatives:  Rule1 / Rule2 ...............................6
+      3.3. Incremental Alternatives: Rule1 =/ Rule2 ...................7
+      3.4. Value Range Alternatives:  %c##-## .........................7
+      3.5. Sequence Group:  (Rule1 Rule2) .............................8
+      3.6. Variable Repetition:  *Rule ................................8
+      3.7. Specific Repetition:  nRule ................................9
+      3.8. Optional Sequence:  [RULE] .................................9
+      3.9. Comment:  ; Comment ........................................9
+      3.10. Operator Precedence .......................................9
+   4. ABNF DEFINITION OF ABNF ........................................10
+   5. SECURITY CONSIDERATIONS ........................................11
+   6. References .....................................................11
+      6.1. Normative References ......................................11
+      6.2. Informative References ....................................11
+   Appendix A.  ACKNOWLEDGEMENTS .....................................13
+   Appendix B.  APPENDIX - CORE ABNF OF ABNF .........................13
+      B.1.  Core Rules ...............................................13
+      B.2.  Common Encoding ..........................................14
+
+1.  INTRODUCTION
+
+   Internet technical specifications often need to define a formal
+   syntax and are free to employ whatever notation their authors deem
+   useful.  Over the years, a modified version of Backus-Naur Form
+   (BNF), called Augmented BNF (ABNF), has been popular among many
+   Internet specifications.  It balances compactness and simplicity,
+   with reasonable representational power.  In the early days of the
+   Arpanet, each specification contained its own definition of ABNF.
+   This included the email specifications, [RFC733] and then [RFC822],
+   which came to be the common citations for defining ABNF.  The current
+   document separates those definitions to permit selective reference.
+   Predictably, it also provides some modifications and enhancements.
+
+   The differences between standard BNF and ABNF involve naming rules,
+   repetition, alternatives, order-independence, and value ranges.
+   Appendix B supplies rule definitions and encoding for a core lexical
+   analyzer of the type common to several Internet specifications.  It
+   is provided as a convenience and is otherwise separate from the meta
+
+
+
+Crocker & Overell           Standards Track                     [Page 2]
+
+RFC 4234                          ABNF                      October 2005
+
+
+   language defined in the body of this document, and separate from its
+   formal status.
+
+   Changes since [RFC2234]:
+
+      In Section 3.7, the phrase: "That is, exactly <N> occurrences of
+      <element>." was corrected to: "That is, exactly <n> occurrences of
+      <element>."
+
+      Some continuation comment lines needed to be corrected to begin
+      with comment character (";").
+
+2.  RULE DEFINITION
+
+2.1.  Rule Naming
+
+   The name of a rule is simply the name itself; that is, a sequence of
+   characters, beginning with an alphabetic character, and followed by a
+   combination of alphabetics, digits, and hyphens (dashes).
+
+   NOTE:
+
+      Rule names are case-insensitive
+
+   The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all
+   refer to the same rule.
+
+   Unlike original BNF, angle brackets ("<", ">") are not required.
+   However, angle brackets may be used around a rule name whenever their
+   presence facilitates in discerning the use of a rule name.  This is
+   typically restricted to rule name references in free-form prose, or
+   to distinguish partial rules that combine into a string not separated
+   by white space, such as shown in the discussion about repetition,
+   below.
+
+2.2.  Rule Form
+
+   A rule is defined by the following sequence:
+
+         name =  elements crlf
+
+   where <name> is the name of the rule, <elements> is one or more rule
+   names or terminal specifications, and <crlf> is the end-of-line
+   indicator (carriage return followed by line feed).  The equal sign
+   separates the name from the definition of the rule.  The elements
+   form a sequence of one or more rule names and/or value definitions,
+   combined according to the various operators defined in this document,
+   such as alternative and repetition.
+
+
+
+Crocker & Overell           Standards Track                     [Page 3]
+
+RFC 4234                          ABNF                      October 2005
+
+
+   For visual ease, rule definitions are left aligned.  When a rule
+   requires multiple lines, the continuation lines are indented.  The
+   left alignment and indentation are relative to the first lines of the
+   ABNF rules and need not match the left margin of the document.
+
+2.3.  Terminal Values
+
+   Rules resolve into a string of terminal values, sometimes called
+   characters.  In ABNF, a character is merely a non-negative integer.
+   In certain contexts, a specific mapping (encoding) of values into a
+   character set (such as ASCII) will be specified.
+
+   Terminals are specified by one or more numeric characters, with the
+   base interpretation of those characters indicated explicitly.  The
+   following bases are currently defined:
+
+         b           =  binary
+
+         d           =  decimal
+
+         x           =  hexadecimal
+
+   Hence:
+
+         CR          =  %d13
+
+         CR          =  %x0D
+
+   respectively specify the decimal and hexadecimal representation of
+   [US-ASCII] for carriage return.
+
+   A concatenated string of such values is specified compactly, using a
+   period (".") to indicate a separation of characters within that
+   value.  Hence:
+
+         CRLF        =  %d13.10
+
+   ABNF permits the specification of literal text strings directly,
+   enclosed in quotation-marks.  Hence:
+
+         command     =  "command string"
+
+   Literal text strings are interpreted as a concatenated set of
+   printable characters.
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                     [Page 4]
+
+RFC 4234                          ABNF                      October 2005
+
+
+   NOTE:
+
+      ABNF strings are case-insensitive and the character set for these
+      strings is us-ascii.
+
+   Hence:
+
+         rulename = "abc"
+
+   and:
+
+         rulename = "aBc"
+
+   will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
+   "ABC".
+
+      To specify a rule that IS case SENSITIVE, specify the characters
+      individually.
+
+   For example:
+
+         rulename    =  %d97 %d98 %d99
+
+   or
+
+         rulename    =  %d97.98.99
+
+   will match only the string that comprises only the lowercased
+   characters, abc.
+
+2.4.  External Encodings
+
+   External representations of terminal value characters will vary
+   according to constraints in the storage or transmission environment.
+   Hence, the same ABNF-based grammar may have multiple external
+   encodings, such as one for a 7-bit US-ASCII environment, another for
+   a binary octet environment, and still a different one when 16-bit
+   Unicode is used.  Encoding details are beyond the scope of ABNF,
+   although Appendix A (Core) provides definitions for a 7-bit US-ASCII
+   environment as has been common to much of the Internet.
+
+   By separating external encoding from the syntax, it is intended that
+   alternate encoding environments can be used for the same syntax.
+
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                     [Page 5]
+
+RFC 4234                          ABNF                      October 2005
+
+
+3.  OPERATORS
+
+3.1.  Concatenation:  Rule1 Rule2
+
+   A rule can define a simple, ordered string of values (i.e., a
+   concatenation of contiguous characters) by listing a sequence of rule
+   names.  For example:
+
+         foo         =  %x61           ; a
+
+         bar         =  %x62           ; b
+
+         mumble      =  foo bar foo
+
+   So that the rule <mumble> matches the lowercase string "aba".
+
+   LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing
+   model.  A string of contiguous characters (values) is parsed
+   according to the rules defined in ABNF.  For Internet specifications,
+   there is some history of permitting linear white space (space and
+   horizontal tab) to be freely and implicitly interspersed around major
+   constructs, such as delimiting special characters or atomic strings.
+
+   NOTE:
+
+      This specification for ABNF does not provide for implicit
+      specification of linear white space.
+
+   Any grammar that wishes to permit linear white space around
+   delimiters or string segments must specify it explicitly.  It is
+   often useful to provide for such white space in "core" rules that are
+   then used variously among higher-level rules.  The "core" rules might
+   be formed into a lexical analyzer or simply be part of the main
+   ruleset.
+
+3.2.  Alternatives:  Rule1 / Rule2
+
+   Elements separated by a forward slash ("/") are alternatives.
+   Therefore,
+
+         foo / bar
+
+   will accept <foo> or <bar>.
+
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                     [Page 6]
+
+RFC 4234                          ABNF                      October 2005
+
+
+   NOTE:
+
+      A quoted string containing alphabetic characters is a special form
+      for specifying alternative characters and is interpreted as a
+      non-terminal representing the set of combinatorial strings with
+      the contained characters, in the specified order but with any
+      mixture of upper and lower case.
+
+3.3.  Incremental Alternatives: Rule1 =/ Rule2
+
+   It is sometimes convenient to specify a list of alternatives in
+   fragments.  That is, an initial rule may match one or more
+   alternatives, with later rule definitions adding to the set of
+   alternatives.  This is particularly useful for otherwise, independent
+   specifications that derive from the same parent rule set, such as
+   often occurs with parameter lists.  ABNF permits this incremental
+   definition through the construct:
+
+         oldrule     =/ additional-alternatives
+
+   So that the rule set
+
+         ruleset     =  alt1 / alt2
+
+         ruleset     =/ alt3
+
+         ruleset     =/ alt4 / alt5
+
+   is the same as specifying
+
+         ruleset     =  alt1 / alt2 / alt3 / alt4 / alt5
+
+3.4.  Value Range Alternatives:  %c##-##
+
+   A range of alternative numeric values can be specified compactly,
+   using dash ("-") to indicate the range of alternative values.  Hence:
+
+         DIGIT       =  %x30-39
+
+   is equivalent to:
+
+         DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /
+
+                        "7" / "8" / "9"
+
+   Concatenated numeric values and numeric value ranges cannot be
+   specified in the same string.  A numeric value may use the dotted
+   notation for concatenation or it may use the dash notation to specify
+
+
+
+Crocker & Overell           Standards Track                     [Page 7]
+
+RFC 4234                          ABNF                      October 2005
+
+
+   one value range.  Hence, to specify one printable character between
+   end of line sequences, the specification could be:
+
+         char-line = %x0D.0A %x20-7E %x0D.0A
+
+3.5.  Sequence Group:  (Rule1 Rule2)
+
+   Elements enclosed in parentheses are treated as a single element,
+   whose contents are STRICTLY ORDERED.  Thus,
+
+         elem (foo / bar) blat
+
+   matches (elem foo blat) or (elem bar blat), and
+
+         elem foo / bar blat
+
+   matches (elem foo) or (bar blat).
+
+   NOTE:
+
+      It is strongly advised that grouping notation be used, rather than
+      relying on the proper reading of "bare" alternations, when
+      alternatives consist of multiple rule names or literals.
+
+   Hence, it is recommended that the following form be used:
+
+        (elem foo) / (bar blat)
+
+   It will avoid misinterpretation by casual readers.
+
+   The sequence group notation is also used within free text to set off
+   an element sequence from the prose.
+
+3.6.  Variable Repetition:  *Rule
+
+   The operator "*" preceding an element indicates repetition.  The full
+   form is:
+
+         <a>*<b>element
+
+   where <a> and <b> are optional decimal values, indicating at least
+   <a> and at most <b> occurrences of the element.
+
+   Default values are 0 and infinity so that *<element> allows any
+   number, including zero; 1*<element> requires at least one;
+   3*3<element> allows exactly 3 and 1*2<element> allows one or two.
+
+
+
+
+
+Crocker & Overell           Standards Track                     [Page 8]
+
+RFC 4234                          ABNF                      October 2005
+
+
+3.7.  Specific Repetition:  nRule
+
+   A rule of the form:
+
+         <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.
+
+3.8.  Optional Sequence:  [RULE]
+
+   Square brackets enclose an optional element sequence:
+
+         [foo bar]
+
+   is equivalent to
+
+         *1(foo bar).
+
+3.9.  Comment:  ; Comment
+
+   A semi-colon starts a comment that continues to the end of line.
+   This is a simple way of including useful notes in parallel with the
+   specifications.
+
+3.10.  Operator Precedence
+
+   The various mechanisms described above have the following precedence,
+   from highest (binding tightest) at the top, to lowest (loosest) at
+   the bottom:
+
+         Strings, Names formation
+
+         Comment
+
+         Value range
+
+         Repetition
+
+         Grouping, Optional
+
+         Concatenation
+
+         Alternative
+
+
+
+Crocker & Overell           Standards Track                     [Page 9]
+
+RFC 4234                          ABNF                      October 2005
+
+
+   Use of the alternative operator, freely mixed with concatenations,
+   can be confusing.
+
+      Again, it is recommended that the grouping operator be used to
+      make explicit concatenation groups.
+
+4.  ABNF DEFINITION OF ABNF
+
+   NOTES:
+
+      1. This syntax requires a formatting of rules that is relatively
+         strict.  Hence, the version of a ruleset included in a
+         specification might need preprocessing to ensure that it can be
+         interpreted by an ABNF parser.
+
+      2. This syntax uses the rules provided in Appendix B (Core).
+
+         rulelist       =  1*( rule / (*c-wsp c-nl) )
+
+         rule           =  rulename defined-as elements c-nl
+                                ; continues if next line starts
+                                ;  with white space
+
+         rulename       =  ALPHA *(ALPHA / DIGIT / "-")
+
+         defined-as     =  *c-wsp ("=" / "=/") *c-wsp
+                                ; basic rules definition and
+                                ;  incremental alternatives
+
+         elements       =  alternation *c-wsp
+
+         c-wsp          =  WSP / (c-nl WSP)
+
+         c-nl           =  comment / CRLF
+                                ; comment or newline
+
+         comment        =  ";" *(WSP / VCHAR) CRLF
+
+         alternation    =  concatenation
+                           *(*c-wsp "/" *c-wsp concatenation)
+
+         concatenation  =  repetition *(1*c-wsp repetition)
+
+         repetition     =  [repeat] element
+
+         repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)
+
+
+
+
+
+Crocker & Overell           Standards Track                    [Page 10]
+
+RFC 4234                          ABNF                      October 2005
+
+
+         element        =  rulename / group / option /
+                           char-val / num-val / prose-val
+
+         group          =  "(" *c-wsp alternation *c-wsp ")"
+
+         option         =  "[" *c-wsp alternation *c-wsp "]"
+
+         char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
+                                ; quoted string of SP and VCHAR
+                                ;  without DQUOTE
+
+         num-val        =  "%" (bin-val / dec-val / hex-val)
+
+         bin-val        =  "b" 1*BIT
+                           [ 1*("." 1*BIT) / ("-" 1*BIT) ]
+                                ; series of concatenated bit values
+                                ;  or single ONEOF range
+
+         dec-val        =  "d" 1*DIGIT
+                           [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
+
+         hex-val        =  "x" 1*HEXDIG
+                           [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
+
+         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
+                                ; bracketed string of SP and VCHAR
+                                ;  without angles
+                                ; prose description, to be used as
+                                ;  last resort
+
+5.  SECURITY CONSIDERATIONS
+
+   Security is truly believed to be irrelevant to this document.
+
+6.  References
+
+6.1.  Normative References
+
+   [US-ASCII] American National Standards Institute, "Coded Character
+              Set -- 7-bit American Standard Code for Information
+              Interchange", ANSI X3.4, 1986.
+
+6.2.  Informative References
+
+   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+
+
+
+
+Crocker & Overell           Standards Track                    [Page 11]
+
+RFC 4234                          ABNF                      October 2005
+
+
+   [RFC733]   Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
+              "Standard for the format of ARPA network text messages",
+              RFC 733, November 1977.
+
+   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
+              text messages", STD 11, RFC 822, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                    [Page 12]
+
+RFC 4234                          ABNF                      October 2005
+
+
+Appendix A.  ACKNOWLEDGEMENTS
+
+   The syntax for ABNF was originally specified in RFC 733.  Ken L.
+   Harrenstien, of SRI International, was responsible for re-coding the
+   BNF into an augmented BNF that makes the representation smaller and
+   easier to understand.
+
+   This recent project began as a simple effort to cull out the portion
+   of RFC 822 that has been repeatedly cited by non-email specification
+   writers, namely the description of augmented BNF.  Rather than simply
+   and blindly converting the existing text into a separate document,
+   the working group chose to give careful consideration to the
+   deficiencies, as well as benefits, of the existing specification and
+   related specifications made available over the last 15 years, and
+   therefore to pursue enhancement.  This turned the project into
+   something rather more ambitious than was first intended.
+   Interestingly, the result is not massively different from that
+   original, although decisions, such as removing the list notation,
+   came as a surprise.
+
+   This "separated" version of the specification was part of the DRUMS
+   working group, with significant contributions from Jerome Abela,
+   Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom
+   Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete
+   Resnick, and Henning Schulzrinne.
+
+   Julian Reschke warrants a special thanks for converting the Draft
+   Standard version to XML source form.
+
+Appendix B.  APPENDIX - CORE ABNF OF ABNF
+
+   This Appendix is provided as a convenient core for specific grammars.
+   The definitions may be used as a core set of rules.
+
+B.1.  Core Rules
+
+   Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT,
+   ALPHA, etc.
+
+         ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
+
+         BIT            =  "0" / "1"
+
+         CHAR           =  %x01-7F
+                                ; any 7-bit US-ASCII character,
+                                ;  excluding NUL
+
+
+
+
+
+Crocker & Overell           Standards Track                    [Page 13]
+
+RFC 4234                          ABNF                      October 2005
+
+
+         CR             =  %x0D
+                                ; carriage return
+
+         CRLF           =  CR LF
+                                ; Internet standard newline
+
+         CTL            =  %x00-1F / %x7F
+                                ; controls
+
+         DIGIT          =  %x30-39
+                                ; 0-9
+
+         DQUOTE         =  %x22
+                                ; " (Double Quote)
+
+         HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
+
+         HTAB           =  %x09
+                                ; horizontal tab
+
+         LF             =  %x0A
+                                ; linefeed
+
+         LWSP           =  *(WSP / CRLF WSP)
+                                ; linear white space (past newline)
+
+         OCTET          =  %x00-FF
+                                ; 8 bits of data
+
+         SP             =  %x20
+
+         VCHAR          =  %x21-7E
+                                ; visible (printing) characters
+
+         WSP            =  SP / HTAB
+                                ; white space
+
+B.2.  Common Encoding
+
+   Externally, data are represented as "network virtual ASCII" (namely,
+   7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
+   zero.  A string of values is in "network byte order", in which the
+   higher-valued bytes are represented on the left-hand side and are
+   sent over the network first.
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                    [Page 14]
+
+RFC 4234                          ABNF                      October 2005
+
+
+Authors' Addresses
+
+   Dave Crocker (editor)
+   Brandenburg InternetWorking
+   675 Spruce Dr.
+   Sunnyvale, CA  94086
+   US
+
+   Phone: +1.408.246.8253
+   EMail: dcrocker@bbiw.net
+
+
+   Paul Overell
+   THUS plc.
+   1/2 Berkeley Square
+   99 Berkeley Street
+   Glasgow
+   G3 7HR
+   UK
+
+   EMail: paul.overell@thus.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                    [Page 15]
+
+RFC 4234                          ABNF                      October 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.
+
+
+
+
+
+
+
+Crocker & Overell           Standards Track                    [Page 16]
+
@@ -0,0 +1,504 @@
+/*
+ * "$Id$"
+ *
+ *   RFC file to HTML conversion program.
+ *
+ *   Copyright 2007-2011 by Apple Inc.
+ *   Copyright 2006 by Easy Software Products.
+ *
+ *   These coded instructions, statements, and computer programs are the
+ *   property of Apple Inc. and are protected by Federal copyright
+ *   law.  Distribution and use rights are outlined in the file "LICENSE.txt"
+ *   which should have been included with this file.  If this file is
+ *   file is missing or damaged, see the license at "http://www.cups.org/".
+ *
+ * Contents:
+ *
+ *   main()       - Convert a man page to HTML.
+ *   put_entity() - Put a single character, using entities as needed.
+ *   put_line()   - Put a whole string for a line.
+ */
+
+/*
+ * Include necessary headers.
+ */
+
+#include <cups/string-private.h>
+#include <stdlib.h>
+#include <cups/file.h>
+
+
+/*
+ * Local functions...
+ */
+
+void	put_entity(cups_file_t *fp, int ch);
+void	put_line(cups_file_t *fp, const char *line);
+
+
+/*
+ * 'main()' - Convert a man page to HTML.
+ */
+
+int					/* O - Exit status */
+main(int  argc,				/* I - Number of command-line args */
+     char *argv[])			/* I - Command-line arguments */
+{
+  cups_file_t	*infile,		/* Input file */
+		*outfile;		/* Output file */
+  char		line[1024],		/* Line from file */
+		*lineptr,		/* Pointer into line */
+		title[2048],		/* Title string */
+		*titleptr,		/* Pointer into title */
+		name[1024],		/* Heading anchor name */
+		*nameptr;		/* Pointer into anchor name */
+  int		rfc,			/* RFC # */
+		inheading,		/* Inside a heading? */
+		inpre,			/* Inside preformatted text? */
+		intoc,			/* Inside table-of-contents? */
+		toclevel,		/* Current table-of-contents level */
+		linenum;		/* Current line on page */
+
+
+ /*
+  * Check arguments...
+  */
+
+  if (argc > 3)
+  {
+    fputs("Usage: rfctohtml [rfcNNNN.txt [rfcNNNN.html]]\n", stderr);
+    return (1);
+  }
+
+ /*
+  * Open files as needed...
+  */
+
+  if (argc > 1)
+  {
+    if ((infile = cupsFileOpen(argv[1], "r")) == NULL)
+    {
+      perror(argv[1]);
+      return (1);
+    }
+  }
+  else
+    infile = cupsFileOpenFd(0, "r");
+
+  if (argc > 2)
+  {
+    if ((outfile = cupsFileOpen(argv[2], "w")) == NULL)
+    {
+      perror(argv[2]);
+      cupsFileClose(infile);
+      return (1);
+    }
+  }
+  else
+    outfile = cupsFileOpenFd(1, "w");
+
+ /*
+  * Read from input and write the output...
+  */
+
+  cupsFilePuts(outfile,
+	       "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" "
+	       "\"http://www.w3.org/TR/html4/loose.dtd\">\n"
+	       "<html>\n"
+	       "<!-- SECTION: Specifications -->\n"
+	       "<head>\n"
+	       "\t<link rel=\"stylesheet\" type=\"text/css\" "
+	       "href=\"../cups-printable.css\">\n");
+
+ /*
+  * Skip the initial header stuff (working group ID, RFC #, authors, and
+  * copyright...
+  */
+
+  linenum = 0;
+  rfc     = 0;
+
+  while (cupsFileGets(infile, line, sizeof(line)))
+  {
+    linenum ++;
+
+    if (line[0])
+      break;
+  }
+
+  while (cupsFileGets(infile, line, sizeof(line)))
+  {
+    linenum ++;
+
+    if (!line[0])
+      break;
+    else if (!_cups_strncasecmp(line, "Request for Comments:", 21))
+      rfc = atoi(line + 21);
+  }
+
+ /*
+  * Read the document title...
+  */
+
+  while (cupsFileGets(infile, line, sizeof(line)))
+  {
+    linenum ++;
+
+    if (line[0])
+      break;
+  }
+
+  for (lineptr = line; isspace(*lineptr & 255); lineptr ++);
+
+  snprintf(title, sizeof(title), "RFC %d: %s", rfc, lineptr);
+  titleptr = title + strlen(title);
+
+  while (cupsFileGets(infile, line, sizeof(line)))
+  {
+    linenum ++;
+
+    if (!line[0])
+      break;
+    else
+    {
+      for (lineptr = line; isspace(*lineptr & 255); lineptr ++);
+
+      snprintf(titleptr, sizeof(title) - (titleptr - title), " %s", lineptr);
+      titleptr += strlen(titleptr);
+    }
+  }
+
+  cupsFilePrintf(outfile, "\t<title>%s</title>\n"
+			  "</head>\n"
+			  "<body>\n"
+			  "<h1 class='title'>%s</h1>\n", title, title);
+
+ /*
+  * Read the rest of the file...
+  */
+
+  inheading = 0;
+  inpre     = 0;
+  intoc     = 0;
+  toclevel  = 0;
+
+  while (cupsFileGets(infile, line, sizeof(line)))
+  {
+    linenum ++;
+
+    if (!line[0])
+    {
+      if (linenum > 50)
+        continue;
+
+      if (inpre)
+      {
+	cupsFilePuts(outfile, "</pre>\n");
+	inpre = 0;
+      }
+
+      if (inheading)
+      {
+	if (inheading < 0)
+	  cupsFilePuts(outfile, "</h2>\n");
+	else
+	  cupsFilePrintf(outfile, "</a></h%d>\n", inheading);
+
+        inheading = 0;
+      }
+    }
+    else if ((line[0] == ' ' ||
+              (!isupper(line[0] & 255) && !isdigit(line[0] & 255) &&
+	       !strstr(line, "[Page "))) && !inheading)
+    {
+      if (inheading)
+      {
+	if (inheading < 0)
+	  cupsFilePuts(outfile, "</h2>\n");
+	else
+	  cupsFilePrintf(outfile, "</a></h%d>\n", inheading);
+
+        inheading = 0;
+      }
+
+      for (lineptr = line; *lineptr == ' '; lineptr ++);
+
+      if (intoc)
+      {
+        char	*temp;			/* Temporary pointer into line */
+	int	level;			/* Heading level */
+
+
+        if (isdigit(*lineptr & 255))
+	{
+	  strlcpy(name, lineptr, sizeof(name));
+
+	  for (nameptr = name, level = -1; *nameptr;)
+	    if (isdigit(*nameptr & 255))
+	    {
+	      while (isdigit(*nameptr & 255))
+		nameptr ++;
+
+	      level ++;
+	    }
+	    else if (*nameptr == ' ')
+	    {
+	      *nameptr = '\0';
+	      break;
+	    }
+	    else
+	      nameptr ++;
+
+	  while (toclevel > level)
+	  {
+	    cupsFilePuts(outfile, "\n</ul>");
+	    toclevel --;
+	  }
+
+	  while (toclevel < level)
+	  {
+	    cupsFilePuts(outfile, "\n<ul style=\"list-style-type: none;\">\n");
+	    toclevel ++;
+	  }
+
+	  cupsFilePrintf(outfile, "\n<%s><a href=\"#s%s\">", toclevel ? "li" : "p",
+	                 name);
+	}
+
+        temp = lineptr + strlen(lineptr) - 1;
+
+	while (temp > lineptr)
+	  if (*temp == ' ' || !isdigit(*temp & 255))
+	    break;
+	  else
+	    temp --;
+
+        if (*temp == ' ')
+	{
+	  while (temp > lineptr)
+	    if (*temp != ' ' && *temp != '.')
+	      break;
+	    else
+	      *temp-- = '\0';
+	}
+	else
+	  temp = NULL;
+
+        if (isdigit(*lineptr & 255))
+          put_line(outfile, lineptr);
+	else
+	  put_line(outfile, lineptr - 1);
+
+        if (temp)
+	  cupsFilePuts(outfile, "</a>");
+      }
+      else if (!inpre)
+      {
+	cupsFilePuts(outfile, "\n<pre>");
+	put_line(outfile, line);
+	inpre = 1;
+      }
+      else
+      {
+	cupsFilePutChar(outfile, '\n');
+	put_line(outfile, line);
+      }
+    }
+    else if (strstr(line, "[Page "))
+    {
+     /*
+      * Skip page footer and header...
+      */
+
+      cupsFileGets(infile, line, sizeof(line));
+      cupsFileGets(infile, line, sizeof(line));
+      cupsFileGets(infile, line, sizeof(line));
+      cupsFileGets(infile, line, sizeof(line));
+      linenum = 3;
+    }
+    else if (isdigit(line[0] & 255) && !inheading)
+    {
+      int level;			/* Heading level */
+
+
+      if (intoc)
+      {
+        while (toclevel > 0)
+	{
+	  cupsFilePuts(outfile, "\n</ul>");
+	  toclevel --;
+	}
+
+	cupsFilePutChar(outfile, '\n');
+	intoc = 0;
+      }
+
+      if (inpre)
+      {
+	cupsFilePuts(outfile, "</pre>\n");
+	inpre = 0;
+      }
+
+      strlcpy(name, line, sizeof(name));
+      for (nameptr = name, level = 1; *nameptr;)
+        if (isdigit(*nameptr & 255))
+	{
+	  while (isdigit(*nameptr & 255))
+	    nameptr ++;
+
+          level ++;
+	}
+	else if (*nameptr == ' ')
+	{
+	  *nameptr = '\0';
+	  break;
+	}
+	else
+	  nameptr ++;
+
+      cupsFilePrintf(outfile, "\n<h%d class='title'><a name='s%s'>", level,
+                     name);
+      put_line(outfile, line);
+
+      intoc     = 0;
+      inheading = level;
+    }
+    else
+    {
+      if (intoc)
+      {
+        while (toclevel > 0)
+	{
+	  cupsFilePuts(outfile, "\n</ul>");
+	  toclevel --;
+	}
+
+	cupsFilePutChar(outfile, '\n');
+	intoc = 0;
+      }
+
+      if (!inheading)
+      {
+        cupsFilePuts(outfile, "\n<h2 class='title'>");
+        inheading = -1;
+      }
+
+      put_line(outfile, line);
+
+      intoc    = !_cups_strcasecmp(line, "Table of Contents");
+      toclevel = 0;
+    }
+  }
+
+  if (inpre)
+    cupsFilePuts(outfile, "</pre>\n");
+
+  if (inheading)
+  {
+    if (inheading < 0)
+      cupsFilePuts(outfile, "</h2>\n");
+    else
+      cupsFilePrintf(outfile, "</a></h%d>\n", inheading);
+  }
+
+  cupsFilePuts(outfile, "</body>\n"
+                        "</html>\n");
+
+ /*
+  * Close files...
+  */
+
+  cupsFileClose(infile);
+  cupsFileClose(outfile);
+
+ /*
+  * Return with no errors...
+  */
+
+  return (0);
+}
+
+
+/*
+ * 'put_entity()' - Put a single character, using entities as needed.
+ */
+
+void
+put_entity(cups_file_t *fp,		/* I - File */
+           int         ch)		/* I - Character */
+{
+  if (ch == '&')
+    cupsFilePuts(fp, "&amp;");
+  else if (ch == '<')
+    cupsFilePuts(fp, "&lt;");
+  else
+    cupsFilePutChar(fp, ch);
+}
+
+
+/*
+ * 'put_line()' - Put a whole string for a line.
+ */
+
+void
+put_line(cups_file_t *fp,		/* I - File */
+         const char  *s)		/* I - String */
+{
+  int	whitespace,			/* Saw whitespace */
+	i,				/* Looping var */
+	len;				/* Length of keyword */
+  static const char * const keywords[] =/* Special keywords to boldface */
+  {
+    "MAY",
+    "MUST",
+    "NEED",
+    "NOT",
+    "OPTIONAL",
+    "OPTIONALLY",
+    "RECOMMENDED",
+    "REQUIRED",
+    "SHALL",
+    "SHOULD"
+  };
+
+
+  whitespace = 1;
+
+  while (*s)
+  {
+    if (*s == ' ')
+      whitespace = 1;
+
+    if (whitespace && isupper(*s & 255))
+    {
+      whitespace = 0;
+
+      for (i = 0; i < (int)(sizeof(keywords) / sizeof(sizeof(keywords[0]))); i ++)
+      {
+        len = strlen(keywords[i]);
+	if (!strncmp(s, keywords[i], len) &&
+	    (isspace(s[len] & 255) || ispunct(s[len] & 255) || !*s))
+	{
+	  cupsFilePrintf(fp, "<b>%s</b>", keywords[i]);
+	  s += len;
+	  break;
+	}
+      }
+
+      if (i >= (int)(sizeof(keywords) / sizeof(sizeof(keywords[0]))))
+        put_entity(fp, *s++);
+    }
+    else
+    {
+      if (*s != ' ')
+        whitespace = 0;
+
+      put_entity(fp, *s++);
+    }
+  }
+}
+
+
+/*
+ * End of "$Id$".
+ */
@@ -1,9 +1,9 @@
 #
-# "$Id: ipp-1.1.test 9830 2011-06-14 21:11:17Z mike $"
+# "$Id: ipp-1.1.test 9405 2010-12-08 07:13:22Z mike $"
 #
 #   IPP/1.1 test suite.
 #
-#   Copyright 2007-2011 by Apple Inc.
+#   Copyright 2007-2010 by Apple Inc.
 #   Copyright 2001-2006 by Easy Software Products. All rights reserved.
 #
 #   These coded instructions, statements, and computer programs are the
@@ -17,10 +17,6 @@
 #   ./ipptool -f filename -t printer-uri ipp-1.1.test
 #

-# Regular expression for IPP URI schemes
-# Matches strings beginning with ipp:// or ipps://
-DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"
-
 # Test that a request-id value of 0 is not accepted.
 #
 # Required by: RFC 2911 section 3.1.1
@@ -91,7 +87,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"
 	ATTR uri printer-uri $uri

 	STATUS successful-ok
-	EXPECT printer-uri-supported OF-TYPE uri WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT printer-uri-supported OF-TYPE uri
 }


@@ -148,7 +144,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	STATUS client-error-document-format-not-supported
-	EXPECT job-uri OF-TYPE uri COUNT 1 IN-GROUP job-attributes-tag WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri COUNT 1 IN-GROUP job-attributes-tag
 	EXPECT job-id OF-TYPE integer COUNT 1 IN-GROUP job-attributes-tag
 	       WITH-VALUE >0
 	EXPECT job-state OF-TYPE enum COUNT 1 IN-GROUP job-attributes-tag
@@ -241,7 +237,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"
 	EXPECT printer-state OF-TYPE enum IN-GROUP printer-attributes-tag COUNT 1 WITH-VALUE 3,4,5
 	EXPECT printer-state-reasons OF-TYPE keyword IN-GROUP printer-attributes-tag
 	EXPECT printer-up-time OF-TYPE integer IN-GROUP printer-attributes-tag COUNT 1 WITH-VALUE >0
-	EXPECT printer-uri-supported OF-TYPE uri IN-GROUP printer-attributes-tag SAME-COUNT-AS uri-security-supported WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT printer-uri-supported OF-TYPE uri IN-GROUP printer-attributes-tag SAME-COUNT-AS uri-security-supported
 	EXPECT queued-job-count OF-TYPE integer IN-GROUP printer-attributes-tag COUNT 1
 	EXPECT uri-authentication-supported OF-TYPE keyword IN-GROUP printer-attributes-tag
 	EXPECT uri-security-supported OF-TYPE keyword IN-GROUP printer-attributes-tag SAME-COUNT-AS uri-authentication-supported
@@ -264,7 +260,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok

-	EXPECT printer-uri-supported OF-TYPE uri IN-GROUP printer-attributes-tag WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT printer-uri-supported OF-TYPE uri IN-GROUP printer-attributes-tag
 	EXPECT !printer-name
 }

@@ -283,7 +279,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	EXPECT job-id OF-TYPE integer IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE >0
-	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT !job-printer-uri
 	EXPECT !job-more-info
 	EXPECT !job-name
@@ -341,7 +337,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	EXPECT job-id OF-TYPE integer IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE >0
-	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT job-printer-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT ?job-more-info OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT job-name OF-TYPE name IN-GROUP job-attributes-tag COUNT 1
@@ -399,7 +395,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	EXPECT job-id OF-TYPE integer IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE >0
-	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT !job-printer-uri
 	EXPECT !job-more-info
 	EXPECT !job-name
@@ -519,7 +515,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	EXPECT job-id OF-TYPE integer IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE >0
-	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT !job-printer-uri
 	EXPECT !job-more-info
 	EXPECT !job-name
@@ -579,7 +575,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	EXPECT job-id OF-TYPE integer IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE >0
-	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT !job-printer-uri
 	EXPECT !job-more-info
 	EXPECT !job-name
@@ -659,7 +655,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	STATUS client-error-document-format-not-supported
-	EXPECT job-uri OF-TYPE uri COUNT 1 IN-GROUP job-attributes-tag WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri COUNT 1 IN-GROUP job-attributes-tag
 	EXPECT job-id OF-TYPE integer COUNT 1 IN-GROUP job-attributes-tag
 	       WITH-VALUE >0
 	EXPECT job-state OF-TYPE enum COUNT 1 IN-GROUP job-attributes-tag
@@ -704,7 +700,7 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"

 	STATUS successful-ok
 	EXPECT job-id OF-TYPE integer IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE >0
-	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE "$IPP_URI_SCHEME"
+	EXPECT job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT job-printer-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT ?job-more-info OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1
 	EXPECT job-name OF-TYPE name IN-GROUP job-attributes-tag COUNT 1
@@ -748,5 +744,5 @@ DEFINE IPP_URI_SCHEME "/^ipps?://.+$$/"


 #
-# End of "$Id: ipp-1.1.test 9830 2011-06-14 21:11:17Z mike $".
+# End of "$Id: ipp-1.1.test 9405 2010-12-08 07:13:22Z mike $".
 #
@@ -2569,11 +2569,11 @@ do_tests(_cups_vars_t *vars,		/* I - Variables */
 	puts("</array>");
    }

-    skip_error:
-
    if (Output == _CUPS_OUTPUT_PLIST)
      puts("</dict>");

+    skip_error:
+
    ippDelete(response);
    response = NULL;

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# "$Id: makesrcdist 9852 2011-07-06 20:14:24Z mike $"
+# "$Id: makesrcdist 9086 2010-04-07 18:46:04Z mike $"
 #
 # makesrcdist - make a source distribution of CUPS.
 #
@@ -54,6 +54,7 @@ cd ..
 echo Configuring...
 autoconf -f
 rm -rf autom4te*.cache
+rm -rf standards
 rm -rf tools
 cd ..

@@ -86,5 +87,5 @@ rm -rf cups-$version
 echo "Done!"

 #
-# End of "$Id: makesrcdist 9852 2011-07-06 20:14:24Z mike $".
+# End of "$Id: makesrcdist 9086 2010-04-07 18:46:04Z mike $".
 #