CHANGES IN CUPS V1.3.11
- - The web interface could hang on OpenBSD (STR #3176)
+ - The scheduler did not handle partial header lines properly from CGI
+ programs (STR #3194)
+ - The web interface could hang on OpenBSD (STR #3176, STR #3196)
- The scheduler and cupsfilter utility did not handle rules starting
with a negation operator properly (STR #3160)
- The scheduler and cupsfilter utility would crash with certain MIME
-CHANGES.txt - 2009-05-14
+CHANGES.txt - 2009-05-16
------------------------
CHANGES IN CUPS V1.4b3
- - Documentation fixes (STR #3044, STR #3057, STR #3153)
+ - Documentation fixes (STR #3044, STR #3057, STR #3153, STR #3158,
+ STR #3173)
- Added complete localizations for German, Japanese, Polish, and
Russian and partial localizations for Chinese, Danish, Finnish,
French, Italian, Korean, Norwegian, Portuguese, and Swedish
(STR #3096, STR #3098, STR #3109, STR #3111, STR #3141)
+ - Updated the configure check for -fstack-protector (STR #3198)
+ - The network backends now correctly convert SNMP supply descriptions to
+ UTF-8 encoding as needed.
- The scheduler could crash when deleting an attribute (STR #3197)
- The cups-driverd program did not detect symlink loops (STR #3185)
- The EPSON 24-pin series driver should now feed the correct amount
*
* Backend support definitions for the Common UNIX Printing System (CUPS).
*
- * Copyright 2007-2008 by Apple Inc.
+ * Copyright 2007-2009 by Apple Inc.
* Copyright 1997-2007 by Easy Software Products, all rights reserved.
*
* These coded instructions, statements, and computer programs are the
#define CUPS_OID_prtGeneral CUPS_OID_printmib,5
#define CUPS_OID_prtGeneralTable CUPS_OID_prtGeneral,1
#define CUPS_OID_prtGeneralEntry CUPS_OID_prtGeneralTable,1
+#define CUPS_OID_prtGeneralCurrentLocalization CUPS_OID_prtGeneralEntry,2
#define CUPS_OID_prtGeneralPrinterName CUPS_OID_prtGeneralEntry,16
#define CUPS_OID_prtGeneralSerialNumber CUPS_OID_prtGeneralEntry,17
#define CUPS_OID_prtCoverDescription CUPS_OID_prtCoverEntry,2
#define CUPS_OID_prtCoverStatus CUPS_OID_prtCoverEntry,3
+#define CUPS_OID_prtLocalization CUPS_OID_printmib,7
+#define CUPS_OID_prtLocalizationTable CUPS_OID_prtLocalization,1
+#define CUPS_OID_prtLocalizationEntry CUPS_OID_prtLocalizationTable,1
+#define CUPS_OID_prtLocalizationCharacterSet CUPS_OID_prtLocalizationEntry,4
+
#define CUPS_OID_prtMarker CUPS_OID_printmib,10
#define CUPS_OID_prtMarkerTable CUPS_OID_prtMarker,2
#define CUPS_OID_prtMarkerEntry CUPS_OID_prtMarkerTable,1
#define CUPS_TC_inserts 33
#define CUPS_TC_covers 34
+/* These come from RFC 3808 to define character sets we support */
+/* Also see http://www.iana.org/assignments/character-sets */
+#define CUPS_TC_csASCII 3
+#define CUPS_TC_csISOLatin1 4
+#define CUPS_TC_csShiftJIS 17
+#define CUPS_TC_csUTF8 106
+#define CUPS_TC_csUnicode 1000 /* UCS2 BE */
+#define CUPS_TC_csUCS4 1001 /* UCS4 BE */
+#define CUPS_TC_csUnicodeASCII 1002
+#define CUPS_TC_csUnicodeLatin1 1003
+#define CUPS_TC_csUTF16BE 1013
+#define CUPS_TC_csUTF16LE 1014
+#define CUPS_TC_csUTF32 1017
+#define CUPS_TC_csUTF32BE 1018
+#define CUPS_TC_csUTF32LE 1019
+
/*
* Prototypes...
}
while (http == NULL);
- if (job_cancelled)
+ if (job_cancelled || !http)
{
if (tmpfilename[0])
unlink(tmpfilename);
httpReconnect(http);
}
else
+ {
+ /*
+ * Update auth-info-required as needed...
+ */
+
_cupsLangPrintf(stderr, _("ERROR: Print file was not accepted (%s)!\n"),
cupsLastErrorString());
+
+ if (ipp_status == IPP_NOT_AUTHORIZED)
+ {
+ fprintf(stderr, "DEBUG: WWW-Authenticate=\"%s\"\n",
+ httpGetField(http, HTTP_FIELD_WWW_AUTHENTICATE));
+
+ if (!strncmp(httpGetField(http, HTTP_FIELD_WWW_AUTHENTICATE),
+ "Negotiate", 9))
+ fputs("ATTR: auth-info-required=negotiate\n", stderr);
+ else
+ fputs("ATTR: auth-info-required=username,password\n", stderr);
+ }
+ }
}
else if ((job_id_attr = ippFindAttribute(response, "job-id",
IPP_TAG_INTEGER)) == NULL)
page_count > start_count)
fprintf(stderr, "PAGE: total %d\n", page_count - start_count);
- /*
- * Update auth-info-required as needed...
- */
-
- if (ipp_status == IPP_NOT_AUTHORIZED)
- {
- if (!strncmp(httpGetField(http, HTTP_FIELD_WWW_AUTHENTICATE),
- "Negotiate", 9))
- fputs("ATTR: auth-info-required=negotiate\n", stderr);
- else
- fputs("ATTR: auth-info-required=username,password\n", stderr);
- }
-
/*
* Free memory...
*/
*
* backendSNMPSupplies() - Get the current supplies for a device.
* backend_init_supplies() - Initialize the supplies list.
- * backend_walk_cb() - Interpret the supply value responses...
+ * backend_walk_cb() - Interpret the supply value responses.
+ * utf16_to_utf8() - Convert UTF-16 text to UTF-8.
*/
/*
*/
#define CUPS_MAX_SUPPLIES 32 /* Maximum number of supplies for a printer */
+#define CUPS_SUPPLY_TIMEOUT 2.0 /* Timeout for SNMP lookups */
/*
static http_addr_t current_addr; /* Current address */
static int current_state = -1;
/* Current device state bits */
+static int charset = -1; /* Character set for supply names */
static int num_supplies = 0;
/* Number of supplies found */
static backend_supplies_t supplies[CUPS_MAX_SUPPLIES];
static const int hrPrinterDetectedErrorState[] =
{ CUPS_OID_hrPrinterDetectedErrorState, 1, -1 };
/* Current printer state bits OID */
+static const int prtGeneralCurrentLocalization[] =
+ { CUPS_OID_prtGeneralCurrentLocalization, 1, -1 };
+static const int prtLocalizationCharacterSet[] =
+ { CUPS_OID_prtLocalizationCharacterSet, 1, 1, -1 },
+ prtLocalizationCharacterSetOffset =
+ (sizeof(prtLocalizationCharacterSet) /
+ sizeof(prtLocalizationCharacterSet[0]));
static const int prtMarkerColorantValue[] =
{ CUPS_OID_prtMarkerColorantValue, -1 },
/* Colorant OID */
static void backend_init_supplies(int snmp_fd, http_addr_t *addr);
static void backend_walk_cb(cups_snmp_t *packet, void *data);
+static void utf16_to_utf8(cups_utf8_t *dst, const unsigned char *src,
+ size_t srcsize, size_t dstsize, int le);
/*
backend_init_supplies(snmp_fd, addr);
else if (num_supplies > 0)
_cupsSNMPWalk(snmp_fd, ¤t_addr, CUPS_SNMP_VERSION_1,
- _cupsSNMPDefaultCommunity(), prtMarkerSuppliesLevel, 0.5,
- backend_walk_cb, NULL);
+ _cupsSNMPDefaultCommunity(), prtMarkerSuppliesLevel,
+ CUPS_SUPPLY_TIMEOUT, backend_walk_cb, NULL);
if (page_count)
*page_count = -1;
hrPrinterDetectedErrorState))
return (-1);
- if (!_cupsSNMPRead(snmp_fd, &packet, 0.5) ||
+ if (!_cupsSNMPRead(snmp_fd, &packet, CUPS_SUPPLY_TIMEOUT) ||
packet.object_type != CUPS_ASN1_OCTET_STRING)
return (-1);
hrPrinterStatus))
return (-1);
- if (!_cupsSNMPRead(snmp_fd, &packet, 0.5) ||
+ if (!_cupsSNMPRead(snmp_fd, &packet, CUPS_SUPPLY_TIMEOUT) ||
packet.object_type != CUPS_ASN1_INTEGER)
return (-1);
prtMarkerLifeCount))
return (-1);
- if (!_cupsSNMPRead(snmp_fd, &packet, 0.5) ||
+ if (!_cupsSNMPRead(snmp_fd, &packet, CUPS_SUPPLY_TIMEOUT) ||
packet.object_type != CUPS_ASN1_COUNTER)
return (-1);
current_addr = *addr;
current_state = -1;
num_supplies = -1;
+ charset = -1;
memset(supplies, 0, sizeof(supplies));
hrDeviceDescr))
return;
- if (!_cupsSNMPRead(snmp_fd, &packet, 0.5) ||
+ if (!_cupsSNMPRead(snmp_fd, &packet, CUPS_SUPPLY_TIMEOUT) ||
packet.object_type != CUPS_ASN1_OCTET_STRING)
{
strlcpy(description, "Unknown", sizeof(description));
strlcpy(description, (char *)packet.object_value.string.bytes,
sizeof(description));
+ fprintf(stderr, "DEBUG2: hrDeviceDesc=\"%s\"\n", description);
+
/*
* See if we have already queried this device...
*/
/*
* Yes, read the cache file:
*
- * 1 num_supplies
+ * 2 num_supplies charset
* device description
* supply structures...
*/
if (cupsFileGets(cachefile, value, sizeof(value)))
{
- if (sscanf(value, "1 %d", &num_supplies) == 1 &&
+ if (sscanf(value, "2 %d%d", &num_supplies, &charset) == 2 &&
num_supplies <= CUPS_MAX_SUPPLIES &&
cupsFileGets(cachefile, value, sizeof(value)))
{
- if ((ptr = value + strlen(value) - 1) >= value && *ptr == '\n')
- *ptr = '\n';
-
if (!strcmp(description, value))
cupsFileRead(cachefile, (char *)supplies,
num_supplies * sizeof(backend_supplies_t));
else
+ {
num_supplies = -1;
+ charset = -1;
+ }
}
else
+ {
num_supplies = -1;
+ charset = -1;
+ }
}
cupsFileClose(cachefile);
* If the cache information isn't correct, scan for supplies...
*/
+ if (charset < 0)
+ {
+ /*
+ * Get the configured character set...
+ */
+
+ int oid[CUPS_SNMP_MAX_OID]; /* OID for character set */
+
+
+ if (!_cupsSNMPWrite(snmp_fd, ¤t_addr, CUPS_SNMP_VERSION_1,
+ _cupsSNMPDefaultCommunity(), CUPS_ASN1_GET_REQUEST, 1,
+ prtGeneralCurrentLocalization))
+ return;
+
+ if (!_cupsSNMPRead(snmp_fd, &packet, CUPS_SUPPLY_TIMEOUT) ||
+ packet.object_type != CUPS_ASN1_INTEGER)
+ {
+ fprintf(stderr,
+ "DEBUG: prtGeneralCurrentLocalization type is %x, expected %x!\n",
+ packet.object_type, CUPS_ASN1_INTEGER);
+ return;
+ }
+
+ fprintf(stderr, "DEBUG2: prtGeneralCurrentLocalization=%d\n",
+ packet.object_value.integer);
+
+ _cupsSNMPCopyOID(oid, prtLocalizationCharacterSet, CUPS_SNMP_MAX_OID);
+ oid[prtLocalizationCharacterSetOffset - 2] = packet.object_value.integer;
+
+
+ if (!_cupsSNMPWrite(snmp_fd, ¤t_addr, CUPS_SNMP_VERSION_1,
+ _cupsSNMPDefaultCommunity(), CUPS_ASN1_GET_REQUEST, 1,
+ oid))
+ return;
+
+ if (!_cupsSNMPRead(snmp_fd, &packet, CUPS_SUPPLY_TIMEOUT) ||
+ packet.object_type != CUPS_ASN1_INTEGER)
+ {
+ fprintf(stderr,
+ "DEBUG: prtLocalizationCharacterSet type is %x, expected %x!\n",
+ packet.object_type, CUPS_ASN1_INTEGER);
+ return;
+ }
+
+ fprintf(stderr, "DEBUG2: prtLocalizationCharacterSet=%d\n",
+ packet.object_value.integer);
+ charset = packet.object_value.integer;
+ }
+
if (num_supplies < 0)
{
/*
*/
_cupsSNMPWalk(snmp_fd, ¤t_addr, CUPS_SNMP_VERSION_1,
- _cupsSNMPDefaultCommunity(), prtMarkerSuppliesEntry, 0.5,
- backend_walk_cb, NULL);
+ _cupsSNMPDefaultCommunity(), prtMarkerSuppliesEntry,
+ CUPS_SUPPLY_TIMEOUT, backend_walk_cb, NULL);
}
/*
if ((cachefile = cupsFileOpen(cachefilename, "w")) != NULL)
{
- cupsFilePrintf(cachefile, "1 %d\n", num_supplies);
+ cupsFilePrintf(cachefile, "2 %d %d\n", num_supplies, charset);
cupsFilePrintf(cachefile, "%s\n", description);
if (num_supplies > 0)
strcpy(supplies[i].color, "none");
_cupsSNMPWalk(snmp_fd, ¤t_addr, CUPS_SNMP_VERSION_1,
- _cupsSNMPDefaultCommunity(), prtMarkerColorantValue, 0.5,
- backend_walk_cb, NULL);
+ _cupsSNMPDefaultCommunity(), prtMarkerColorantValue,
+ CUPS_SUPPLY_TIMEOUT, backend_walk_cb, NULL);
/*
* Output the marker-colors attribute...
/*
- * 'backend_walk_cb()' - Interpret the supply value responses...
+ * 'backend_walk_cb()' - Interpret the supply value responses.
*/
static void
packet->object_type != CUPS_ASN1_OCTET_STRING)
return;
- fprintf(stderr, "DEBUG2: prtMarkerSuppliesDescription.1.%d = \"%s\"\n", i,
- (char *)packet->object_value.string.bytes);
-
if (i > num_supplies)
num_supplies = i;
- strlcpy(supplies[i - 1].name, (char *)packet->object_value.string.bytes,
- sizeof(supplies[0].name));
+ switch (charset)
+ {
+ case CUPS_TC_csASCII :
+ case CUPS_TC_csUTF8 :
+ case CUPS_TC_csUnicodeASCII :
+ strlcpy(supplies[i - 1].name,
+ (char *)packet->object_value.string.bytes,
+ sizeof(supplies[0].name));
+ break;
+
+ case CUPS_TC_csISOLatin1 :
+ case CUPS_TC_csUnicodeLatin1 :
+ cupsCharsetToUTF8((cups_utf8_t *)supplies[i - 1].name,
+ (char *)packet->object_value.string.bytes,
+ sizeof(supplies[0].name), CUPS_ISO8859_1);
+ break;
+
+ case CUPS_TC_csShiftJIS :
+ cupsCharsetToUTF8((cups_utf8_t *)supplies[i - 1].name,
+ (char *)packet->object_value.string.bytes,
+ sizeof(supplies[0].name), CUPS_JIS_X0213);
+ break;
+
+ case CUPS_TC_csUCS4 :
+ case CUPS_TC_csUTF32 :
+ case CUPS_TC_csUTF32BE :
+ case CUPS_TC_csUTF32LE :
+ cupsUTF32ToUTF8((cups_utf8_t *)supplies[i - 1].name,
+ (cups_utf32_t *)packet->object_value.string.bytes,
+ sizeof(supplies[0].name));
+ break;
+
+ case CUPS_TC_csUnicode :
+ case CUPS_TC_csUTF16BE :
+ case CUPS_TC_csUTF16LE :
+ utf16_to_utf8((cups_utf8_t *)supplies[i - 1].name,
+ packet->object_value.string.bytes,
+ packet->object_value.string.num_bytes,
+ sizeof(supplies[0].name), charset == CUPS_TC_csUTF16LE);
+ break;
+
+ default :
+ /*
+ * If we get here, the printer is using an unknown character set and
+ * we just want to copy characters that look like ASCII...
+ */
+
+ {
+ char *src, *dst; /* Pointers into strings */
+
+
+ /*
+ * Loop safe because both the object_value and supplies char arrays
+ * are CUPS_SNMP_MAX_STRING elements long.
+ */
+
+ for (src = (char *)packet->object_value.string.bytes,
+ dst = supplies[i - 1].name;
+ *src;
+ src ++)
+ {
+ if ((*src & 0x80) || *src < ' ' || *src == 0x7f)
+ *dst++ = '?';
+ else
+ *dst++ = *src;
+ }
+
+ *dst = '\0';
+ }
+ break;
+ }
+
+ fprintf(stderr, "DEBUG2: prtMarkerSuppliesDescription.1.%d = \"%s\"\n", i,
+ supplies[i - 1].name);
+
}
else if (_cupsSNMPIsOIDPrefixed(packet, prtMarkerSuppliesLevel))
{
}
+/*
+ * 'utf16_to_utf8()' - Convert UTF-16 text to UTF-8.
+ */
+
+static void
+utf16_to_utf8(
+ cups_utf8_t *dst, /* I - Destination buffer */
+ const unsigned char *src, /* I - Source string */
+ size_t srcsize, /* I - Size of source string */
+ size_t dstsize, /* I - Size of destination buffer */
+ int le) /* I - Source is little-endian? */
+{
+ cups_utf32_t ch, /* Current character */
+ temp[CUPS_SNMP_MAX_STRING],
+ /* UTF-32 string */
+ *ptr; /* Pointer into UTF-32 string */
+
+
+ for (ptr = temp; srcsize >= 2;)
+ {
+ if (le)
+ ch = src[0] | (src[1] << 8);
+ else
+ ch = (src[0] << 8) | src[1];
+
+ src += 2;
+ srcsize -= 2;
+
+ if (ch >= 0xd800 && ch <= 0xdbff && srcsize >= 2)
+ {
+ /*
+ * Multi-word UTF-16 char...
+ */
+
+ int lch; /* Lower word */
+
+
+ if (le)
+ lch = src[0] | (src[1] << 8);
+ else
+ lch = (src[0] << 8) | src[1];
+
+ if (lch >= 0xdc00 && lch <= 0xdfff)
+ {
+ src += 2;
+ srcsize -= 2;
+
+ ch = (((ch & 0x3ff) << 10) | (lch & 0x3ff)) + 0x10000;
+ }
+ }
+
+ if (ptr < (temp + CUPS_SNMP_MAX_STRING - 1))
+ *ptr++ = ch;
+ }
+
+ *ptr = '\0';
+
+ cupsUTF32ToUTF8(dst, temp, dstsize);
+}
+
+
/*
* End of "$Id$".
*/
# VERSIONS OF CUPS. Instead, create a "local.types" file that
# reflects your local configuration changes.
#
-# Copyright 2007-2008 by Apple Inc.
+# Copyright 2007-2009 by Apple Inc.
# Copyright 1997-2007 by Easy Software Products.
#
# These coded instructions, statements, and computer programs are the
#
# MIME type names are case-insensitive. Internally they are converted
# to lowercase. Multiple occurrences of a type will cause the provided
-# rules to be appended to the existing definition. Type names are sorted
-# in ascending order, so if two types use the same rules to resolve a type
-# (e.g. doc extension for two types), the returned type will be the first
-# type in the sorted list.
+# rules to be appended to the existing definition. If two types use the same
+# rules to resolve a type and have the same priority, e.g. "doc" extension for
+# "text/bar" and "text/foo", the returned type will be the first type as
+# sorted in alphanumerically ascending order without regard to case. Thus,
+# the "text/bar" type will match the "doc" extension first unless the
+# "text/foo" type has specified a higher priority.
#
# The "printable" rule differs from the "ascii" rule in that it also
# accepts 8-bit characters in the range 128-255.
AC_MSG_CHECKING(if GCC supports -fstack-protector)
OLDCFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -fstack-protector"
- AC_TRY_COMPILE(,,
+ AC_TRY_LINK(,,
OPTIM="$OPTIM -fstack-protector"
AC_MSG_RESULT(yes),
AC_MSG_RESULT(no))
if test x$default_gssservicename != xno; then
if test "x$default_gssservicename" = "xdefault"; then
- CUPS_DEFAULT_GSSSERVICENAME="ipp"
+ CUPS_DEFAULT_GSSSERVICENAME="host"
else
CUPS_DEFAULT_GSSSERVICENAME="$default_gssservicename"
fi
gss_display_status(&err_minor_status, minor_status, GSS_C_MECH_CODE,
GSS_C_NULL_OID, &msg_ctx, &minor_status_string);
- DEBUG_printf(("8%s: %s, %s", message, (char *)major_status_string.value,
+ DEBUG_printf(("1%s: %s, %s", message, (char *)major_status_string.value,
(char *)minor_status_string.value));
gss_release_buffer(&err_minor_status, &major_status_string);
* information...
*/
- if (http->hostaddr->addr.sa_family == AF_LOCAL &&
+# ifdef HAVE_GSSAPI
+ if (strncmp(http->fields[HTTP_FIELD_WWW_AUTHENTICATE], "Negotiate", 9) &&
+# else
+ if (
+# endif /* HAVE_GSSAPI */
+ http->hostaddr->addr.sa_family == AF_LOCAL &&
!getenv("GATEWAY_INTERFACE")) /* Not via CGI programs... */
{
/*
<body>
<div class='body'>
<!--
- "$Id: api-array.header 8627 2009-05-13 21:39:17Z mike $"
+ "$Id$"
Array API header for the Common UNIX Printing System (CUPS).
<li><a href="#cups_array_t" title="CUPS array type">cups_array_t</a></li>
</ul></li>
<!--
- "$Id: api-array.shtml 7616 2008-05-28 00:34:13Z mike $"
+ "$Id$"
Array API introduction for the Common UNIX Printing System (CUPS).
<body>
<div class='body'>
<!--
- "$Id: api-array.header 8087 2008-10-27 21:37:05Z mike $"
+ "$Id$"
CGI API header for CUPS.
<li><a href="#help_word_s" title="Help word structure...">help_word_s</a></li>
</ul></li>
<!--
- "$Id: api-array.shtml 7616 2008-05-28 00:34:13Z mike $"
+ "$Id$"
CGI API introduction for CUPS.
<body>
<div class='body'>
<!--
- "$Id: api-cups.header 8627 2009-05-13 21:39:17Z mike $"
+ "$Id$"
CUPS API header for the Common UNIX Printing System (CUPS).
<li><a href="#cups_ptype_e" title="Printer type/capability bit constants">cups_ptype_e</a></li>
</ul></li>
<!--
- "$Id: api-cups.shtml 7337 2008-02-22 04:44:04Z mike $"
+ "$Id$"
CUPS API introduction for the Common UNIX Printing System (CUPS).
<body>
<div class='body'>
<!--
- "$Id: api-array.header 8087 2008-10-27 21:37:05Z mike $"
+ "$Id$"
Driver API header for CUPS.
<li><a href="#cups_srgb_lut[256]" title="sRGB gamma lookup table">cups_srgb_lut[256]</a></li>
</ul></li>
<!--
- "$Id: api-array.shtml 7616 2008-05-28 00:34:13Z mike $"
+ "$Id$"
Driver API introduction for CUPS.
<body>
<div class='body'>
<!--
- "$Id: api-filedir.header 8627 2009-05-13 21:39:17Z mike $"
+ "$Id$"
File and Directory API header for the Common UNIX Printing System (CUPS).
<li><a href="#cups_dentry_s" title="Directory entry type">cups_dentry_s</a></li>
</ul></li>
<!--
- "$Id: api-filedir.shtml 7279 2008-01-31 01:50:44Z mike $"
+ "$Id$"
File and directory API introduction for the Common UNIX Printing System (CUPS).
<body>
<div class='body'>
<!--
- "$Id: api-filter.header 8627 2009-05-13 21:39:17Z mike $"
+ "$Id$"
Filter and backend programming header for the Common UNIX Printing System
(CUPS).
<li><a href="#cups_sc_status_e" title="Response status codes">cups_sc_status_e</a></li>
</ul></li>
<!--
- "$Id: api-filter.shtml 7962 2008-09-18 17:31:33Z mike $"
+ "$Id$"
Filter and backend programming introduction for the Common UNIX Printing
System (CUPS).
<body>
<div class='body'>
<!--
- "$Id: api-httpipp.header 8627 2009-05-13 21:39:17Z mike $"
+ "$Id$"
HTTP and IPP API header for the Common UNIX Printing System (CUPS).
<li><a href="#ipp_tag_e" title="Format tags for attributes...">ipp_tag_e</a></li>
</ul></li>
<!--
- "$Id: api-httpipp.shtml 7684 2008-06-23 16:47:38Z mike $"
+ "$Id$"
HTTP and IPP API introduction for the Common UNIX Printing System (CUPS).
<body>
<div class='body'>
<!--
- "$Id: api-array.header 8087 2008-10-27 21:37:05Z mike $"
+ "$Id$"
MIME API header for CUPS.
<li><a href="#mime_type_t" title="MIME Type Data">mime_type_t</a></li>
</ul></li>
<!--
- "$Id: api-array.shtml 7616 2008-05-28 00:34:13Z mike $"
+ "$Id$"
MIME API introduction for CUPS.
<body>
<div class='body'>
<!--
- "$Id: api-cups.header 7279 2008-01-31 01:50:44Z mike $"
+ "$Id$"
Introduction to CUPS programming header for the Common UNIX Printing System
(CUPS).
</ul></li>
<li><a href="#WHERETOGO">Where to Go Next</a></li>
<!--
- "$Id: api-cups.header 7279 2008-01-31 01:50:44Z mike $"
+ "$Id$"
Introduction to CUPS programming content for the Common UNIX Printing System
(CUPS).
<body>
<div class='body'>
<!--
- "$Id: api-ppd.header 8627 2009-05-13 21:39:17Z mike $"
+ "$Id$"
PPD API header for the Common UNIX Printing System (CUPS).
<li><a href="#ppd_ui_e" title="UI Types">ppd_ui_e</a></li>
</ul></li>
<!--
- "$Id: api-ppd.shtml 7616 2008-05-28 00:34:13Z mike $"
+ "$Id$"
PPD API introduction for the Common UNIX Printing System (CUPS).
<body>
<div class='body'>
<!--
- "$Id: api-array.header 8087 2008-10-27 21:37:05Z mike $"
+ "$Id$"
PPD Compiler API header for CUPS.
<li><a href="#ppdcOptType" title="// Option type">ppdcOptType</a></li>
</ul></li>
<!--
- "$Id: api-array.shtml 7616 2008-05-28 00:34:13Z mike $"
+ "$Id$"
PPD Compiler API introduction for CUPS.
<H1 CLASS="title">Managing Operation Policies</H1>
-<P>Operation policies are the rules used for each IPP operation
-in CUPS. These rules include things like "user must provide a
-password", "user must be in the system group", "allow only from
-the local system", and so forth. Until CUPS 1.2, these rules were
-largely hardcoded and could only be customized at a very basic
-level.</P>
-
-<P>CUPS 1.2 adds a new fine-grained policy layer which allows you
-to completely redefine the rules for each operation and/or
-printer. Each policy is named and defines access control rules
-for each IPP operation. This document describes how to manage
-policies and their rules.</P>
+<P>Operation policies are the rules used for each IPP operation in CUPS. These rules include things like "user must provide a password", "user must be in the system group", "allow only from the local system", and so forth. Until CUPS 1.2, these rules were largely hardcoded and could only be customized at a very basic level.</P>
+
+<P>CUPS 1.2 and later provides a fine-grained policy layer which allows you to completely redefine the rules for each operation and/or printer. Each policy is named and defines access control rules for each IPP operation. This document describes how to manage policies and their rules.</P>
<H2 CLASS="title"><A NAME="BASICS">The Basics</A></H2>
-<P>Operation policies are used for all IPP requests sent to the
-scheduler and are evaluated <em>after</em> the <A
-HREF="ref-cupsd-conf.html#Location"><TT>Location</TT></A> based
-access control rules. This means that operation policies can only
-add additional security restrictions to a request, never relax
-them. Use <TT>Location</TT> based access control rules for
-server-wide limits and operation policies for limits on
-individual printers, tasks, or services.</P>
-
-<P>Policies are stored in the <VAR>cupsd.conf</VAR> file in <A
-HREF="ref-cupsd-conf.html#Policy"><TT>Policy</TT></A> sections.
-Each policy has an alphanumeric name that is used to select it.
-Inside the policy section are one or more <A
-HREF="ref-cupsd-conf.html#LimitIPP"><TT>Limit</TT></A>
-subsections which list the operations that are affected by the
-rules inside it. <A HREF="#LISTING01">Listing 1</A> shows the
-default operation policy, appropriately called "default", that is
-shipped with CUPS.</P>
-
-<P>The easiest way to add a policy to the <VAR>cupsd.conf</VAR>
-file is to use the web interface. Click on the
-<VAR>Administration</VAR> tab and then the <VAR>Edit
-Configuration File</VAR> button to edit the current
-<VAR>cupsd.conf</VAR> file. Click on the <VAR>Save Changes</VAR>
-button to save the changes and restart the scheduler. If you edit
-the <VAR>cupsd.conf</VAR> file from the console, make sure to <A
-HREF="ref-cupsd-conf.html">restart the cupsd process</A> before
-trying to use the new policy.</P>
+<P>Operation policies are used for all IPP requests sent to the scheduler and are evaluated <em>after</em> the <A HREF="ref-cupsd-conf.html#Location"><TT>Location</TT></A> based access control rules. This means that operation policies can only add additional security restrictions to a request, never relax them. Use <TT>Location</TT> based access control rules for server-wide limits and operation policies for limits on individual printers, tasks, or services.</P>
+
+<P>Policies are stored in the <VAR>cupsd.conf</VAR> file in <A HREF="ref-cupsd-conf.html#Policy"><TT>Policy</TT></A> sections. Each policy has an alphanumeric name that is used to select it. Inside the policy section are one or more <A
+HREF="ref-cupsd-conf.html#LimitIPP"><TT>Limit</TT></A> subsections which list the operations that are affected by the rules inside it. <A HREF="#LISTING01">Listing 1</A> shows the default operation policy, appropriately called "default", that is shipped with CUPS.</P>
+
+<P>The easiest way to add a policy to the <VAR>cupsd.conf</VAR> file is to use the web interface. Click on the <VAR>Administration</VAR> tab and then the <VAR>Edit Configuration File</VAR> button to edit the current <VAR>cupsd.conf</VAR> file. Click on the <VAR>Save Changes</VAR> button to save the changes and restart the scheduler. If you edit the <VAR>cupsd.conf</VAR> file from the console, make sure to <A HREF="ref-cupsd-conf.html">restart the cupsd process</A> before trying to use the new policy.</P>
<PRE CLASS="example">
<EM>Listing 1: <A NAME="LISTING01">Default Operation Policy</A></EM>
Create-Job-Subscription Renew-Subscription
Cancel-Subscription Get-Notifications Reprocess-Job
Cancel-Current-Job Suspend-Current-Job Resume-Job
- CUPS-Move-Job>
+ CUPS-Move-Job CUPS-Get-Document>
4 Require user @OWNER @SYSTEM
5 Order deny,allow
6 </Limit>
<H3>The Default CUPS Operation Policy</H3>
-<P>The policy definition starts with an opening <TT>Policy</TT>
-directive:</P>
+<P>The policy definition starts with an opening <TT>Policy</TT> directive:</P>
<PRE CLASS="example">
1 <Policy default>
</PRE>
-<P>The first <TT>Limit</TT> subsection defines the rules for IPP
-job operations:</P>
+<P>The first <TT>Limit</TT> subsection defines the rules for IPP job operations:</P>
<PRE CLASS="example">
3 <Limit Send-Document Send-URI Hold-Job Release-Job
Create-Job-Subscription Renew-Subscription
Cancel-Subscription Get-Notifications Reprocess-Job
Cancel-Current-Job Suspend-Current-Job Resume-Job
- CUPS-Move-Job>
+ CUPS-Move-Job CUPS-Get-Document>
4 Require user @OWNER @SYSTEM
5 Order deny,allow
6 </Limit>
</PRE>
-<P>The operation names are listed on a single line
-with spaces separating them. Each name corresponds to the IPP
-operation described in any of the IETF or PWG standards documents
-for the Internet Printing Protocol. <A HREF="#TABLE01">Table
-1</A> lists all of the operations that have been defined along
-with their usage in CUPS.</P>
-
-<P>The access control rules are listed after the <TT>Limit</TT>
-line and are the same as those used for <A
-HREF="ref-cupsd-conf.html#Location"><TT>Location</TT></A>
-sections. In this case, we require the owner of the job
-("@OWNER") or a member of the <A
-HREF="ref-cupsd-conf.html#SystemGroup"><TT>SystemGroup</TT></A>
-("@SYSTEM") to do the operation. Because we do not include an <A
-HREF="ref-cupsd-conf.html#AuthType"><TT>AuthType</TT></A>
-directive here, the user information can come from the IPP
-request itself or the authenticated username from the HTTP
-request. The administrative operations starting on line 9,
-however, <em>do</em> use the <TT>AuthType</TT> directive, and so
-administrative operations need to be authenticated:</P>
+<P>The operation names are listed on a single line with spaces separating them. Each name corresponds to the IPP operation described in any of the IETF or PWG standards documents for the Internet Printing Protocol. <A HREF="#TABLE01">Table 1</A> lists all of the operations that have been defined along with their usage in CUPS.</P>
+
+<P>The access control rules are listed after the <TT>Limit</TT> line and are the same as those used for <A HREF="ref-cupsd-conf.html#Location"><TT>Location</TT></A> sections. In this case, we require the owner of the job ("@OWNER") or a member of the <A HREF="ref-cupsd-conf.html#SystemGroup"><TT>SystemGroup</TT></A> ("@SYSTEM") to do the operation. Because we do not include an <A HREF="ref-cupsd-conf.html#AuthType"><TT>AuthType</TT></A> directive here, the user information can come from the IPP request itself or the authenticated username from the HTTP request. The administrative operations starting on line 9, however, <em>do</em> use the <TT>AuthType</TT> directive, and so administrative operations need to be authenticated:</P>
<PRE CLASS="example">
9 <Limit CUPS-Add-Printer CUPS-Delete-Printer CUPS-Add-Class
20 </Limit>
</PRE>
-<P>The "Order deny,allow" line at the end of both <TT>Limit</TT>
-subsections allows the request to come from any system allowed by
-the <TT>Location</TT> sections elsewhere in the
-<VAR>cupsd.conf</VAR> file.</P>
+<P>The "Order deny,allow" line at the end of both <TT>Limit</TT> subsections allows the request to come from any system allowed by the <TT>Location</TT> sections elsewhere in the <VAR>cupsd.conf</VAR> file.</P>
-<P>The <TT>Cancel-Job</TT> and <TT>CUPS-Authenticate-Job</TT>
-operations are listed separately to allow the web interface to
-more easily edit their policy without disturbing the rest. Like
-the rest of the job operations, we want the job's owner
-("@OWNER") or an administrator ("@SYSTEM") to do it:</P>
+<P>The <TT>Cancel-Job</TT> and <TT>CUPS-Authenticate-Job</TT> operations are listed separately to allow the web interface to more easily edit their policy without disturbing the rest. Like the rest of the job operations, we want the job's owner ("@OWNER") or an administrator ("@SYSTEM") to do it:</P>
<PRE CLASS="example">
16 <Limit Cancel-Job CUPS-Authenticate-Job>
19 </Limit>
</PRE>
-<P>The last <TT>Limit</TT> subsection in any policy uses the
-special operation name <TT>All</TT>. CUPS will use the rules in
-this subsection for any operation you don't list specifically in
-the policy. In this case, all other operations are allowed
-without a username or authentication:</P>
+<P>The last <TT>Limit</TT> subsection in any policy uses the special operation name <TT>All</TT>. CUPS will use the rules in this subsection for any operation you don't list specifically in the policy. In this case, all other operations are allowed without a username or authentication:</P>
<PRE CLASS="example">
21 <Limit All>
<TD>Yes</TD>
<TD>Authenticates a job for printing.</TD>
</TR>
+<TR>
+ <TD NOWRAP><TT>CUPS-Get-Document</TT></TD>
+ <TD>Yes</TD>
+ <TD>Retrieves a document file from a job.</TD>
+</TR>
</TBODY>
</TABLE></DIV>
<H2 CLASS="title"><A NAME="CREATING">Creating Your Own Policies</A></H2>
-<P>The easiest way to create a new policy is to start with the
-default policy and then make changes to the copy. The first
-change you'll make is to give the policy a new name. Policy names
-can use the same characters as a printer name, specifically all
-printable characters except space, slash (/), and pound (#):</P>
+<P>The easiest way to create a new policy is to start with the default policy and then make changes to the copy. The first change you'll make is to give the policy a new name. Policy names can use the same characters as a printer name, specifically all printable characters except space, slash (/), and pound (#):</P>
<PRE CLASS="example">
<Policy mypolicy>
</PRE>
-<P>Then you need to decide exactly what limits you want for the
-policy. For example, if you want to allow any user to cancel any
-other users' jobs, you can change the <TT>Cancel-Job</TT> limits
-to:</P>
+<P>Then you need to decide exactly what limits you want for the policy. For example, if you want to allow any user to cancel any other users' jobs, you can change the <TT>Cancel-Job</TT> limits to:</P>
<PRE CLASS="example">
<Limit Cancel-Job>
</Limit>
</PRE>
-<P>The directives inside the <TT>Limit</TT> subsection can use
-any of the normal limiting directives: <A
-HREF="ref-cupsd-conf.html#Allow"><TT>Allow</TT></A>, <A
-HREF="ref-cupsd-conf.html#AuthType"><TT>AuthType</TT></A>, <A
-HREF="ref-cupsd-conf.html#Deny"><TT>Deny</TT></A>, <A
-HREF="ref-cupsd-conf.html#Encryption"><TT>Encryption</TT></A>, <A
-HREF="ref-cupsd-conf.html#Require"><TT>Require</TT></A>, and <A
-HREF="ref-cupsd-conf.html#Satisfy"><TT>Satisfy</TT></A>. <A
-HREF="#TABLE02">Table 2</A> lists some basic "recipes" for
-different access control rules.</P>
+<P>The directives inside the <TT>Limit</TT> subsection can use any of the normal limiting directives: <A HREF="ref-cupsd-conf.html#Allow"><TT>Allow</TT></A>, <A HREF="ref-cupsd-conf.html#AuthType"><TT>AuthType</TT></A>, <A HREF="ref-cupsd-conf.html#Deny"><TT>Deny</TT></A>, <A HREF="ref-cupsd-conf.html#Encryption"><TT>Encryption</TT></A>, <A HREF="ref-cupsd-conf.html#Require"><TT>Require</TT></A>, and <A HREF="ref-cupsd-conf.html#Satisfy"><TT>Satisfy</TT></A>. <A HREF="#TABLE02">Table 2</A> lists some basic "recipes" for different access control rules.</P>
<DIV CLASS="table"><TABLE WIDTH="80%" SUMMARY="Access Control Recipes">
<CAPTION>Table 2: <A NAME="TABLE02">Access Control Recipes</A></CAPTION>
</TR>
<TR>
<TD>Deny Everyone/Disable Operation(s)</TD>
- <TD><PRE>Order allow,deny
-Deny from all</PRE></TD>
+ <TD><PRE>Order deny,allow</PRE></TD>
</TR>
<TR>
<TD>Require Login (System) Password</TD>
<TD>Require CUPS (lppasswd) Password</TD>
<TD><PRE>AuthType BasicDigest</PRE></TD>
</TR>
+<TR>
+ <TD>Require Kerberos</TD>
+ <TD><PRE>AuthType Negotiate</PRE></TD>
+</TR>
<TR>
<TD>Require the Owner of a Job or Subscription</TD>
<TD><PRE>Require user @OWNER</PRE></TD>
<H3>Creating a Policy for a Computer Lab</H3>
-<P>One common operating scenario is a computer lab. The lab is
-managed by one or more technicians that assist the users of the
-lab and handle the basic administration tasks. <A
-HREF="#LISTING02">Listing 2</A> shows an operation policy that
-only allows access from the lab's subnet, 10.0.2.x, and allows
-the lab technicians, who are members of a special UNIX group for
-that lab called "lab999", to do job, printer, and subscription
-management operations.</P>
+<P>One common operating scenario is a computer lab. The lab is managed by one or more technicians that assist the users of the lab and handle the basic administration tasks. <A HREF="#LISTING02">Listing 2</A> shows an operation policy that only allows access from the lab's subnet, 10.0.2.x, and allows the lab technicians, who are members of a special UNIX group for that lab called "lab999", to do job, printer, and subscription management operations.</P>
<PRE CLASS="example">
<EM>Listing 2: <A NAME="LISTING02">Operation Policy for a Lab</A></EM>
Create-Job-Subscription Renew-Subscription
Cancel-Subscription Get-Notifications Reprocess-Job
Cancel-Current-Job Suspend-Current-Job Resume-Job
- CUPS-Move-Job Cancel-Job CUPS-Authenticate-Job>
+ CUPS-Move-Job Cancel-Job CUPS-Authenticate-Job CUPS-Get-Document>
4 Require user @OWNER @lab999 @SYSTEM
5 Order allow,deny
6 Allow from 10.0.2.0/24
<H2 CLASS="title"><A NAME="SELECT">Using Policies</A></H2>
-<P>Once you have created a policy, you can use it in two ways.
-The first way is to assign it as the default policy for the
-system using the <A
-HREF="ref-cupsd-conf.html#DefaultPolicy"><TT>DefaultPolicy</TT></A>
-directive in the <VAR>cupsd.conf</VAR> file. For example, add the
-following line to the <VAR>cupsd.conf</VAR> file to use the
-"lab999" policy from the previous section:</P>
+<P>Once you have created a policy, you can use it in two ways. The first way is to assign it as the default policy for the system using the <A HREF="ref-cupsd-conf.html#DefaultPolicy"><TT>DefaultPolicy</TT></A> directive in the <VAR>cupsd.conf</VAR> file. For example, add the following line to the <VAR>cupsd.conf</VAR> file to use the "lab999" policy from the previous section:</P>
<PRE CLASS="example">
DefaultPolicy lab999
</PRE>
-<P>To associate the policy with one or more printers, use either
-the <A HREF="man-lpadmin.html">lpadmin(8)</A> command or the web
-interface to change the operation policy for each printer. When
-using the <B>lpadmin</B> command, the <TT>-o
-printer-op-policy=name</TT> option sets the operation policy for
-a printer. For example, enter the following command to use the
-"lab999" policy from the previous section with a printer named
-"LaserJet4000":</P>
+<P>To associate the policy with one or more printers, use either the <A HREF="man-lpadmin.html">lpadmin(8)</A> command or the web interface to change the operation policy for each printer. When using the <B>lpadmin</B> command, the <TT>-o printer-op-policy=name</TT> option sets the operation policy for a printer. For example, enter the following command to use the "lab999" policy from the previous section with a printer named "LaserJet4000":</P>
<PRE CLASS="command">
lpadmin -p LaserJet4000 -o printer-op-policy=lab999
</PRE>
-<P>To make the same change in the web interface, go to the
-printer's web page, for example
-"http://localhost:631/printers/LaserJet4000", and click on the
-<VAR>Set Printer Options</VAR> button. Scroll down to the bottom
-of the page and choose the desired policy from the pull-down
-list. Click on <VAR>Set Printer Options</VAR> to change the policy for
-the printer.</P>
+<P>To make the same change in the web interface, go to the printer's web page, for example "http://localhost:631/printers/LaserJet4000", and choose <VAR>Set Default Options</VAR> from the <VAR>Administration</VAR> menu button. Click on the <VAR>Policies</VAR> link and choose the desired policy from the pull-down list. Click on <VAR>Set Default Options</VAR> to change the policy for the printer.</P>
</BODY>
</HTML>
CUPS IPP specification for the Common UNIX Printing System (CUPS).
- Copyright 2007-2008 by Apple Inc.
+ Copyright 2007-2009 by Apple Inc.
Copyright 1997-2007 by Easy Software Products.
These coded instructions, statements, and computer programs are the
<h2 class='title'><a name='INTRODUCTION'>Introduction</a></h2>
-<p>CUPS implements IPP/1.1 and the operations and attributes
+<p>CUPS implements IPP/2.1 and the operations and attributes
defined in the "IPP: Job and Printer Set Operations", "IPP/1.1:
Output-bin Attribute Extension", and "IPP/1.1: finishings
'fold',' trim', and 'bale' attribute values extension"
<h3 class='title'><span class='info'>CUPS 1.1</span><a name='CUPS_MOVE_JOB'>CUPS-Move-Job Operation</a></h3>
-<p>The CUPS-Move-Job operation (0x400D) moves an active print job
-to a different printer.</p>
+<p>The CUPS-Move-Job operation (0x400D) moves an active print job or all print
+jobs for a printer to a different printer.</p>
<h4>CUPS-Move-Job Request</h4>
attributes as described in section 3.1.4.1 of the IPP Model and
Semantics document.
+ <dt>"printer-uri" (uri)
+ <br><i>OR</i>
<dt>"printer-uri" (uri) and "job-id" (integer)
<br><i>OR</i>
<br>"job-uri":
- <dd>The client MUST supply a URI for the specified printer and
- a job ID number, or the job URI.
+ <dd>The client MUST supply a URI for the specified printer, the URI for
+ the specified printer and a job ID number, or the job URI.
</dl>
.\" 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/".
.\"
-.TH mime.types 5 "CUPS" "17 June 2008" "Apple Inc."
+.TH mime.types 5 "CUPS" "16 May 2009" "Apple Inc."
.SH NAME
mime.types \- mime type description file for cups
.SH DESCRIPTION
super/type rule [ ... ruleN]
.fi
+MIME type names are case-insensitive and are sorted in ascending alphanumeric
+order for the purposes of matching. See the "TYPE MATCHING AND PRIORITY"
+section for more information.
+.LP
The rules may be grouped using parenthesis, joined using "+" for a
logical AND and "," or whitespace for a logical OR, and negated using
"!".
String constants can be specified inside quotes ("") for strings
containing whitespace and angle brackets (<>) for hexadecimal
strings.
+.SH TYPE MATCHING AND PRIORITY
+When CUPS needs to determine the MIME type of a given file, it checks every
+MIME type defined in the .types files. When two types have the same matching
+rules, the type chosen will depend on the type name and priority, with higher-
+priority types being used over lower-priority ones. If the types have the same
+priority, the type names are sorted alphanumerically in ascending order and the
+first type is chosen.
+.LP
+For example, if two types "text/bar" and "text/foo" are defined as matching the
+extension "doc", normally the type "text/bar" will be chosen since its name is
+alphanumerically smaller than "text/foo". However, if "text/foo" also defines a
+higher priority than "text/bar", "text/foo" will be chosen instead.
.SH SEE ALSO
\fIclasses.conf(5)\fR, \fIcupsd(8)\fR, \fIcupsd.conf(5)\fR,
\fImime.convs(5)\fR, \fIprinters.conf(5)\fR,
UIConstraints "*PageSize Legal *InputSlot Envelope"
UIConstraints "*PageSize Letter *InputSlot Envelope"
UIConstraints "*PageSize Tabloid *InputSlot Envelope"
- UIConstraints "*Resolution 600dpi *ColorModel CMYK"
HWMargins 18 36 18 36
*MediaSize Letter
Resolution - 1 0 0 0 150dpi
*Resolution - 1 0 0 0 300dpi
- Resolution k 1 0 0 0 "600dpi/600 DPI Grayscale"
+ Resolution - 1 0 0 0 600dpi
*InputSlot 1 Tray
InputSlot 2 "Manual/Manual Feed"
if (!con->gss_creds)
cupsdLogMessage(CUPSD_LOG_DEBUG,
- "cupsdAuthorize: No credentials!");
+ "cupsdAuthorize: No delegated credentials!");
if (major_status == GSS_S_CONTINUE_NEEDED)
cupsdLogGSSMessage(CUPSD_LOG_DEBUG, major_status, minor_status,
peersize = sizeof(peercred);
+# ifdef __APPLE__
+ if (getsockopt(con->http.fd, 0, LOCAL_PEERCRED, &peercred, &peersize))
+# else
if (getsockopt(con->http.fd, SOL_SOCKET, SO_PEERCRED, &peercred, &peersize))
+# endif /* __APPLE__ */
{
cupsdLogMessage(CUPSD_LOG_ERROR, "Unable to get peer credentials - %s",
strerror(errno));
return (NULL);
}
+ cupsdLogMessage(CUPSD_LOG_DEBUG,
+ "cupsdCopyKrb5Creds: Copying credentials for UID %d...",
+ CUPSD_UCRED_UID(peercred));
+
krb5_ipc_client_set_target_uid(CUPSD_UCRED_UID(peercred));
if ((error = krb5_cc_default(KerberosContext, &peerccache)) != 0)
void
cupsdLoadAllClasses(void)
{
+ int i; /* Looping var */
cups_file_t *fp; /* classes.conf file */
int linenum; /* Current line number */
char line[4096], /* Line from file */
else if (!strcasecmp(value, "stopped"))
{
p->state = IPP_PRINTER_STOPPED;
- cupsdSetPrinterReasons(p, "+paused");
+
+ for (i = 0 ; i < p->num_reasons; i ++)
+ if (!strcmp("paused", p->reasons[i]))
+ break;
+
+ if (i >= p->num_reasons &&
+ p->num_reasons < (int)(sizeof(p->reasons) / sizeof(p->reasons[0])))
+ {
+ p->reasons[p->num_reasons] = _cupsStrAlloc("paused");
+ p->num_reasons ++;
+ }
}
else
cupsdLogMessage(CUPSD_LOG_ERROR,
con->sent_header = 0;
con->file_ready = 0;
con->got_fields = 0;
- con->field_col = 0;
+ con->header_used = 0;
return (1);
}
if (auth_str[0])
{
- cupsdLogMessage(CUPSD_LOG_DEBUG, "cupsdSendHeader: WWW-Authenticate: %s",
+ cupsdLogMessage(CUPSD_LOG_DEBUG,
+ "cupsdSendHeader: %d WWW-Authenticate: %s", con->http.fd,
auth_str);
if (httpPrintf(HTTP(con), "WWW-Authenticate: %s\r\n", auth_str) < 0)
void
cupsdWriteClient(cupsd_client_t *con) /* I - Client connection */
{
- int bytes; /* Number of bytes written */
- char buf[16385]; /* Data buffer */
- char *bufptr; /* Pointer into buffer */
+ int bytes, /* Number of bytes written */
+ field_col; /* Current column */
+ char *bufptr, /* Pointer into buffer */
+ *bufend; /* Pointer to end of buffer */
ipp_state_t ipp_state; /* IPP state value */
bytes = ipp_state != IPP_ERROR &&
(con->file >= 0 || ipp_state != IPP_DATA);
}
- else if ((bytes = read(con->file, buf, sizeof(buf) - 1)) > 0)
+ else if ((bytes = read(con->file, con->header,
+ sizeof(con->header) - con->header_used)) > 0)
{
+ con->header_used += bytes;
+
if (con->pipe_pid && !con->got_fields)
{
/*
* Inspect the data for Content-Type and other fields.
*/
- buf[bytes] = '\0';
-
- for (bufptr = buf; !con->got_fields && *bufptr; bufptr ++)
+ for (bufptr = con->header, bufend = con->header + con->header_used,
+ field_col = 0;
+ !con->got_fields && bufptr < bufend;
+ bufptr ++)
{
if (*bufptr == '\n')
{
* Send line to client...
*/
- if (bufptr > buf && bufptr[-1] == '\r')
+ if (bufptr > con->header && bufptr[-1] == '\r')
bufptr[-1] = '\0';
*bufptr++ = '\0';
- cupsdLogMessage(CUPSD_LOG_DEBUG, "Script header: %s", buf);
+ cupsdLogMessage(CUPSD_LOG_DEBUG, "Script header: %s", con->header);
if (!con->sent_header)
{
* Handle redirection and CGI status codes...
*/
- if (!strncasecmp(buf, "Location:", 9))
+ if (!strncasecmp(con->header, "Location:", 9))
{
cupsdSendHeader(con, HTTP_SEE_OTHER, NULL, CUPSD_AUTH_NONE);
con->sent_header = 2;
if (httpPrintf(HTTP(con), "Content-Length: 0\r\n") < 0)
return;
}
- else if (!strncasecmp(buf, "Status:", 7))
+ else if (!strncasecmp(con->header, "Status:", 7))
{
- cupsdSendError(con, (http_status_t)atoi(buf + 7), CUPSD_AUTH_NONE);
+ cupsdSendError(con, (http_status_t)atoi(con->header + 7),
+ CUPSD_AUTH_NONE);
con->sent_header = 2;
}
else
}
}
- if (strncasecmp(buf, "Status:", 7))
- httpPrintf(HTTP(con), "%s\r\n", buf);
+ if (strncasecmp(con->header, "Status:", 7))
+ httpPrintf(HTTP(con), "%s\r\n", con->header);
/*
* Update buffer...
*/
- bytes -= (bufptr - buf);
+ con->header_used -= bufptr - con->header;
- if (bytes > 0)
- memmove(buf, bufptr, bytes + 1);
- else
- buf[0] = '\0';
+ if (con->header_used > 0)
+ memmove(con->header, bufptr, con->header_used);
- bufptr = buf - 1;
+ bufptr = con->header - 1;
/*
* See if the line was empty...
*/
- if (con->field_col == 0)
+ if (field_col == 0)
{
con->got_fields = 1;
con->http.data_encoding = HTTP_ENCODE_CHUNKED;
}
else
- con->field_col = 0;
+ field_col = 0;
}
else if (*bufptr != '\r')
- con->field_col ++;
+ field_col ++;
}
- if (bytes > 0 && !con->got_fields)
- {
- /*
- * Remaining text needs to go out...
- */
-
- httpPrintf(HTTP(con), "%s", buf);
-
- con->http.activity = time(NULL);
- return;
- }
- else if (bytes == 0)
+ if (!con->got_fields)
{
con->http.activity = time(NULL);
return;
}
}
- if (bytes > 0)
+ if (con->header_used > 0)
{
- if (httpWrite2(HTTP(con), buf, bytes) < 0)
+ if (httpWrite2(HTTP(con), con->header, con->header_used) < 0)
{
cupsdLogMessage(CUPSD_LOG_DEBUG,
"cupsdWriteClient: %d Closing for error %d (%s)",
if (con->http.data_encoding == HTTP_ENCODE_CHUNKED)
httpFlushWrite(HTTP(con));
- con->bytes += bytes;
+ con->bytes += con->header_used;
if (con->http.state == HTTP_WAITING)
bytes = 0;
+ else
+ bytes = con->header_used;
+
+ con->header_used = 0;
}
}
int pipe_pid; /* Pipe process ID (or 0 if not a pipe) */
int sent_header, /* Non-zero if sent HTTP header */
got_fields, /* Non-zero if all fields seen */
- field_col; /* Column within line */
+ header_used; /* Number of header bytes used */
+ char header[2048]; /* Header from CGI program */
cups_lang_t *language; /* Language to use */
#ifdef HAVE_SSL
int auto_ssl; /* Automatic test for SSL/TLS */
cupsdLoadAllPrinters();
cupsdLoadAllClasses();
cupsdLoadRemoteCache();
- cupsdMarkDirty(CUPSD_DIRTY_PRINTCAP);
cupsdCreateCommonData();
+ /*
+ * Update the printcap file as needed...
+ */
+
+ if (Printcap && *Printcap && access(Printcap, 0))
+ cupsdWritePrintcap();
+
/*
* Load queued jobs...
*/
int port; /* Port portion of URI */
ipp_attribute_t *attr; /* Attribute in request */
const char *username; /* Username */
- int purge; /* Purge? */
+ cupsd_jobaction_t purge; /* Purge? */
cupsd_printer_t *printer; /* Printer */
if ((attr = ippFindAttribute(con->request, "purge-jobs",
IPP_TAG_BOOLEAN)) != NULL)
- purge = attr->values[0].boolean;
+ purge = attr->values[0].boolean ? CUPSD_JOB_PURGE : CUPSD_JOB_DEFAULT;
else
- purge = 1;
+ purge = CUPSD_JOB_PURGE;
/*
* And if the destination is valid...
cupsdCancelJobs(NULL, username, purge);
cupsdLogMessage(CUPSD_LOG_INFO, "All jobs were %s by \"%s\".",
- purge ? "purged" : "canceled", get_username(con));
+ purge == CUPSD_JOB_PURGE ? "purged" : "canceled",
+ get_username(con));
}
else
{
cupsdCancelJobs(printer->name, username, purge);
cupsdLogMessage(CUPSD_LOG_INFO, "All jobs on \"%s\" were %s by \"%s\".",
- printer->name, purge ? "purged" : "canceled",
+ printer->name,
+ purge == CUPSD_JOB_PURGE ? "purged" : "canceled",
get_username(con));
}
cupsd_job_t *job; /* Job information */
cups_ptype_t dtype; /* Destination type (printer/class) */
cupsd_printer_t *printer; /* Printer data */
- int purge; /* Purge the job? */
+ cupsd_jobaction_t purge; /* Purge the job? */
cupsdLogMessage(CUPSD_LOG_DEBUG2, "cancel_job(%p[%d], %s)", con,
if ((attr = ippFindAttribute(con->request, "purge-job",
IPP_TAG_BOOLEAN)) != NULL)
- purge = attr->values[0].boolean;
+ purge = attr->values[0].boolean ? CUPSD_JOB_PURGE : CUPSD_JOB_DEFAULT;
else
- purge = 0;
+ purge = CUPSD_JOB_DEFAULT;
/*
* See if the job exists...
* we can't cancel...
*/
- if (job->state_value >= IPP_JOB_CANCELED && !purge)
+ if (job->state_value >= IPP_JOB_CANCELED && purge != CUPSD_JOB_PURGE)
{
switch (job->state_value)
{
*/
cupsdSetJobState(job, IPP_JOB_CANCELED, purge,
- purge ? "Job purged by \"%s\"" : "Job canceled by \"%s\"",
+ purge == CUPSD_JOB_PURGE ? "Job purged by \"%s\"" :
+ "Job canceled by \"%s\"",
username);
cupsdCheckJobs();
- if (purge)
+ if (purge == CUPSD_JOB_PURGE)
cupsdLogMessage(CUPSD_LOG_INFO, "[Job %d] Purged by \"%s\".", jobid,
username);
else
cupsFileClose(fp);
#if defined(HAVE_GSSAPI) && defined(HAVE_KRB5_H)
+# ifdef HAVE_KRB5_IPC_CLIENT_SET_TARGET_UID
+ if (con->http.hostaddr->addr.sa_family == AF_LOCAL || con->gss_creds)
+# else
if (con->gss_creds)
+# endif /* HAVE_KRB5_IPC_CLIENT_SET_TARGET_UID */
save_krb5_creds(con, job);
else if (job->ccname)
cupsdClearString(&(job->ccname));
cups_file_t *fp; /* Fake lpsched lock file */
struct stat statbuf; /* Needed for checking lpsched FIFO */
#endif /* __sgi */
+ int run_as_child = 0;
+ /* Needed for background fork/exec */
#ifdef __APPLE__
- int run_as_child = 0,
- /* Needed for Mac OS X fork/exec */
- use_sysman = !getuid();
+ int use_sysman = !getuid();
/* Use system management functions? */
#else
time_t netif_time = 0; /* Time since last network update */
for (opt = argv[i] + 1; *opt != '\0'; opt ++)
switch (*opt)
{
-#ifdef __APPLE__
- case 'S' : /* Disable system management functions */
- puts("Warning: -S (disable system management) for internal testing use only!");
- use_sysman = 0;
- break;
-
case 'C' : /* Run as child with config file */
run_as_child = 1;
fg = -1;
-#endif /* __APPLE__ */
case 'c' : /* Configuration file */
i ++;
UseProfiles = 0;
break;
+#ifdef __APPLE__
+ case 'S' : /* Disable system management functions */
+ puts("Warning: -S (disable system management) for internal testing use only!");
+ use_sysman = 0;
+ break;
+#endif /* __APPLE__ */
+
case 't' : /* Test the cupsd.conf file... */
TestConfigFile = 1;
fg = 1;
}
}
-#ifdef __APPLE__
+#ifdef __OpenBSD__
+ /*
+ * Call _thread_sys_closefrom() so the child process doesn't reset the
+ * parent's file descriptors to be blocking. This is a workaround for a
+ * limitation of userland libpthread on OpenBSD.
+ */
+
+ _thread_sys_closefrom(0);
+#endif /* __OpenBSD__ */
+
/*
- * Since CoreFoundation has an overly-agressive check for whether a
- * process has forked but not exec'd (whether CF has been called or
- * not...), we now have to exec ourselves with the "-f" option to
- * eliminate their bogus warning messages.
+ * Since CoreFoundation and DBUS both create fork-unsafe data on execution of
+ * a program, and since this kind of really unfriendly behavior seems to be
+ * more common these days in system libraries, we need to re-execute the
+ * background cupsd with the "-C" option to avoid problems. Unfortunately,
+ * we also have to assume that argv[0] contains the name of the cupsd
+ * executable - there is no portable way to get the real pathname...
*/
execlp(argv[0], argv[0], "-C", ConfigurationFile, (char *)0);
exit(errno);
-#endif /* __APPLE__ */
}
if (fg < 1)
* Redirect stdin/out/err to /dev/null...
*/
- open("/dev/null", O_RDONLY);
- open("/dev/null", O_WRONLY);
- open("/dev/null", O_WRONLY);
+ if ((i = open("/dev/null", O_RDONLY)) != 0)
+ {
+ dup2(i, 0);
+ close(i);
+ }
+
+ if ((i = open("/dev/null", O_WRONLY)) != 1)
+ {
+ dup2(i, 1);
+ close(i);
+ }
+
+ if ((i = open("/dev/null", O_WRONLY)) != 2)
+ {
+ dup2(i, 2);
+ close(i);
+ }
#endif /* DEBUG */
}
* we are up and running...
*/
-#ifdef __APPLE__
if (!fg || run_as_child)
-#else
- if (!fg)
-#endif /* __APPLE__ */
{
/*
* Send a signal to the parent process, but only if the parent is
else if (value && !strcasecmp(value, "stopped"))
{
p->state = IPP_PRINTER_STOPPED;
- cupsdSetPrinterReasons(p, "+paused");
+
+ for (i = 0 ; i < p->num_reasons; i ++)
+ if (!strcmp("paused", p->reasons[i]))
+ break;
+
+ if (i >= p->num_reasons &&
+ p->num_reasons < (int)(sizeof(p->reasons) / sizeof(p->reasons[0])))
+ {
+ p->reasons[p->num_reasons] = _cupsStrAlloc("paused");
+ p->num_reasons ++;
+ }
}
else
cupsdLogMessage(CUPSD_LOG_ERROR,
if (!Printcap || !*Printcap)
return;
+ cupsdLogMessage(CUPSD_LOG_INFO, "Generating printcap %s...", Printcap);
+
/*
* Open the printcap file...
*/
if (infd != 0)
{
- close(0);
- if (infd > 0)
- dup(infd);
- else
- open("/dev/null", O_RDONLY);
+ if (infd < 0)
+ infd = open("/dev/null", O_RDONLY);
+
+ if (infd != 0)
+ {
+ dup2(infd, 0);
+ close(infd);
+ }
}
+
if (outfd != 1)
{
- close(1);
- if (outfd > 0)
- dup(outfd);
- else
- open("/dev/null", O_WRONLY);
+ if (outfd < 0)
+ outfd = open("/dev/null", O_WRONLY);
+
+ if (outfd != 1)
+ {
+ dup2(outfd, 1);
+ close(outfd);
+ }
}
+
if (errfd != 2)
{
- close(2);
- if (errfd > 0)
- dup(errfd);
- else
- open("/dev/null", O_WRONLY);
+ if (errfd < 0)
+ errfd = open("/dev/null", O_WRONLY);
+
+ if (errfd != 2)
+ {
+ dup2(errfd, 2);
+ close(errfd);
+ }
}
- if (backfd != 3)
+
+ if (backfd != 3 && backfd >= 0)
{
- close(3);
- if (backfd > 0)
- dup(backfd);
- else
- open("/dev/null", O_RDWR);
+ dup2(backfd, 3);
+ close(backfd);
fcntl(3, F_SETFL, O_NDELAY);
}
- if (sidefd != 4 && sidefd > 0)
+
+ if (sidefd != 4 && sidefd >= 0)
{
- close(4);
- dup(sidefd);
+ dup2(sidefd, 4);
+ close(sidefd);
fcntl(4, F_SETFL, O_NDELAY);
}
void
cupsdMarkDirty(int what) /* I - What file(s) are dirty? */
{
+ cupsdLogMessage(CUPSD_LOG_DEBUG, "cupsdMarkDirty(%c%c%c%c%c%c)",
+ (what & CUPSD_DIRTY_PRINTERS) ? 'P' : '-',
+ (what & CUPSD_DIRTY_CLASSES) ? 'C' : '-',
+ (what & CUPSD_DIRTY_REMOTE) ? 'R' : '-',
+ (what & CUPSD_DIRTY_PRINTCAP) ? 'p' : '-',
+ (what & CUPSD_DIRTY_JOBS) ? 'J' : '-',
+ (what & CUPSD_DIRTY_SUBSCRIPTIONS) ? 'S' : '-');
+
if (what == CUPSD_DIRTY_PRINTCAP && !Printcap)
return;
--- /dev/null
+
+
+
+
+
+
+
+Network Working Group Editors of this version:
+Request for Comments: 2579 K. McCloghrie
+STD: 58 Cisco Systems
+Obsoletes: 1903 D. Perkins
+Category: Standards Track SNMPinfo
+ J. Schoenwaelder
+ TU Braunschweig
+ Authors of previous version:
+ J. Case
+ SNMP Research
+ K. McCloghrie
+ Cisco Systems
+ M. Rose
+ First Virtual Holdings
+ S. Waldbusser
+ International Network Services
+ April 1999
+
+
+ Textual Conventions for SMIv2
+
+
+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.
+
+
+Table of Contents
+
+ 1 Introduction ..................................................2
+ 1.1 A Note on Terminology .......................................2
+ 2 Definitions ...................................................2
+ 3 Mapping of the TEXTUAL-CONVENTION macro ......................20
+ 3.1 Mapping of the DISPLAY-HINT clause .........................21
+ 3.2 Mapping of the STATUS clause ...............................22
+ 3.3 Mapping of the DESCRIPTION clause ..........................23
+ 3.4 Mapping of the REFERENCE clause ............................23
+ 3.5 Mapping of the SYNTAX clause ...............................23
+ 4 Sub-typing of Textual Conventions ............................23
+ 5 Revising a Textual Convention Definition .....................23
+
+
+McCloghrie, et al. Standards Track [Page 1]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ 6 Security Considerations ......................................24
+ 7 Editors' Addresses ...........................................25
+ 8 References ...................................................25
+ 9 Full Copyright Statement .....................................26
+
+1. Introduction
+
+ Management information is viewed as a collection of managed objects,
+ residing in a virtual information store, termed the Management
+ Information Base (MIB). Collections of related objects are defined
+ in MIB modules. These modules are written using an adapted subset of
+ OSI's Abstract Syntax Notation One, ASN.1 (1988) [1], termed the
+ Structure of Management Information (SMI) [2].
+
+ When designing a MIB module, it is often useful to define new types
+ similar to those defined in the SMI. In comparison to a type defined
+ in the SMI, each of these new types has a different name, a similar
+ syntax, but a more precise semantics. These newly defined types are
+ termed textual conventions, and are used for the convenience of
+ humans reading the MIB module. It is the purpose of this document to
+ define the initial set of textual conventions available to all MIB
+ modules.
+
+ Objects defined using a textual convention are always encoded by
+ means of the rules that define their primitive type. However,
+ textual conventions often have special semantics associated with
+ them. As such, an ASN.1 macro, TEXTUAL-CONVENTION, is used to
+ concisely convey the syntax and semantics of a textual convention.
+
+1.1. A Note on Terminology
+
+ For the purpose of exposition, the original Structure of Management
+ Information, as described in RFCs 1155 (STD 16), 1212 (STD 16), and
+ RFC 1215, is termed the SMI version 1 (SMIv1). The current version
+ of the Structure of Management Information is termed SMI version 2
+ (SMIv2).
+
+2. Definitions
+
+SNMPv2-TC DEFINITIONS ::= BEGIN
+
+IMPORTS
+ TimeTicks FROM SNMPv2-SMI;
+
+
+-- definition of textual conventions
+
+TEXTUAL-CONVENTION MACRO ::=
+
+
+McCloghrie, et al. Standards Track [Page 2]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+BEGIN
+ TYPE NOTATION ::=
+ DisplayPart
+ "STATUS" Status
+ "DESCRIPTION" Text
+ ReferPart
+ "SYNTAX" Syntax
+
+ VALUE NOTATION ::=
+ value(VALUE Syntax) -- adapted ASN.1
+
+ DisplayPart ::=
+ "DISPLAY-HINT" Text
+ | empty
+
+ Status ::=
+ "current"
+ | "deprecated"
+ | "obsolete"
+
+ ReferPart ::=
+ "REFERENCE" Text
+ | empty
+
+ -- a character string as defined in [2]
+ Text ::= value(IA5String)
+
+ Syntax ::= -- Must be one of the following:
+ -- a base type (or its refinement), or
+ -- a BITS pseudo-type
+ type
+ | "BITS" "{" NamedBits "}"
+
+ NamedBits ::= NamedBit
+ | NamedBits "," NamedBit
+
+ NamedBit ::= identifier "(" number ")" -- number is nonnegative
+
+END
+
+
+
+
+DisplayString ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "255a"
+ STATUS current
+ DESCRIPTION
+ "Represents textual information taken from the NVT ASCII
+
+
+McCloghrie, et al. Standards Track [Page 3]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ character set, as defined in pages 4, 10-11 of RFC 854.
+
+ To summarize RFC 854, the NVT ASCII repertoire specifies:
+
+ - the use of character codes 0-127 (decimal)
+
+ - the graphics characters (32-126) are interpreted as
+ US ASCII
+
+ - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
+ meanings specified in RFC 854
+
+ - the other 25 codes have no standard interpretation
+
+ - the sequence 'CR LF' means newline
+
+ - the sequence 'CR NUL' means carriage-return
+
+ - an 'LF' not preceded by a 'CR' means moving to the
+ same column on the next line.
+
+ - the sequence 'CR x' for any x other than LF or NUL is
+ illegal. (Note that this also means that a string may
+ end with either 'CR LF' or 'CR NUL', but not with CR.)
+
+ Any object defined using this syntax may not exceed 255
+ characters in length."
+ SYNTAX OCTET STRING (SIZE (0..255))
+
+PhysAddress ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "1x:"
+ STATUS current
+ DESCRIPTION
+ "Represents media- or physical-level addresses."
+ SYNTAX OCTET STRING
+
+
+MacAddress ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "1x:"
+ STATUS current
+ DESCRIPTION
+ "Represents an 802 MAC address represented in the
+ `canonical' order defined by IEEE 802.1a, i.e., as if it
+ were transmitted least significant bit first, even though
+ 802.5 (in contrast to other 802.x protocols) requires MAC
+ addresses to be transmitted most significant bit first."
+ SYNTAX OCTET STRING (SIZE (6))
+
+
+
+McCloghrie, et al. Standards Track [Page 4]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+TruthValue ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Represents a boolean value."
+ SYNTAX INTEGER { true(1), false(2) }
+
+TestAndIncr ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Represents integer-valued information used for atomic
+ operations. When the management protocol is used to specify
+ that an object instance having this syntax is to be
+ modified, the new value supplied via the management protocol
+ must precisely match the value presently held by the
+ instance. If not, the management protocol set operation
+ fails with an error of `inconsistentValue'. Otherwise, if
+ the current value is the maximum value of 2^31-1 (2147483647
+ decimal), then the value held by the instance is wrapped to
+ zero; otherwise, the value held by the instance is
+ incremented by one. (Note that regardless of whether the
+ management protocol set operation succeeds, the variable-
+ binding in the request and response PDUs are identical.)
+
+ The value of the ACCESS clause for objects having this
+ syntax is either `read-write' or `read-create'. When an
+ instance of a columnar object having this syntax is created,
+ any value may be supplied via the management protocol.
+
+ When the network management portion of the system is re-
+ initialized, the value of every object instance having this
+ syntax must either be incremented from its value prior to
+ the re-initialization, or (if the value prior to the re-
+ initialization is unknown) be set to a pseudo-randomly
+ generated value."
+ SYNTAX INTEGER (0..2147483647)
+
+AutonomousType ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Represents an independently extensible type identification
+ value. It may, for example, indicate a particular sub-tree
+ with further MIB definitions, or define a particular type of
+ protocol or hardware."
+ SYNTAX OBJECT IDENTIFIER
+
+
+InstancePointer ::= TEXTUAL-CONVENTION
+ STATUS obsolete
+
+
+McCloghrie, et al. Standards Track [Page 5]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ DESCRIPTION
+ "A pointer to either a specific instance of a MIB object or
+ a conceptual row of a MIB table in the managed device. In
+ the latter case, by convention, it is the name of the
+ particular instance of the first accessible columnar object
+ in the conceptual row.
+
+ The two uses of this textual convention are replaced by
+ VariablePointer and RowPointer, respectively."
+ SYNTAX OBJECT IDENTIFIER
+
+
+VariablePointer ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "A pointer to a specific object instance. For example,
+ sysContact.0 or ifInOctets.3."
+ SYNTAX OBJECT IDENTIFIER
+
+
+RowPointer ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Represents a pointer to a conceptual row. The value is the
+ name of the instance of the first accessible columnar object
+ in the conceptual row.
+
+ For example, ifIndex.3 would point to the 3rd row in the
+ ifTable (note that if ifIndex were not-accessible, then
+ ifDescr.3 would be used instead)."
+ SYNTAX OBJECT IDENTIFIER
+
+RowStatus ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "The RowStatus textual convention is used to manage the
+ creation and deletion of conceptual rows, and is used as the
+ value of the SYNTAX clause for the status column of a
+ conceptual row (as described in Section 7.7.1 of [2].)
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 6]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ The status column has six defined values:
+
+ - `active', which indicates that the conceptual row is
+ available for use by the managed device;
+
+ - `notInService', which indicates that the conceptual
+ row exists in the agent, but is unavailable for use by
+ the managed device (see NOTE below); 'notInService' has
+ no implication regarding the internal consistency of
+ the row, availability of resources, or consistency with
+ the current state of the managed device;
+
+ - `notReady', which indicates that the conceptual row
+ exists in the agent, but is missing information
+ necessary in order to be available for use by the
+ managed device (i.e., one or more required columns in
+ the conceptual row have not been instanciated);
+
+ - `createAndGo', which is supplied by a management
+ station wishing to create a new instance of a
+ conceptual row and to have its status automatically set
+ to active, making it available for use by the managed
+ device;
+
+ - `createAndWait', which is supplied by a management
+ station wishing to create a new instance of a
+ conceptual row (but not make it available for use by
+ the managed device); and,
+
+ - `destroy', which is supplied by a management station
+ wishing to delete all of the instances associated with
+ an existing conceptual row.
+
+ Whereas five of the six values (all except `notReady') may
+ be specified in a management protocol set operation, only
+ three values will be returned in response to a management
+ protocol retrieval operation: `notReady', `notInService' or
+ `active'. That is, when queried, an existing conceptual row
+ has only three states: it is either available for use by
+ the managed device (the status column has value `active');
+ it is not available for use by the managed device, though
+ the agent has sufficient information to attempt to make it
+ so (the status column has value `notInService'); or, it is
+ not available for use by the managed device, and an attempt
+ to make it so would fail because the agent has insufficient
+ information (the state column has value `notReady').
+
+
+
+
+McCloghrie, et al. Standards Track [Page 7]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ NOTE WELL
+
+ This textual convention may be used for a MIB table,
+ irrespective of whether the values of that table's
+ conceptual rows are able to be modified while it is
+ active, or whether its conceptual rows must be taken
+ out of service in order to be modified. That is, it is
+ the responsibility of the DESCRIPTION clause of the
+ status column to specify whether the status column must
+ not be `active' in order for the value of some other
+ column of the same conceptual row to be modified. If
+ such a specification is made, affected columns may be
+ changed by an SNMP set PDU if the RowStatus would not
+ be equal to `active' either immediately before or after
+ processing the PDU. In other words, if the PDU also
+ contained a varbind that would change the RowStatus
+ value, the column in question may be changed if the
+ RowStatus was not equal to `active' as the PDU was
+ received, or if the varbind sets the status to a value
+ other than 'active'.
+
+
+ Also note that whenever any elements of a row exist, the
+ RowStatus column must also exist.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 8]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ To summarize the effect of having a conceptual row with a
+ status column having a SYNTAX clause value of RowStatus,
+ consider the following state diagram:
+
+
+ STATE
+ +--------------+-----------+-------------+-------------
+ | A | B | C | D
+ | |status col.|status column|
+ |status column | is | is |status column
+ ACTION |does not exist| notReady | notInService| is active
+--------------+--------------+-----------+-------------+-------------
+set status |noError ->D|inconsist- |inconsistent-|inconsistent-
+column to | or | entValue| Value| Value
+createAndGo |inconsistent- | | |
+ | Value| | |
+--------------+--------------+-----------+-------------+-------------
+set status |noError see 1|inconsist- |inconsistent-|inconsistent-
+column to | or | entValue| Value| Value
+createAndWait |wrongValue | | |
+--------------+--------------+-----------+-------------+-------------
+set status |inconsistent- |inconsist- |noError |noError
+column to | Value| entValue| |
+active | | | |
+ | | or | |
+ | | | |
+ | |see 2 ->D|see 8 ->D| ->D
+--------------+--------------+-----------+-------------+-------------
+set status |inconsistent- |inconsist- |noError |noError ->C
+column to | Value| entValue| |
+notInService | | | |
+ | | or | | or
+ | | | |
+ | |see 3 ->C| ->C|see 6
+--------------+--------------+-----------+-------------+-------------
+set status |noError |noError |noError |noError ->A
+column to | | | | or
+destroy | ->A| ->A| ->A|see 7
+--------------+--------------+-----------+-------------+-------------
+set any other |see 4 |noError |noError |see 5
+column to some| | | |
+value | | see 1| ->C| ->D
+--------------+--------------+-----------+-------------+-------------
+
+ (1) goto B or C, depending on information available to the
+ agent.
+
+ (2) if other variable bindings included in the same PDU,
+
+
+McCloghrie, et al. Standards Track [Page 9]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ provide values for all columns which are missing but
+ required, and all columns have acceptable values, then
+ return noError and goto D.
+
+ (3) if other variable bindings included in the same PDU,
+ provide legal values for all columns which are missing but
+ required, then return noError and goto C.
+
+ (4) at the discretion of the agent, the return value may be
+ either:
+
+ inconsistentName: because the agent does not choose to
+ create such an instance when the corresponding
+ RowStatus instance does not exist, or
+
+ inconsistentValue: if the supplied value is
+ inconsistent with the state of some other MIB object's
+ value, or
+
+ noError: because the agent chooses to create the
+ instance.
+
+ If noError is returned, then the instance of the status
+ column must also be created, and the new state is B or C,
+ depending on the information available to the agent. If
+ inconsistentName or inconsistentValue is returned, the row
+ remains in state A.
+
+ (5) depending on the MIB definition for the column/table,
+ either noError or inconsistentValue may be returned.
+
+ (6) the return value can indicate one of the following
+ errors:
+
+ wrongValue: because the agent does not support
+ notInService (e.g., an agent which does not support
+ createAndWait), or
+
+ inconsistentValue: because the agent is unable to take
+ the row out of service at this time, perhaps because it
+ is in use and cannot be de-activated.
+
+ (7) the return value can indicate the following error:
+
+ inconsistentValue: because the agent is unable to
+ remove the row at this time, perhaps because it is in
+ use and cannot be de-activated.
+
+
+
+McCloghrie, et al. Standards Track [Page 10]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ (8) the transition to D can fail, e.g., if the values of the
+ conceptual row are inconsistent, then the error code would
+ be inconsistentValue.
+
+ NOTE: Other processing of (this and other varbinds of) the
+ set request may result in a response other than noError
+ being returned, e.g., wrongValue, noCreation, etc.
+
+
+ Conceptual Row Creation
+
+ There are four potential interactions when creating a
+ conceptual row: selecting an instance-identifier which is
+ not in use; creating the conceptual row; initializing any
+ objects for which the agent does not supply a default; and,
+ making the conceptual row available for use by the managed
+ device.
+
+ Interaction 1: Selecting an Instance-Identifier
+
+ The algorithm used to select an instance-identifier varies
+ for each conceptual row. In some cases, the instance-
+ identifier is semantically significant, e.g., the
+ destination address of a route, and a management station
+ selects the instance-identifier according to the semantics.
+
+ In other cases, the instance-identifier is used solely to
+ distinguish conceptual rows, and a management station
+ without specific knowledge of the conceptual row might
+ examine the instances present in order to determine an
+ unused instance-identifier. (This approach may be used, but
+ it is often highly sub-optimal; however, it is also a
+ questionable practice for a naive management station to
+ attempt conceptual row creation.)
+
+ Alternately, the MIB module which defines the conceptual row
+ might provide one or more objects which provide assistance
+ in determining an unused instance-identifier. For example,
+ if the conceptual row is indexed by an integer-value, then
+ an object having an integer-valued SYNTAX clause might be
+ defined for such a purpose, allowing a management station to
+ issue a management protocol retrieval operation. In order
+ to avoid unnecessary collisions between competing management
+ stations, `adjacent' retrievals of this object should be
+ different.
+
+ Finally, the management station could select a pseudo-random
+ number to use as the index. In the event that this index
+
+
+McCloghrie, et al. Standards Track [Page 11]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ was already in use and an inconsistentValue was returned in
+ response to the management protocol set operation, the
+ management station should simply select a new pseudo-random
+ number and retry the operation.
+
+ A MIB designer should choose between the two latter
+ algorithms based on the size of the table (and therefore the
+ efficiency of each algorithm). For tables in which a large
+ number of entries are expected, it is recommended that a MIB
+ object be defined that returns an acceptable index for
+ creation. For tables with small numbers of entries, it is
+ recommended that the latter pseudo-random index mechanism be
+ used.
+
+ Interaction 2: Creating the Conceptual Row
+
+ Once an unused instance-identifier has been selected, the
+ management station determines if it wishes to create and
+ activate the conceptual row in one transaction or in a
+ negotiated set of interactions.
+
+ Interaction 2a: Creating and Activating the Conceptual Row
+
+ The management station must first determine the column
+ requirements, i.e., it must determine those columns for
+ which it must or must not provide values. Depending on the
+ complexity of the table and the management station's
+ knowledge of the agent's capabilities, this determination
+ can be made locally by the management station. Alternately,
+ the management station issues a management protocol get
+ operation to examine all columns in the conceptual row that
+ it wishes to create. In response, for each column, there
+ are three possible outcomes:
+
+ - a value is returned, indicating that some other
+ management station has already created this conceptual
+ row. We return to interaction 1.
+
+ - the exception `noSuchInstance' is returned,
+ indicating that the agent implements the object-type
+ associated with this column, and that this column in at
+ least one conceptual row would be accessible in the MIB
+ view used by the retrieval were it to exist. For those
+ columns to which the agent provides read-create access,
+ the `noSuchInstance' exception tells the management
+ station that it should supply a value for this column
+ when the conceptual row is to be created.
+
+
+
+McCloghrie, et al. Standards Track [Page 12]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ - the exception `noSuchObject' is returned, indicating
+ that the agent does not implement the object-type
+ associated with this column or that there is no
+ conceptual row for which this column would be
+ accessible in the MIB view used by the retrieval. As
+ such, the management station can not issue any
+ management protocol set operations to create an
+ instance of this column.
+
+ Once the column requirements have been determined, a
+ management protocol set operation is accordingly issued.
+ This operation also sets the new instance of the status
+ column to `createAndGo'.
+
+ When the agent processes the set operation, it verifies that
+ it has sufficient information to make the conceptual row
+ available for use by the managed device. The information
+ available to the agent is provided by two sources: the
+ management protocol set operation which creates the
+ conceptual row, and, implementation-specific defaults
+ supplied by the agent (note that an agent must provide
+ implementation-specific defaults for at least those objects
+ which it implements as read-only). If there is sufficient
+ information available, then the conceptual row is created, a
+ `noError' response is returned, the status column is set to
+ `active', and no further interactions are necessary (i.e.,
+ interactions 3 and 4 are skipped). If there is insufficient
+ information, then the conceptual row is not created, and the
+ set operation fails with an error of `inconsistentValue'.
+ On this error, the management station can issue a management
+ protocol retrieval operation to determine if this was
+ because it failed to specify a value for a required column,
+ or, because the selected instance of the status column
+ already existed. In the latter case, we return to
+ interaction 1. In the former case, the management station
+ can re-issue the set operation with the additional
+ information, or begin interaction 2 again using
+ `createAndWait' in order to negotiate creation of the
+ conceptual row.
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 13]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ NOTE WELL
+
+ Regardless of the method used to determine the column
+ requirements, it is possible that the management
+ station might deem a column necessary when, in fact,
+ the agent will not allow that particular columnar
+ instance to be created or written. In this case, the
+ management protocol set operation will fail with an
+ error such as `noCreation' or `notWritable'. In this
+ case, the management station decides whether it needs
+ to be able to set a value for that particular columnar
+ instance. If not, the management station re-issues the
+ management protocol set operation, but without setting
+ a value for that particular columnar instance;
+ otherwise, the management station aborts the row
+ creation algorithm.
+
+ Interaction 2b: Negotiating the Creation of the Conceptual
+ Row
+
+ The management station issues a management protocol set
+ operation which sets the desired instance of the status
+ column to `createAndWait'. If the agent is unwilling to
+ process a request of this sort, the set operation fails with
+ an error of `wrongValue'. (As a consequence, such an agent
+ must be prepared to accept a single management protocol set
+ operation, i.e., interaction 2a above, containing all of the
+ columns indicated by its column requirements.) Otherwise,
+ the conceptual row is created, a `noError' response is
+ returned, and the status column is immediately set to either
+ `notInService' or `notReady', depending on whether it has
+ sufficient information to (attempt to) make the conceptual
+ row available for use by the managed device. If there is
+ sufficient information available, then the status column is
+ set to `notInService'; otherwise, if there is insufficient
+ information, then the status column is set to `notReady'.
+ Regardless, we proceed to interaction 3.
+
+ Interaction 3: Initializing non-defaulted Objects
+
+ The management station must now determine the column
+ requirements. It issues a management protocol get operation
+ to examine all columns in the created conceptual row. In
+ the response, for each column, there are three possible
+ outcomes:
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 14]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ - a value is returned, indicating that the agent
+ implements the object-type associated with this column
+ and had sufficient information to provide a value. For
+ those columns to which the agent provides read-create
+ access (and for which the agent allows their values to
+ be changed after their creation), a value return tells
+ the management station that it may issue additional
+ management protocol set operations, if it desires, in
+ order to change the value associated with this column.
+
+ - the exception `noSuchInstance' is returned,
+ indicating that the agent implements the object-type
+ associated with this column, and that this column in at
+ least one conceptual row would be accessible in the MIB
+ view used by the retrieval were it to exist. However,
+ the agent does not have sufficient information to
+ provide a value, and until a value is provided, the
+ conceptual row may not be made available for use by the
+ managed device. For those columns to which the agent
+ provides read-create access, the `noSuchInstance'
+ exception tells the management station that it must
+ issue additional management protocol set operations, in
+ order to provide a value associated with this column.
+
+ - the exception `noSuchObject' is returned, indicating
+ that the agent does not implement the object-type
+ associated with this column or that there is no
+ conceptual row for which this column would be
+ accessible in the MIB view used by the retrieval. As
+ such, the management station can not issue any
+ management protocol set operations to create an
+ instance of this column.
+
+ If the value associated with the status column is
+ `notReady', then the management station must first deal with
+ all `noSuchInstance' columns, if any. Having done so, the
+ value of the status column becomes `notInService', and we
+ proceed to interaction 4.
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 15]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ Interaction 4: Making the Conceptual Row Available
+
+ Once the management station is satisfied with the values
+ associated with the columns of the conceptual row, it issues
+ a management protocol set operation to set the status column
+ to `active'. If the agent has sufficient information to
+ make the conceptual row available for use by the managed
+ device, the management protocol set operation succeeds (a
+ `noError' response is returned). Otherwise, the management
+ protocol set operation fails with an error of
+ `inconsistentValue'.
+
+ NOTE WELL
+
+ A conceptual row having a status column with value
+ `notInService' or `notReady' is unavailable to the
+ managed device. As such, it is possible for the
+ managed device to create its own instances during the
+ time between the management protocol set operation
+ which sets the status column to `createAndWait' and the
+ management protocol set operation which sets the status
+ column to `active'. In this case, when the management
+ protocol set operation is issued to set the status
+ column to `active', the values held in the agent
+ supersede those used by the managed device.
+
+ If the management station is prevented from setting the
+ status column to `active' (e.g., due to management station
+ or network failure) the conceptual row will be left in the
+ `notInService' or `notReady' state, consuming resources
+ indefinitely. The agent must detect conceptual rows that
+ have been in either state for an abnormally long period of
+ time and remove them. It is the responsibility of the
+ DESCRIPTION clause of the status column to indicate what an
+ abnormally long period of time would be. This period of
+ time should be long enough to allow for human response time
+ (including `think time') between the creation of the
+ conceptual row and the setting of the status to `active'.
+ In the absence of such information in the DESCRIPTION
+ clause, it is suggested that this period be approximately 5
+ minutes in length. This removal action applies not only to
+ newly-created rows, but also to previously active rows which
+ are set to, and left in, the notInService state for a
+ prolonged period exceeding that which is considered normal
+ for such a conceptual row.
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 16]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ Conceptual Row Suspension
+
+ When a conceptual row is `active', the management station
+ may issue a management protocol set operation which sets the
+ instance of the status column to `notInService'. If the
+ agent is unwilling to do so, the set operation fails with an
+ error of `wrongValue' or `inconsistentValue'. Otherwise,
+ the conceptual row is taken out of service, and a `noError'
+ response is returned. It is the responsibility of the
+ DESCRIPTION clause of the status column to indicate under
+ what circumstances the status column should be taken out of
+ service (e.g., in order for the value of some other column
+ of the same conceptual row to be modified).
+
+
+ Conceptual Row Deletion
+
+ For deletion of conceptual rows, a management protocol set
+ operation is issued which sets the instance of the status
+ column to `destroy'. This request may be made regardless of
+ the current value of the status column (e.g., it is possible
+ to delete conceptual rows which are either `notReady',
+ `notInService' or `active'.) If the operation succeeds,
+ then all instances associated with the conceptual row are
+ immediately removed."
+ SYNTAX INTEGER {
+ -- the following two values are states:
+ -- these values may be read or written
+ active(1),
+ notInService(2),
+
+ -- the following value is a state:
+ -- this value may be read, but not written
+ notReady(3),
+
+ -- the following three values are
+ -- actions: these values may be written,
+ -- but are never read
+ createAndGo(4),
+ createAndWait(5),
+ destroy(6)
+ }
+
+TimeStamp ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "The value of the sysUpTime object at which a specific
+ occurrence happened. The specific occurrence must be
+
+
+McCloghrie, et al. Standards Track [Page 17]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ defined in the description of any object defined using this
+ type.
+
+ If sysUpTime is reset to zero as a result of a re-
+ initialization of the network management (sub)system, then
+ the values of all TimeStamp objects are also reset.
+ However, after approximately 497 days without a re-
+ initialization, the sysUpTime object will reach 2^^32-1 and
+ then increment around to zero; in this case, existing values
+ of TimeStamp objects do not change. This can lead to
+ ambiguities in the value of TimeStamp objects."
+ SYNTAX TimeTicks
+
+
+TimeInterval ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "A period of time, measured in units of 0.01 seconds."
+ SYNTAX INTEGER (0..2147483647)
+
+DateAndTime ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
+ STATUS current
+ DESCRIPTION
+ "A date-time specification.
+
+ field octets contents range
+ ----- ------ -------- -----
+ 1 1-2 year* 0..65536
+ 2 3 month 1..12
+ 3 4 day 1..31
+ 4 5 hour 0..23
+ 5 6 minutes 0..59
+ 6 7 seconds 0..60
+ (use 60 for leap-second)
+ 7 8 deci-seconds 0..9
+ 8 9 direction from UTC '+' / '-'
+ 9 10 hours from UTC* 0..13
+ 10 11 minutes from UTC 0..59
+
+ * Notes:
+ - the value of year is in network-byte order
+ - daylight saving time in New Zealand is +13
+
+ For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
+ displayed as:
+
+ 1992-5-26,13:30:15.0,-4:0
+
+
+McCloghrie, et al. Standards Track [Page 18]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ Note that if only local time is known, then timezone
+ information (fields 8-10) is not present."
+ SYNTAX OCTET STRING (SIZE (8 | 11))
+
+
+StorageType ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Describes the memory realization of a conceptual row. A
+ row which is volatile(2) is lost upon reboot. A row which
+ is either nonVolatile(3), permanent(4) or readOnly(5), is
+ backed up by stable storage. A row which is permanent(4)
+ can be changed but not deleted. A row which is readOnly(5)
+ cannot be changed nor deleted.
+
+ If the value of an object with this syntax is either
+ permanent(4) or readOnly(5), it cannot be written.
+ Conversely, if the value is either other(1), volatile(2) or
+ nonVolatile(3), it cannot be modified to be permanent(4) or
+ readOnly(5). (All illegal modifications result in a
+ 'wrongValue' error.)
+
+ Every usage of this textual convention is required to
+ specify the columnar objects which a permanent(4) row must
+ at a minimum allow to be writable."
+ SYNTAX INTEGER {
+ other(1), -- eh?
+ volatile(2), -- e.g., in RAM
+ nonVolatile(3), -- e.g., in NVRAM
+ permanent(4), -- e.g., partially in ROM
+ readOnly(5) -- e.g., completely in ROM
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 19]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+TDomain ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Denotes a kind of transport service.
+
+ Some possible values, such as snmpUDPDomain, are defined in
+ the SNMPv2-TM MIB module. Other possible values are defined
+ in other MIB modules."
+ REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
+ SYNTAX OBJECT IDENTIFIER
+
+
+TAddress ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Denotes a transport service address.
+
+ A TAddress value is always interpreted within the context of a
+ TDomain value. Thus, each definition of a TDomain value must
+ be accompanied by a definition of a textual convention for use
+ with that TDomain. Some possible textual conventions, such as
+ SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM
+ MIB module. Other possible textual conventions are defined in
+ other MIB modules."
+ REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
+ SYNTAX OCTET STRING (SIZE (1..255))
+
+
+END
+
+3. Mapping of the TEXTUAL-CONVENTION macro
+
+ The TEXTUAL-CONVENTION macro is used to convey the syntax and
+ semantics associated with a textual convention. It should be noted
+ that the expansion of the TEXTUAL-CONVENTION macro is something which
+ conceptually happens during implementation and not during run-time.
+
+ The name of a textual convention must consist of one or more letters
+ or digits, with the initial character being an upper case letter.
+ The name must not conflict with any of the reserved words listed in
+ section 3.7 of [2], should not consist of all upper case letters, and
+ shall not exceed 64 characters in length. (However, names longer
+ than 32 characters are not recommended.) The hyphen is not allowed
+ in the name of a textual convention (except for use in information
+ modules converted from SMIv1 which allowed hyphens in ASN.1 type
+ assignments). Further, all names used for the textual conventions
+ defined in all "standard" information modules shall be unique.
+
+
+
+McCloghrie, et al. Standards Track [Page 20]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+3.1. Mapping of the DISPLAY-HINT clause
+
+ The DISPLAY-HINT clause, which need not be present, gives a hint as
+ to how the value of an instance of an object with the syntax defined
+ using this textual convention might be displayed. The DISPLAY-HINT
+ clause must not be present if the Textual Convention is defined with
+ a syntax of: OBJECT IDENTIFIER, IpAddress, Counter32, Counter64, or
+ any enumerated syntax (BITS or INTEGER). The determination of
+ whether it makes sense for other syntax types is dependent on the
+ specific definition of the Textual Convention.
+
+ When the syntax has an underlying primitive type of INTEGER, the hint
+ consists of an integer-format specification, containing two parts.
+ The first part is a single character suggesting a display format,
+ either: `x' for hexadecimal, or `d' for decimal, or `o' for octal, or
+ `b' for binary. For all types, when rendering the value, leading
+ zeros are omitted, and for negative values, a minus sign is rendered
+ immediately before the digits. The second part is always omitted for
+ `x', `o' and `b', and need not be present for `d'. If present, the
+ second part starts with a hyphen and is followed by a decimal number,
+ which defines the implied decimal point when rendering the value.
+ For example:
+
+ Hundredths ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "d-2"
+ ...
+ SYNTAX INTEGER (0..10000)
+
+ suggests that a Hundredths value of 1234 be rendered as "12.34"
+
+
+ When the syntax has an underlying primitive type of OCTET STRING, the
+ hint consists of one or more octet-format specifications. Each
+ specification consists of five parts, with each part using and
+ removing zero or more of the next octets from the value and producing
+ the next zero or more characters to be displayed. The octets within
+ the value are processed in order of significance, most significant
+ first.
+
+ The five parts of a octet-format specification are:
+
+(1) the (optional) repeat indicator; if present, this part is a `*',
+ and indicates that the current octet of the value is to be used as
+ the repeat count. The repeat count is an unsigned integer (which
+ may be zero) which specifies how many times the remainder of this
+ octet-format specification should be successively applied. If the
+ repeat indicator is not present, the repeat count is one.
+
+
+
+McCloghrie, et al. Standards Track [Page 21]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+(2) the octet length: one or more decimal digits specifying the number
+ of octets of the value to be used and formatted by this octet-
+ specification. Note that the octet length can be zero. If less
+ than this number of octets remain in the value, then the lesser
+ number of octets are used.
+
+(3) the display format, either: `x' for hexadecimal, `d' for decimal,
+ `o' for octal, `a' for ascii, or `t' for UTF-8. If the octet
+ length part is greater than one, and the display format part refers
+ to a numeric format, then network-byte ordering (big-endian
+ encoding) is used interpreting the octets in the value. The octets
+ processed by the `t' display format do not necessarily form an
+ integral number of UTF-8 characters. Trailing octets which do not
+ form a valid UTF-8 encoded character are discarded.
+
+(4) the (optional) display separator character; if present, this part
+ is a single character which is produced for display after each
+ application of this octet-specification; however, this character is
+ not produced for display if it would be immediately followed by the
+ display of the repeat terminator character for this octet-
+ specification. This character can be any character other than a
+ decimal digit and a `*'.
+
+(5) the (optional) repeat terminator character, which can be present
+ only if the display separator character is present and this octet-
+ specification begins with a repeat indicator; if present, this part
+ is a single character which is produced after all the zero or more
+ repeated applications (as given by the repeat count) of this
+ octet-specification. This character can be any character other
+ than a decimal digit and a `*'.
+
+ Output of a display separator character or a repeat terminator
+ character is suppressed if it would occur as the last character of
+ the display.
+
+ If the octets of the value are exhausted before all the octet-format
+ specification have been used, then the excess specifications are
+ ignored. If additional octets remain in the value after interpreting
+ all the octet-format specifications, then the last octet-format
+ specification is re-interpreted to process the additional octets,
+ until no octets remain in the value.
+
+3.2. Mapping of the STATUS clause
+
+ The STATUS clause, which must be present, indicates whether this
+ definition is current or historic.
+
+ The value "current" means that the definition is current and valid.
+
+
+McCloghrie, et al. Standards Track [Page 22]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ The value "obsolete" means the definition is obsolete and should not
+ be implemented and/or can be removed if previously implemented.
+ While the value "deprecated" also indicates an obsolete definition,
+ it permits new/continued implementation in order to foster
+ interoperability with older/existing implementations.
+
+3.3. Mapping of the DESCRIPTION clause
+
+ The DESCRIPTION clause, which must be present, contains a textual
+ definition of the textual convention, which provides all semantic
+ definitions necessary for implementation, and should embody any
+ information which would otherwise be communicated in any ASN.1
+ commentary annotations associated with the object.
+
+3.4. Mapping of the REFERENCE clause
+
+ The REFERENCE clause, which need not be present, contains a textual
+ cross-reference to some other document, either another information
+ module which defines a related assignment, or some other document
+ which provides additional information relevant to this definition.
+
+3.5. Mapping of the SYNTAX clause
+
+ The SYNTAX clause, which must be present, defines abstract data
+ structure corresponding to the textual convention. The data
+ structure must be one of the alternatives defined in the ObjectSyntax
+ CHOICE or the BITS construct (see section 7.1 in [2]). Note that
+ this means that the SYNTAX clause of a Textual Convention can not
+ refer to a previously defined Textual Convention.
+
+ An extended subset of the full capabilities of ASN.1 (1988) sub-
+ typing is allowed, as appropriate to the underlying ASN.1 type. Any
+ such restriction on size, range or enumerations specified in this
+ clause represents the maximal level of support which makes "protocol
+ sense". Restrictions on sub-typing are specified in detail in
+ Section 9 and Appendix A of [2].
+
+4. Sub-typing of Textual Conventions
+
+ The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in
+ the same way as the SYNTAX clause of an OBJECT-TYPE macro (see
+ section 11 of [2]).
+
+5. Revising a Textual Convention Definition
+
+ It may be desirable to revise the definition of a textual convention
+ after experience is gained with it. However, changes are not allowed
+ if they have any potential to cause interoperability problems "over
+
+
+McCloghrie, et al. Standards Track [Page 23]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+ the wire" between an implementation using an original specification
+ and an implementation using an updated specification(s). Such
+ changes can only be accommodated by defining a new textual convention
+ (i.e., a new name).
+
+ The following revisions are allowed:
+
+(1) A SYNTAX clause containing an enumerated INTEGER may have new
+ enumerations added or existing labels changed. Similarly, named
+ bits may be added or existing labels changed for the BITS
+ construct.
+
+(2) A STATUS clause value of "current" may be revised as "deprecated"
+ or "obsolete". Similarly, a STATUS clause value of "deprecated"
+ may be revised as "obsolete". When making such a change, the
+ DESCRIPTION clause should be updated to explain the rationale.
+
+(3) A REFERENCE clause may be added or updated.
+
+(4) A DISPLAY-HINTS clause may be added or updated.
+
+(5) Clarifications and additional information may be included in the
+ DESCRIPTION clause.
+
+(6) Any editorial change.
+
+ Note that with the introduction of the TEXTUAL-CONVENTION macro,
+ there is no longer any need to define types in the following manner:
+
+ DisplayString ::= OCTET STRING (SIZE (0..255))
+
+ When revising an information module containing a definition such as
+ this, that definition should be replaced by a TEXTUAL-CONVENTION
+ macro.
+
+6. Security Considerations
+
+ This document defines the means to define new data types for the
+ language used to write and read descriptions of management
+ information. These data types have no security impact on the
+ Internet.
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 24]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 April 1999
+
+
+7. Editors' Addresses
+
+ Keith McCloghrie
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ USA
+ Phone: +1 408 526 5260
+ EMail: kzm@cisco.com
+
+ David Perkins
+ SNMPinfo
+ 3763 Benton Street
+ Santa Clara, CA 95051
+ USA
+ Phone: +1 408 221-8702
+ EMail: dperkins@snmpinfo.com
+
+ Juergen Schoenwaelder
+ TU Braunschweig
+ Bueltenweg 74/75
+ 38106 Braunschweig
+ Germany
+ Phone: +49 531 391-3283
+ EMail: schoenw@ibr.cs.tu-bs.de
+
+
+8. References
+
+[1] Information processing systems - Open Systems Interconnection -
+ Specification of Abstract Syntax Notation One (ASN.1),
+ International Organization for Standardization. International
+ Standard 8824, (December, 1987).
+
+[2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
+ and S. Waldbusser, "Structure of Management Information Version 2
+ (SMIv2)", STD 58, RFC 2578, April 1999.
+
+[3] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
+ Waldbusser, S., "Transport Mappings for Version 2 of the" Simple
+ Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 25]
+\f
+
+
+
+
+RFC 2579 Textual Conventions for SMIv2 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."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al. Standards Track [Page 26]
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / cups.git / commitdiff
