Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8011

Internet Printing Protocol/1.1: Model and Semantics

Pages: 221
Internet Standard: 92
Errata
Obsoletes:  291133813382
Part 6 of 12 – Pages 92 to 106
First   Prev   Next

Top   ToC   RFC8011 - Page 92   prevText

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].
Top   ToC   RFC8011 - Page 93
   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.
Top   ToC   RFC8011 - Page 94
   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
Top   ToC   RFC8011 - Page 95
   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.
Top   ToC   RFC8011 - Page 96
   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
Top   ToC   RFC8011 - Page 97
   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'.
Top   ToC   RFC8011 - Page 98
       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
Top   ToC   RFC8011 - Page 99
   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).
Top   ToC   RFC8011 - Page 100

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.
Top   ToC   RFC8011 - Page 101

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.
Top   ToC   RFC8011 - Page 102

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
Top   ToC   RFC8011 - Page 103
   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).
Top   ToC   RFC8011 - Page 104
   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.
Top   ToC   RFC8011 - Page 105

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
Top   ToC   RFC8011 - Page 106
   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.


(page 106 continued on part 7)

Next Section