5.  Object Attributes

   This section describes the attributes with their corresponding
   attribute syntaxes and values that are part of the IPP Model.  The
   sections below show the objects and their associated attributes that
   are included within the scope of this protocol.  Many of these
   attributes are derived from other relevant documents:

   o  Document Printing Application (DPA) [ISO10175]

   o  Printer MIB v2 [RFC3805]

   Each attribute is uniquely identified in this document using a
   "keyword" (see Section 2.3.7) that is the name of the attribute.  The
   keyword is included in the section title describing that attribute.

   Note: Not only are keywords used to identify attributes, but one of
   the attribute syntaxes described below is "keyword" so that some
   attributes have 'keyword' values.  Therefore, these attributes are
   defined as having an attribute syntax that is a set of keywords.

5.1.  Attribute Syntaxes

   This section defines the basic attribute syntax types that all
   Clients and IPP objects MUST be able to accept in responses and
   accept in requests, respectively.  Each attribute description in
   Sections 4 and 5 includes in the section title the name of the
   attribute with its syntax(es) in parentheses.  A conforming
   implementation of an attribute MUST include the semantics of the
   attribute syntax(es) so identified.  Section 7.7 describes how the
   protocol can be extended with new attribute syntaxes.

   The attribute syntaxes are specified in the following subsections,
   where the subsection title is the keyword name of the attribute
   syntax inside the single quotes.  In operation requests and
   responses, each attribute value MUST be represented as one of the
   attribute syntaxes specified in the subsection title for the
   attribute.  In addition, the value of an attribute in a response (but
   not in a request) MAY be one of the "out-of-band" values
   (Section 5.1.1) whose special encoding rules are defined in the
   Encoding and Transport document [RFC8010].

   All attributes in a request MUST have one or more values as defined
   in Sections 5.2, 5.3, and 5.4.  All attributes in a response MUST
   have either (1) one or more values as defined in Sections 5.2, 5.3,
   and 5.4 or (2) a single "out-of-band" value.

   Most attributes are defined to have a single attribute syntax.
   However, a few attributes (e.g., "job-sheet", "media",
   "job-hold-until") are defined to have several attribute syntaxes,
   depending on the value.  These multiple attribute syntaxes are
   separated by the "|" character in the subsection title to indicate
   the choice.  Since each value MUST be tagged as to its attribute
   syntax in the protocol, a single-valued attribute instance can have
   any one of its attribute syntaxes and a multi-valued attribute
   instance can have a mixture of its defined attribute syntaxes.

5.1.1.  Out-of-Band Values - 'unknown', 'unsupported', and 'no-value'

   This document defines three "out-of-band" values that are used in
   place of an attribute's defined syntax:

   o  'unknown': The attribute is supported by the IPP object, but the
      value is unknown to the IPP object for some reason.  This
      out-of-band value is used for attributes that have an intrinsic,
      physical value that cannot be determined by the IPP object at a
      given time, e.g., sheet count, geo-location, etc.

   o  'unsupported': The attribute is unsupported by the IPP object.
      This value MUST be returned only as the value of an attribute in
      the Unsupported Attributes group.

   o  'no-value': The attribute is supported by the Printer, but the
      Administrator has not yet configured a value.

5.1.2.  'text'

   A 'text' attribute is an attribute whose value is a sequence of zero
   or more characters encoded in a maximum of 1023 ('MAX') octets.  MAX
   is the maximum length for each value of any 'text' attribute.
   However, if an attribute will always contain values whose maximum
   length is much less than MAX, the definition of that attribute will
   include a qualifier that defines the maximum length for values of
   that attribute.  For example, the "printer-location" attribute is
   specified as "printer-location (text(127))".  In this case, text
   values for "printer-location" MUST NOT exceed 127 octets; if supplied
   with a longer text string via some external interface (other than the
   protocol), implementations are free to truncate to this shorter
   length limitation.

   In this document, all 'text' attributes are defined using the 'text'
   syntax.  However, 'text' is used only for brevity; the formal
   interpretation of 'text' is 'textWithoutLanguage | textWithLanguage'.
   That is, for any attribute defined in this document using the 'text'
   attribute syntax, all IPP objects and Clients MUST support both the
   'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes.
   However, in actual usage and protocol execution, IPP objects and
   Clients accept and return only one of the two syntaxes per attribute.
   The syntax 'text' never appears "on-the-wire".

   Both 'textWithoutLanguage' and 'textWithLanguage' are needed to
   support the real-world needs of interoperability between sites and
   systems that use different natural languages as the basis for human
   communication.  Generally, one natural language applies to all 'text'
   attributes in a given request or response.  The language is indicated
   by the "attributes-natural-language" operation attribute defined in
   Section 4.1.4 or the "attributes-natural-language" Job attribute
   defined in Section 5.3.20, and there is no need to identify the
   natural language for each text string on a value-by-value basis.  In
   these cases, the attribute syntax 'textWithoutLanguage' is used for
   'text' attributes.  In other cases, the Client needs to supply or the
   Printer needs to return a text value in a natural language that is
   different from the rest of the text values in the request or
   response.  In these cases, the Client or Printer uses the attribute
   syntax 'textWithLanguage' for 'text' attributes (this is the Natural
   Language Override mechanism described in Section 4.1.4).

   The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes
   are described in more detail in the following sections.

5.1.2.1.  'textWithoutLanguage'

   The 'textWithoutLanguage' syntax indicates a value that is a sequence
   of zero or more characters encoded in a maximum of 1023 (MAX) octets.
   Text strings are encoded using the rules of some charset.  The
   Printer MUST support the UTF-8 charset [RFC3629] and MAY support
   additional charsets to represent 'text' values, provided that the
   charsets are registered with IANA [IANA-CS].  See Section 5.1.8 for
   the definition of the 'charset' attribute syntax, including
   restricted semantics and examples of charsets.

5.1.2.2.  'textWithLanguage'

   The 'textWithLanguage' attribute syntax is a compound attribute
   syntax consisting of two parts: a 'textWithoutLanguage' part encoded
   in a maximum of 1023 (MAX) octets plus an additional
   'naturalLanguage' (see Section 5.1.9) part that overrides the natural
   language in force.  The 'naturalLanguage' part explicitly identifies

   the natural language that applies to the text part of that value and
   that value alone.  For any given 'text' attribute, the
   'textWithoutLanguage' part is limited to the maximum length defined
   for that 'text' attribute, and the 'naturalLanguage' part is always
   limited to 63 (additional) octets.  Using the 'textWithLanguage'
   attribute syntax rather than the normal 'textWithoutLanguage' syntax
   is the so-called "Natural Language Override mechanism" and MUST be
   supported by all IPP objects and Clients.

   If the attribute is multi-valued (1setOf text), then the
   'textWithLanguage' attribute syntax MUST be used to explicitly
   specify each attribute value whose natural language needs to be
   overridden.  Other values in a multi-valued 'text' attribute in a
   request or a response revert to the natural language of the operation
   attribute.

   In a Job Creation request, the Printer MUST accept and store with the
   Job any natural language in the "attributes-natural-language"
   operation attribute, whether the Printer supports that natural
   language or not.  Furthermore, the Printer MUST accept and store any
   'textWithLanguage' attribute value, whether the Printer supports that
   natural language or not.  These requirements are independent of the
   value of the "ipp-attribute-fidelity" operation attribute that the
   Client MAY supply.

   Example: If the Client supplies the "attributes-natural-language"
   operation attribute with the value 'en' indicating English but the
   value of the "job-name" attribute is in French, the Client MUST use
   the 'textWithLanguage' attribute syntax with the following two
   values:

      'fr': Natural Language Override indicating French

      'Rapport Mensuel': the Job name in French

   See the Encoding and Transport document [RFC8010] for the encoding of
   the two parts and a detailed example of the 'textWithLanguage'
   attribute syntax.

5.1.3.  'name'

   This syntax type is used for user-friendly strings, such as a Printer
   name, that, for humans, are more meaningful than identifiers.  Names
   are never translated from one natural language to another.  The
   'name' attribute syntax is essentially the same as 'text', including
   the REQUIRED support of UTF-8, except that the sequence of characters
   is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.

   Also, like 'text', 'name' is really an abbreviated notation for
   either 'nameWithoutLanguage' or 'nameWithLanguage'.  That is, all IPP
   objects and Clients MUST support both the 'nameWithoutLanguage' and
   'nameWithLanguage' attribute syntaxes.  However, in actual usage and
   protocol execution, IPP objects and Clients accept and return only
   one of the two syntaxes per attribute.  The syntax 'name' never
   appears "on-the-wire".

   Only the 'text' and 'name' attribute syntaxes permit the Natural
   Language Override mechanism.

   Some attributes are defined as 'type2 keyword | name'.  These
   attributes support values that are either type2 keywords or names.
   This dual-syntax mechanism enables a site Administrator to extend
   these attributes to legally include values that are locally defined
   by the site Administrator.  Such names are not registered with IANA.

5.1.3.1.  'nameWithoutLanguage'

   The 'nameWithoutLanguage' syntax indicates a value that is a sequence
   of zero or more characters encoded in a maximum of 255 (MAX) octets.

5.1.3.2.  'nameWithLanguage'

   The 'nameWithLanguage' attribute syntax is a compound attribute
   syntax consisting of two parts: a 'nameWithoutLanguage' (see
   Section 5.1.3.1) part plus an additional 'naturalLanguage' (see
   Section 5.1.9) part that overrides the natural language in force.
   The 'naturalLanguage' part explicitly identifies the natural language
   that applies to that name value and that name value alone.  For any
   given 'name' attribute, the 'nameWithoutLanguage' part is limited to
   the maximum length defined for that 'name' attribute, and the
   'naturalLanguage' part is always limited to 63 (additional) octets.
   Using the 'nameWithLanguage' attribute syntax rather than the normal
   'nameWithoutLanguage' syntax is the Natural Language Override
   mechanism and MUST be supported by all IPP objects and Clients.

   The 'nameWithLanguage' attribute syntax behaves the same as the
   'textWithLanguage' syntax.  If a name is in a language that is
   different than the rest of the object or operation, then this
   'nameWithLanguage' syntax is used rather than the generic
   'nameWithoutLanguage' syntax.

   If the attribute is multi-valued (1setOf name), then the
   'nameWithLanguage' attribute syntax MUST be used to explicitly
   specify each attribute value whose natural language needs to be

   overridden.  Other values in a multi-valued 'name' attribute in a
   request or a response revert to the natural language of the operation
   attribute.

   In a Job Creation request, the Printer MUST accept and store with the
   Job any natural language in the "attributes-natural-language"
   operation attribute, whether the Printer supports that natural
   language or not.  Furthermore, the Printer MUST accept and store any
   'nameWithLanguage' attribute value, whether the Printer supports that
   natural language or not.  These requirements are independent of the
   value of the "ipp-attribute-fidelity" operation attribute that the
   Client MAY supply.

   Example: If the Client supplies the "attributes-natural-language"
   operation attribute with the value 'en' indicating English but the
   "printer-name" attribute is in German, the Client MUST use the
   'nameWithLanguage' attribute syntax as follows:

      'de': Natural Language Override indicating German

      'Farbdrucker': the Printer name in German

   See the Encoding and Transport document [RFC8010] for the encoding of
   the two parts and a detailed example of the 'nameWithLanguage'
   attribute syntax.

5.1.3.3.  Matching 'name' Attribute Values

   For purposes of matching two 'name' attribute values for equality,
   such as in Job validation (where a Client-supplied value for
   attribute "xxx" is checked to see if the value is among the values of
   the Printer's corresponding "xxx-supported" attribute), the following
   match rules apply:

   1.  'keyword' values never match 'name' values.

   2.  'name' ('nameWithoutLanguage' and 'nameWithLanguage') values
       match if (1) the name parts match and (2) the Associated
       Natural Language parts (see Section 4.1.4.1) match.  The matching
       rules are as follows:

       2a.  The name parts match if the two names are identical
            character by character, except that it is RECOMMENDED that
            case be ignored as defined in "i;unicode-casemap - Simple
            Unicode Collation Algorithm" [RFC5051].  For example,
            'Ajax-letter-head-white' MUST match 'Ajax-letter-head-white'
            and SHOULD match 'ajax-letter-head-white' and
            'AJAX-LETTER-HEAD-WHITE'.

       2b.  The Associated Natural Language parts match if the shorter
            of the two meets the syntactic requirements defined in
            Section 2.1 of RFC 5646 [RFC5646] and matches (byte for
            byte, since IPP language tags are lowercase) with the
            longer.  For example, 'en' matches 'en', 'en-us', and
            'en-gb' but matches neither 'fr' nor 'e'.

5.1.4.  'keyword'

   The 'keyword' attribute syntax is a sequence of characters, of length
   1 to 255, containing only the US-ASCII [RFC20] encoded values for
   lowercase letters ("a"-"z"), digits ("0"-"9"), hyphen ("-"), dot
   ("."), and underscore ("_").  The first character MUST be a lowercase
   letter.  Furthermore, keywords MUST be in US English.

   This syntax type is used for enumerating semantic identifiers of
   entities in the abstract protocol, i.e., entities identified in this
   document.  Keywords are used as attribute names or values of
   attributes.  Unlike 'text' and 'name' attribute values, 'keyword'
   values MUST NOT use the Natural Language Override mechanism, since
   they MUST always be US-ASCII and US English.

   Keywords are for use in the protocol.  A user interface will likely
   provide a mapping between protocol keywords and displayable
   user-friendly words and phrases that are localized to the natural
   language of the user.  While the keywords specified in this document
   MAY be displayed to users whose natural language is US English, they
   MAY be mapped to other US English words for US English users, since
   the user interface is outside the scope of this document.

   In the definition for each attribute of this syntax type, the full
   set of 'keyword' values being defined for that attribute is listed.
   The IANA IPP registry will always contain the complete and current
   list of 'keyword' values for the attribute.

   When a keyword is used to represent an attribute (its name), it MUST
   be unique within the full scope of all IPP objects and attributes.
   When a keyword is used to represent a value of an attribute, it MUST
   be unique just within the scope of that attribute.  That is, the same
   keyword MUST NOT be used for two different values within the same
   attribute to mean two different semantic ideas.  However, the same
   keyword MAY be used across two or more attributes, representing

   different semantic ideas for each attribute.  Section 7.3 describes
   how the protocol can be extended with new 'keyword' values.  Examples
   of attribute name keywords are:

      "job-name"

      "attributes-charset"

   Note: This document uses "type1" and "type2" prefixes to the
   "keyword" basic syntax to indicate different levels of review for
   extensions (see Section 7.3).

5.1.5.  'enum'

   The 'enum' attribute syntax is an enumerated integer value that is in
   the range from 1 to 2**31 - 1 (MAX).  Each value has an associated
   'keyword' name.  In the definition for each attribute of this syntax
   type, the full set of possible values for that attribute is listed.
   This syntax type is used for attributes for which there are enum
   values assigned by other standards, such as SNMP MIBs.  A number of
   attribute enum values in this document are also used for
   corresponding attributes in other standards [RFC3805].  This syntax
   type is not used for attributes to which the Administrator can assign
   values.  Section 7.4 describes how the protocol can be extended with
   new enum values.

   Enum values are for use in the protocol.  A user interface will
   provide a mapping between protocol enum values and displayable
   user-friendly words and phrases that are localized to the natural
   language of the user.  While the enum symbols specified in this
   document MAY be displayed to users whose natural language is
   US English, they MAY be mapped to other US English words for
   US English users, since the user interface is outside the scope of
   this document.

   Note: Some SNMP MIBs use '2' for 'unknown', which corresponds to the
   IPP "out-of-band" value 'unknown'.  See the description of the
   "out-of-band" values at the beginning of Section 5.1.  Therefore,
   attributes of type 'enum' typically start at '3'.

   Note: This document uses "type1" and "type2" prefixes to the "enum"
   basic syntax to indicate different levels of review for extensions
   (see Section 7.4).

5.1.6.  'uri'

   The 'uri' attribute syntax is any valid Uniform Resource Identifier
   (URI) [RFC3986].  Most often, URIs are simply Uniform Resource
   Locators (URLs).  The maximum length of URIs used as values of IPP
   attributes is 1023 octets.  Although most other IPP attribute syntax
   types allow for only lowercase values, this attribute syntax type
   conforms to the case-sensitive and case-insensitive rules specified
   in [RFC3986].  See also [RFC3196] for a discussion of case in URIs.

5.1.7.  'uriScheme'

   The 'uriScheme' attribute syntax is a sequence of characters
   representing a URI scheme according to RFC 3986 [RFC3986].  Though
   RFC 3986 requires that the values be case insensitive, IPP requires
   all lowercase values in IPP attributes, to simplify comparing by IPP
   Clients and Printers.

   Standard values for this syntax type include the following keywords:

   o  'ipp': for IPP schemed URIs, e.g., "ipp://example.com/ipp/..."
      [RFC3510]

   o  'ipps': for IPPS schemed URIs, e.g., "ipps://example.com/ipp/..."
      [RFC7472]

   o  'http': for HTTP schemed URIs, e.g., "http://example.com/path/to/
      filename" [RFC7230]

   o  'https': for HTTPS schemed URIs, e.g.,
      "https://example.com/path/to/filename" [RFC7230]

   o  'ftp': for FTP schemed URIs, e.g., "ftp://example.com/path/to/
      filename" [RFC1738]

   o  'mailto': for SMTP schemed URIs, e.g., "mailto:user@example.com"
      [RFC6068]

   o  'file': for file schemed URIs, e.g., "file:///path/to/filename"
      [RFC1738]

   o  'urn': for Uniform Resource Name schemed URIs, e.g.,
      "urn:uuid:01234567-89ab-cdef-fedc-ba9876543210" [RFC4122]

   A Printer MAY support any URI 'scheme' that has been registered with
   IANA [IANA-MT].  The maximum length of URI 'scheme' values used to
   represent IPP attribute values is 63 octets.

5.1.8.  'charset'

   The 'charset' attribute syntax is a standard identifier for a
   charset.  A charset is a coded character set and encoding scheme.
   Charsets are used for labeling certain Document contents, 'text'
   attribute values, and 'name' attribute values.  The syntax and
   semantics of this attribute syntax are specified in RFC 2046
   [RFC2046] and contained in the IANA "Character Sets" registry
   [IANA-CS] according to the IANA procedures [RFC2978].  Though
   RFC 2046 requires that the values be case-insensitive US-ASCII
   [RFC20], IPP requires all lowercase values in IPP attributes, to
   simplify comparing by IPP Clients and Printers.  When a character set
   in the IANA registry has more than one name (alias), the name labeled
   as "(preferred MIME name)", if present, MUST be used.

   The maximum length of 'charset' values used to represent IPP
   attribute values is 63 octets.

   Some examples are:

   o  'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set
      (UCS) [ISO10646] represented as the UTF-8 [RFC3629] transfer
      encoding scheme in which US-ASCII [RFC20] is a subset charset.

   o  'us-ascii': 7-bit American Standard Code for Information
      Interchange (ASCII) [RFC20].

   o  'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet
      No. 1 [ISO8859-1].  That standard defines a coded character set
      that is used by Latin languages in the Western Hemisphere and
      Western Europe.  US-ASCII is a subset charset.

   Some attribute descriptions MAY place additional requirements on
   charset values that can be used, such as REQUIRED values that MUST be
   supported or additional restrictions, such as requiring that the
   charset have US-ASCII as a subset charset.

5.1.9.  'naturalLanguage'

   The 'naturalLanguage' attribute syntax is a standard identifier for a
   natural language and, optionally, a country or region.  The values
   for this syntax type are defined by RFC 5646 [RFC5646].  Though
   RFC 5646 requires that the values be case-insensitive US-ASCII, IPP
   requires all lowercase values in IPP attributes, to simplify
   comparing by IPP Clients and Printers.  Examples include:

   o  'en': for English

   o  'en-us': for US English

   o  'fr': for French

   o  'de': for German

   The maximum length of 'naturalLanguage' values used to represent IPP
   attribute values is 63 octets.

   Note: While any standard natural language identifier defined in
   RFC 5646 can be used, Clients typically only support a subset of
   these identifiers.  When comparing two identifiers or performing
   lookups, Printers SHOULD be prepared to match legacy identifiers with
   their corresponding modern equivalents and vice versa.

5.1.10.  'mimeMediaType'

   The 'mimeMediaType' attribute syntax is the Internet media type
   (sometimes called "MIME type") as defined by RFC 2046 [RFC2046] and
   registered according to the procedures of RFC 6838 [RFC6838] for
   identifying a Document format.  The value MAY include a charset
   parameter, or some other parameter, depending on the specification of
   the media type in the IANA "Media Types" registry [IANA-MT].
   Although most other IPP syntax types allow for only lowercase values,
   this syntax type allows for mixed-case values that are
   case insensitive.

   Examples are:

   o  'text/html': An HTML Document

   o  'text/plain': A plain text Document in US-ASCII (RFC 2046
      indicates that in the absence of the charset parameter MUST mean
      US-ASCII rather than simply unspecified) [RFC2046]

   o  'text/plain; charset = US-ASCII': A plain text Document in
      US-ASCII

   o  'text/plain; charset = ISO-8859-1': A plain text Document in
      ISO 8859-1 (Latin 1) [ISO8859-1]

   o  'text/plain; charset = utf-8': A plain text Document in ISO 10646
      represented as UTF-8 [RFC3629]

   o  'application/postscript': A PostScript Document [RFC2046]

   o  'application/vnd.hp-PCL': A PCL Document [IANA-MT] (charset escape
      sequence embedded in the Document data)

   o  'application/pdf': Portable Document Format [ISO32000]

   o  'application/octet-stream': Auto-sense - see Section 5.1.10.1

   The maximum length of a 'mimeMediaType' value to represent IPP
   attribute values is 255 octets.

5.1.10.1.  'application/octet-stream' - Auto-Sensing the Document Format

   One special type is 'application/octet-stream'.  If the Printer
   supports this value, the Printer MUST be capable of auto-sensing the
   format of the Document data using an implementation-dependent method
   that examines some number of octets of the Document data, either as
   part of the Job Creation request and/or at Document processing time.
   During auto-sensing, a Printer can determine that the Document data
   has a format that the Printer doesn't recognize.  If the Printer
   determines this problem before returning an operation response, it
   rejects the request and returns the
   'client-error-document-format-not-supported' status-code.  If the
   Printer determines this problem after accepting the request and
   returning an operation response with one of the successful
   status-code values, the Printer adds the
   'unsupported-document-format' value to the Job's "job-state-reasons"
   attribute.

   If the Printer's default value attribute "document-format-default" is
   set to 'application/octet-stream', the Printer not only supports
   auto-sensing of the Document format but will depend on the result of
   applying its auto-sensing when the Client does not supply the
   "document-format" attribute.  If the Client supplies a Document
   format value, the Printer MUST rely on the supplied attribute, rather
   than trust its auto-sensing algorithm.  To summarize:

   1.  If the Client does not supply a Document format value, the
       Printer MUST rely on its default value setting (which can be
       'application/octet-stream' indicating an auto-sensing mechanism).

   2.  If the Client supplies a value other than
       'application/octet-stream', the Client is supplying valid
       information about the format of the Document data and the Printer
       MUST trust the Client-supplied value more than the outcome of
       applying an automatic format detection mechanism.  For example,
       the Client can request the printing of a PostScript file as a
       'text/plain' Document.  The Printer MUST print a text
       representation of the PostScript commands rather than interpret
       the stream of PostScript commands and print the result.

   3.  If the Client supplies a value of 'application/octet-stream', the
       Client is indicating that the Printer MUST use its auto-sensing
       mechanism on the Client-supplied Document data whether
       auto-sensing is the Printer's default or not.

   Note: Since the auto-sensing algorithm is probabilistic, if the
   Client requests both auto-sensing ("document-format" set to
   'application/octet-stream') and true fidelity
   ("ipp-attribute-fidelity" set to 'true'), the Printer might not be
   able to guarantee exactly what the End User intended (the
   auto-sensing algorithm might mistake one Document format for
   another), but it is able to guarantee that its auto-sensing mechanism
   will be used.

5.1.11.  'octetString'

   The 'octetString' attribute syntax is a sequence of octets encoded in
   a maximum of 1023 octets that is indicated in syntax definitions
   using the notation 'octetString(MAX)'.  This syntax type is used for
   opaque data.

5.1.12.  'boolean'

   The 'boolean' attribute syntax has only two values: 'true' and
   'false'.

5.1.13.  'integer'

   The 'integer' attribute syntax is an integer value that is in the
   range from -2**31 (MIN) to 2**31 - 1 (MAX).  Each individual
   attribute can specify the range constraint explicitly if the range is
   different from the full range of possible integer values -- for
   example, job-priority (integer(1:100)) for the "job-priority"
   attribute, as shown in the title of Section 5.2.1.  However, the
   enforcement of that additional constraint is up to the IPP objects,
   not the protocol.

5.1.14.  'rangeOfInteger'

   The 'rangeOfInteger' attribute syntax is an ordered pair of integers
   that defines an inclusive range of integer values.  The first integer
   specifies the lower bound, and the second specifies the upper bound.
   If a range constraint is specified in the attribute definition, i.e.,
   'rangeOfInteger(X:Y)' indicating X as a minimum value and Y as a
   maximum value, then the constraint applies to both integers.

5.1.15.  'dateTime'

   The 'dateTime' attribute syntax is a standard, fixed-length, 11-octet
   representation of the "DateAndTime" syntax as defined in RFC 2579
   [RFC2579].  RFC 2579 also identifies an 8-octet representation of a
   "DateAndTime" value, but IPP objects MUST use the 11-octet
   representation.  A user interface will provide a mapping between
   protocol dateTime values and displayable user-friendly words or
   presentation values and phrases that are localized to the natural
   language and date format of the user, including time zone.

5.1.16.  'resolution'

   The 'resolution' attribute syntax specifies a two-dimensional
   resolution in the indicated units.  It consists of three values: a
   cross-feed direction resolution (positive integer value), a feed
   direction resolution (positive integer value), and a units value.
   The semantics of these three components are taken from the suggested
   values in the Printer MIB [RFC3805].  That is, the cross-feed
   direction resolution component is the same as the
   prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed
   direction resolution component is the same as the
   prtMarkerAddressabilityFeedDir in the Printer MIB, and the units
   component is the same as the prtMarkerAddressabilityUnit object in
   the Printer MIB (namely, '3' indicates dots per inch and '4'
   indicates dots per centimeter).  All three values MUST be present
   even if the first two values are the same.  For example, '300',
   '600', '3' indicates a 300-dpi cross-feed direction resolution and a
   600-dpi feed direction resolution, since a '3' indicates dots per
   inch (dpi).

5.1.17.  'collection'

   The 'collection' attribute syntax is a container holding one or more
   named values (i.e., attributes), which are called "member
   attributes".  Each 'collection' attribute definition Document lists
   the mandatory and optional member attributes of each collection
   value.  A collection value is similar to an IPP attribute group in a

   request or a response, such as the Operation Attributes group -- they
   both consist of a set of attributes.  Collections can also be nested,
   i.e., a collection in a collection.

   A collection value consists of three separate components:

   o  A 'begCollection' value with an optional octet string value
      starting the collection,

   o  Zero or more member attributes defined using a series of unnamed
      values starting with a 'memberAttrName' value that specifies the
      member attribute name, and

   o  An 'endCollection' value with an optional name plus octet string
      value finishing the collection.

5.1.18.  '1setOf X'

   The '1setOf X' attribute syntax is one or more values of attribute
   syntax type X.  This syntax type is used for multi-valued attributes.
   The syntax type is called '1setOf' rather than just 'setOf' as a
   reminder that the set of values MUST NOT be empty (i.e., a set of
   size 0).  Sets are normally unordered; however, each attribute
   description of this type can specify that the values MUST be in a
   certain order for that attribute.