RFC2911 日本語訳
2911 Internet Printing Protocol/1.1: Model and Semantics. T. Hastings,Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell. September 2000. (Format: TXT=575805 bytes) (Obsoletes RFC2566) (Updated by RFC3380, RFC3382, RFC3996, RFC3995) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hastings, Editor
Request for Comments: 2911 R. Herriot
Obsoletes: 2566 Xerox Corporation
Category: Standards Track R. deBry
Utah Valley State College
S. Isaacson
Novell, Inc.
P. Powell
Astart Technologies
September 2000
Network Working Group T. Hastings, Editor Request for Comments: 2911 R. Herriot Obsoletes: 2566 Xerox Corporation Category: Standards Track R. deBry Utah Valley State College S. Isaacson Novell, Inc. P. Powell Astart Technologies September 2000
Internet Printing Protocol/1.1: Model and Semantics
Internet Printing Protocol/1.1: Model and Semantics
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Abstract
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. This document also addresses security, internationalization, and directory issues.
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. This document also addresses security, internationalization, and directory issues.
Hastings, et al. Standards Track [Page 1] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 1] RFC 2911 IPP/1.1: Model and Semantics September 2000
The full set of IPP documents includes:
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics (this document)
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [RFC2569]
Design Goals for an Internet Printing Protocol [RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568] Internet Printing Protocol/1.1: Model and Semantics (this document) Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG] Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1.
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
Hastings, et al. Standards Track [Page 2] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 2] RFC 2911 IPP/1.1: Model and Semantics September 2000
Table of Contents
Table of Contents
1. Introduction 9 1.1 Simplified Printing Model 10 2. IPP Objects 12 2.1 Printer Object 13 2.2 Job Object 15 2.3 Object Relationships 16 2.4 Object Identity 17 3. IPP Operations 20 3.1 Common Semantics 21 3.1.1 Required Parameters 21 3.1.2 Operation IDs and Request IDs 22 3.1.3 Attributes 22 3.1.4 Character Set and Natural Language Operation Attribute 24 3.1.4.1 Request Operation Attributes 25 3.1.4.2 Response Operation Attributes 29 3.1.5 Operation Targets 30 3.1.6 Operation Response Status Codes and Status Messages 32 3.1.6.1 "status-code" (type2 enum) 32 3.1.6.2 "status-message" (text(255)) 33 3.1.6.3 "detailed-status-message" (text(MAX)) 33 3.1.6.4 "document-access-error" (text(MAX)) 34 3.1.7 Unsupported Attributes 34 3.1.8 Versions 36 3.1.9 Job Creation Operations 38 3.2 Printer Operations 41 3.2.1 Print-Job Operation 41 3.2.1.1 Print-Job Request 41 3.2.1.2 Print-Job Response 46 3.2.2 Print-URI Operation 48 3.2.3 Validate-Job Operation 49 3.2.4 Create-Job Operation 49 3.2.5 Get-Printer-Attributes Operation 50 3.2.5.1 Get-Printer-Attributes Request 51 3.2.5.2 Get-Printer-Attributes Response 53 3.2.6 Get-Jobs Operation 54 3.2.6.1 Get-Jobs Request 54 3.2.6.2 Get-Jobs Response 56 3.2.7 Pause-Printer Operation 57 3.2.7.1 Pause-Printer Request 59 3.2.7.2 Pause-Printer Response 60 3.2.8 Resume-Printer Operation 60 3.2.9 Purge-Jobs Operation 61 3.3 Job Operations 62 3.3.1 Send-Document Operation 62 3.3.1.1 Send-Document Request 64 3.3.1.2 Send-Document Response 65
1. Introduction 9 1.1 Simplified Printing Model 10 2. IPP Objects 12 2.1 Printer Object 13 2.2 Job Object 15 2.3 Object Relationships 16 2.4 Object Identity 17 3. IPP Operations 20 3.1 Common Semantics 21 3.1.1 Required Parameters 21 3.1.2 Operation IDs and Request IDs 22 3.1.3 Attributes 22 3.1.4 Character Set and Natural Language Operation Attribute 24 3.1.4.1 Request Operation Attributes 25 3.1.4.2 Response Operation Attributes 29 3.1.5 Operation Targets 30 3.1.6 Operation Response Status Codes and Status Messages 32 3.1.6.1 "status-code" (type2 enum) 32 3.1.6.2 "status-message" (text(255)) 33 3.1.6.3 "detailed-status-message" (text(MAX)) 33 3.1.6.4 "document-access-error" (text(MAX)) 34 3.1.7 Unsupported Attributes 34 3.1.8 Versions 36 3.1.9 Job Creation Operations 38 3.2 Printer Operations 41 3.2.1 Print-Job Operation 41 3.2.1.1 Print-Job Request 41 3.2.1.2 Print-Job Response 46 3.2.2 Print-URI Operation 48 3.2.3 Validate-Job Operation 49 3.2.4 Create-Job Operation 49 3.2.5 Get-Printer-Attributes Operation 50 3.2.5.1 Get-Printer-Attributes Request 51 3.2.5.2 Get-Printer-Attributes Response 53 3.2.6 Get-Jobs Operation 54 3.2.6.1 Get-Jobs Request 54 3.2.6.2 Get-Jobs Response 56 3.2.7 Pause-Printer Operation 57 3.2.7.1 Pause-Printer Request 59 3.2.7.2 Pause-Printer Response 60 3.2.8 Resume-Printer Operation 60 3.2.9 Purge-Jobs Operation 61 3.3 Job Operations 62 3.3.1 Send-Document Operation 62 3.3.1.1 Send-Document Request 64 3.3.1.2 Send-Document Response 65
Hastings, et al. Standards Track [Page 3] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 3] RFC 2911 IPP/1.1: Model and Semantics September 2000
3.3.2 Send-URI Operation 66
3.3.3 Cancel-Job Operation 66
3.3.3.1 Cancel-Job Request 67
3.3.3.2 Cancel-Job Response 68
3.3.4 Get-Job-Attributes Operation 69
3.3.4.1 Get-Job-Attributes Request 69
3.3.4.2 Get-Job-Attributes Response 70
3.3.5 Hold-Job Operation 71
3.3.5.1 Hold-Job Request 72
3.3.5.2 Hold-Job Response 73
3.3.6 Release-Job Operation 74
3.3.7 Restart-Job Operation 75
3.3.7.1 Restart-Job Request 76
3.3.7.2 Restart-Job Response 78
4. Object Attributes 78
4.1 Attribute Syntaxes 78
4.1.1 'text' 79
4.1.1.1 'textWithoutLanguage' 80
4.1.1.2 'textWithLanguage' 80
4.1.2 'name' 81
4.1.2.1 'nameWithoutLanguage' 82
4.1.2.2 'nameWithLanguage' 82
4.1.2.3 Matching 'name' attribute values 83
4.1.3 'keyword' 84
4.1.4 'enum' 85
4.1.5 'uri' 85
4.1.6 'uriScheme' 86
4.1.7 'charset' 86
4.1.8 'naturalLanguage' 87
4.1.9 'mimeMediaType' 87
4.1.9.1 Application/octet-stream -- Auto-Sensing 88
the document format
4.1.10 'octetString' 89
4.1.11 'boolean' 89
4.1.12 'integer' 89
4.1.13 'rangeOfInteger' 90
4.1.14 'dateTime' 90
4.1.15 'resolution' 90
4.1.16 '1setOf X' 90
4.2 Job Template Attributes 91
4.2.1 job-priority (integer(1:100)) 94
4.2.2 job-hold-until (type3 keyword | name (MAX)) 95
4.2.3 job-sheets (type3 keyword | name(MAX)) 96
4.2.4 multiple-document-handling (type2 keyword) 96
4.2.5 copies (integer(1:MAX)) 98
4.2.6 finishings (1setOf type2 enum) 98
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 101
4.2.8 sides (type2 keyword) 102
3.3.2 Send-URI Operation 66 3.3.3 Cancel-Job Operation 66 3.3.3.1 Cancel-Job Request 67 3.3.3.2 Cancel-Job Response 68 3.3.4 Get-Job-Attributes Operation 69 3.3.4.1 Get-Job-Attributes Request 69 3.3.4.2 Get-Job-Attributes Response 70 3.3.5 Hold-Job Operation 71 3.3.5.1 Hold-Job Request 72 3.3.5.2 Hold-Job Response 73 3.3.6 Release-Job Operation 74 3.3.7 Restart-Job Operation 75 3.3.7.1 Restart-Job Request 76 3.3.7.2 Restart-Job Response 78 4. Object Attributes 78 4.1 Attribute Syntaxes 78 4.1.1 'text' 79 4.1.1.1 'textWithoutLanguage' 80 4.1.1.2 'textWithLanguage' 80 4.1.2 'name' 81 4.1.2.1 'nameWithoutLanguage' 82 4.1.2.2 'nameWithLanguage' 82 4.1.2.3 Matching 'name' attribute values 83 4.1.3 'keyword' 84 4.1.4 'enum' 85 4.1.5 'uri' 85 4.1.6 'uriScheme' 86 4.1.7 'charset' 86 4.1.8 'naturalLanguage' 87 4.1.9 'mimeMediaType' 87 4.1.9.1 Application/octet-stream -- Auto-Sensing 88 the document format 4.1.10 'octetString' 89 4.1.11 'boolean' 89 4.1.12 'integer' 89 4.1.13 'rangeOfInteger' 90 4.1.14 'dateTime' 90 4.1.15 'resolution' 90 4.1.16 '1setOf X' 90 4.2 Job Template Attributes 91 4.2.1 job-priority (integer(1:100)) 94 4.2.2 job-hold-until (type3 keyword | name (MAX)) 95 4.2.3 job-sheets (type3 keyword | name(MAX)) 96 4.2.4 multiple-document-handling (type2 keyword) 96 4.2.5 copies (integer(1:MAX)) 98 4.2.6 finishings (1setOf type2 enum) 98 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 101 4.2.8 sides (type2 keyword) 102
Hastings, et al. Standards Track [Page 4] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 4] RFC 2911 IPP/1.1: Model and Semantics September 2000
4.2.9 number-up (integer(1:MAX)) 102 4.2.10 orientation-requested (type2 enum) 103 4.2.11 media (type3 keyword | name(MAX)) 104 4.2.12 printer-resolution (resolution) 105 4.2.13 print-quality (type2 enum) 105 4.3 Job Description Attributes 106 4.3.1 job-uri (uri) 107 4.3.2 job-id (integer(1:MAX)) 108 4.3.3 job-printer-uri (uri) 108 4.3.4 job-more-info (uri) 108 4.3.5 job-name (name(MAX)) 108 4.3.6 job-originating-user-name (name(MAX)) 109 4.3.7 job-state (type1 enum) 109 4.3.7.1 Forwarding Servers 112 4.3.7.2 Partitioning of Job States 112 4.3.8 job-state-reasons (1setOf type2 keyword) 113 4.3.9 job-state-message (text(MAX)) 118 4.3.10 job-detailed-status-messages (1setOf text(MAX)) 118 4.3.11 job-document-access-errors (1setOf text(MAX)) 118 4.3.12 number-of-documents (integer(0:MAX)) 119 4.3.13 output-device-assigned (name(127)) 119 4.3.14 Event Time Job Description Attributes 119 4.3.14.1 time-at-creation (integer(MIN:MAX)) 120 4.3.14.2 time-at-processing (integer(MIN:MAX)) 120 4.3.14.3 time-at-completed (integer(MIN:MAX)) 120 4.3.14.4 job-printer-up-time (integer(1:MAX)) 120 4.3.14.5 date-time-at-creation (dateTime) 121 4.3.14.6 date-time-at-processing (dateTime) 121 4.3.14.7 date-time-at-completed (dateTime) 121 4.3.15 number-of-intervening-jobs (integer(0:MAX)) 121 4.3.16 job-message-from-operator (text(127)) 121 4.3.17 Job Size Attributes 121 4.3.17.1 job-k-octets (integer(0:MAX)) 122 4.3.17.2 job-impressions (integer(0:MAX)) 122 4.3.17.3 job-media-sheets (integer(0:MAX)) 123 4.3.18 Job Progress Attributes 123 4.3.18.1 job-k-octets-processed (integer(0:MAX)) 123 4.3.18.2 job-impressions-completed (integer(0:MAX)) 123 4.3.18.3 job-media-sheets-completed (integer(0:MAX)) 124 4.3.19 attributes-charset (charset) 124 4.3.20 attributes-natural-language (naturalLanguage) 124 4.4 Printer Description Attributes 124 4.4.1 printer-uri-supported (1setOf uri) 126 4.4.2 uri-authentication-supported (1setOf type2 keyword) 127 4.4.3 uri-security-supported (1setOf type2 keyword) 128 4.4.4 printer-name (name(127)) 129 4.4.5 printer-location (text(127)) 129 4.4.6 printer-info (text(127)) 130
4.2.9 number-up (integer(1:MAX)) 102 4.2.10 orientation-requested (type2 enum) 103 4.2.11 media (type3 keyword | name(MAX)) 104 4.2.12 printer-resolution (resolution) 105 4.2.13 print-quality (type2 enum) 105 4.3 Job Description Attributes 106 4.3.1 job-uri (uri) 107 4.3.2 job-id (integer(1:MAX)) 108 4.3.3 job-printer-uri (uri) 108 4.3.4 job-more-info (uri) 108 4.3.5 job-name (name(MAX)) 108 4.3.6 job-originating-user-name (name(MAX)) 109 4.3.7 job-state (type1 enum) 109 4.3.7.1 Forwarding Servers 112 4.3.7.2 Partitioning of Job States 112 4.3.8 job-state-reasons (1setOf type2 keyword) 113 4.3.9 job-state-message (text(MAX)) 118 4.3.10 job-detailed-status-messages (1setOf text(MAX)) 118 4.3.11 job-document-access-errors (1setOf text(MAX)) 118 4.3.12 number-of-documents (integer(0:MAX)) 119 4.3.13 output-device-assigned (name(127)) 119 4.3.14 Event Time Job Description Attributes 119 4.3.14.1 time-at-creation (integer(MIN:MAX)) 120 4.3.14.2 time-at-processing (integer(MIN:MAX)) 120 4.3.14.3 time-at-completed (integer(MIN:MAX)) 120 4.3.14.4 job-printer-up-time (integer(1:MAX)) 120 4.3.14.5 date-time-at-creation (dateTime) 121 4.3.14.6 date-time-at-processing (dateTime) 121 4.3.14.7 date-time-at-completed (dateTime) 121 4.3.15 number-of-intervening-jobs (integer(0:MAX)) 121 4.3.16 job-message-from-operator (text(127)) 121 4.3.17 Job Size Attributes 121 4.3.17.1 job-k-octets (integer(0:MAX)) 122 4.3.17.2 job-impressions (integer(0:MAX)) 122 4.3.17.3 job-media-sheets (integer(0:MAX)) 123 4.3.18 Job Progress Attributes 123 4.3.18.1 job-k-octets-processed (integer(0:MAX)) 123 4.3.18.2 job-impressions-completed (integer(0:MAX)) 123 4.3.18.3 job-media-sheets-completed (integer(0:MAX)) 124 4.3.19 attributes-charset (charset) 124 4.3.20 attributes-natural-language (naturalLanguage) 124 4.4 Printer Description Attributes 124 4.4.1 printer-uri-supported (1setOf uri) 126 4.4.2 uri-authentication-supported (1setOf type2 keyword) 127 4.4.3 uri-security-supported (1setOf type2 keyword) 128 4.4.4 printer-name (name(127)) 129 4.4.5 printer-location (text(127)) 129 4.4.6 printer-info (text(127)) 130
Hastings, et al. Standards Track [Page 5] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 5] RFC 2911 IPP/1.1: Model and Semantics September 2000
4.4.7 printer-more-info (uri) 130
4.4.8 printer-driver-installer (uri) 130
4.4.9 printer-make-and-model (text(127)) 130
4.4.10 printer-more-info-manufacturer (uri) 130
4.4.11 printer-state (type1 enum) 131
4.4.12 printer-state-reasons (1setOf type2 keyword) 131
4.4.13 printer-state-message (text(MAX)) 134
4.4.14 ipp-versions-supported (1setOf type2 keyword) 134
4.4.15 operations-supported (1setOf type2 enum) 135
4.4.16 multiple-document-jobs-supported (boolean) 136
4.4.17 charset-configured (charset) 136
4.4.18 charset-supported (1setOf charset) 137
4.4.19 natural-language-configured (naturalLanguage) 137
4.4.20 generated-natural-language-supported
(1setOf naturalLanguage) 137
4.4.21 document-format-default (mimeMediaType) 138
4.4.22 document-format-supported (1setOf mimeMediaType) 138
4.4.23 printer-is-accepting-jobs (boolean) 138
4.4.24 queued-job-count (integer(0:MAX)) 138
4.4.25 printer-message-from-operator (text(127)) 139
4.4.26 color-supported (boolean) 139
4.4.27 reference-uri-schemes-supported (1setOf uriScheme) 139
4.4.28 pdl-override-supported (type2 keyword) 139
4.4.29 printer-up-time (integer(1:MAX)) 140
4.4.30 printer-current-time (dateTime) 140
4.4.31 multiple-operation-time-out (integer(1:MAX)) 141
4.4.32 compression-supported (1setOf type3 keyword) 141
4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX)) 142
4.4.34 job-impressions-supported (rangeOfInteger(0:MAX)) 142
4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX)) 142
4.4.36 pages-per-minute (integer(0:MAX)) 142
4.4.37 pages-per-minute-color (integer(0:MAX)) 142
5. Conformance 143
5.1 Client Conformance Requirements 143
5.2 IPP Object Conformance Requirements 145
5.2.1 Objects 145
5.2.2 Operations 145
5.2.3 IPP Object Attributes 146
5.2.4 Versions 146
5.2.5 Extensions 147
5.2.6 Attribute Syntaxes 147
5.2.7 Security 148
5.3 Charset and Natural Language Requirements 148
6. IANA Considerations 148
6.1 Typed 'keyword' and 'enum' Extensions 149
6.2 Attribute Extensibility 151
6.3 Attribute Syntax Extensibility 152
6.4 Operation Extensibility 152
4.4.7 printer-more-info (uri) 130 4.4.8 printer-driver-installer (uri) 130 4.4.9 printer-make-and-model (text(127)) 130 4.4.10 printer-more-info-manufacturer (uri) 130 4.4.11 printer-state (type1 enum) 131 4.4.12 printer-state-reasons (1setOf type2 keyword) 131 4.4.13 printer-state-message (text(MAX)) 134 4.4.14 ipp-versions-supported (1setOf type2 keyword) 134 4.4.15 operations-supported (1setOf type2 enum) 135 4.4.16 multiple-document-jobs-supported (boolean) 136 4.4.17 charset-configured (charset) 136 4.4.18 charset-supported (1setOf charset) 137 4.4.19 natural-language-configured (naturalLanguage) 137 4.4.20 generated-natural-language-supported (1setOf naturalLanguage) 137 4.4.21 document-format-default (mimeMediaType) 138 4.4.22 document-format-supported (1setOf mimeMediaType) 138 4.4.23 printer-is-accepting-jobs (boolean) 138 4.4.24 queued-job-count (integer(0:MAX)) 138 4.4.25 printer-message-from-operator (text(127)) 139 4.4.26 color-supported (boolean) 139 4.4.27 reference-uri-schemes-supported (1setOf uriScheme) 139 4.4.28 pdl-override-supported (type2 keyword) 139 4.4.29 printer-up-time (integer(1:MAX)) 140 4.4.30 printer-current-time (dateTime) 140 4.4.31 multiple-operation-time-out (integer(1:MAX)) 141 4.4.32 compression-supported (1setOf type3 keyword) 141 4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX)) 142 4.4.34 job-impressions-supported (rangeOfInteger(0:MAX)) 142 4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX)) 142 4.4.36 pages-per-minute (integer(0:MAX)) 142 4.4.37 pages-per-minute-color (integer(0:MAX)) 142 5. Conformance 143 5.1 Client Conformance Requirements 143 5.2 IPP Object Conformance Requirements 145 5.2.1 Objects 145 5.2.2 Operations 145 5.2.3 IPP Object Attributes 146 5.2.4 Versions 146 5.2.5 Extensions 147 5.2.6 Attribute Syntaxes 147 5.2.7 Security 148 5.3 Charset and Natural Language Requirements 148 6. IANA Considerations 148 6.1 Typed 'keyword' and 'enum' Extensions 149 6.2 Attribute Extensibility 151 6.3 Attribute Syntax Extensibility 152 6.4 Operation Extensibility 152
Hastings, et al. Standards Track [Page 6] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 6] RFC 2911 IPP/1.1: Model and Semantics September 2000
6.5 Attribute Group Extensibility 153
6.6 Status Code Extensibility 153
6.7 Out-of-band Attribute Value Extensibility 154
6.8 Registration of MIME types/sub-types for document-formats 154
6.9 Registration of charsets for use in 'charset'
attribute values 154
7. Internationalization Considerations 154
8. Security Considerations 158
8.1 Security Scenarios 159
8.1.1 Client and Server in the Same Security Domain 159
8.1.2 Client and Server in Different Security Domains 159
8.1.3 Print by Reference 160
8.2 URIs in Operation, Job, and Printer attributes 160
8.3 URIs for each authentication mechanisms 160
8.4 Restricted Queries 161
8.5 Operations performed by operators and system
administrators 161
8.6 Queries on jobs submitted using non-IPP protocols 162
9. References 162
10. Authors' Addresses 166
11. Formats for IPP Registration Proposals 168
11.1 Type2 keyword attribute values registration 169
11.2 Type3 keyword attribute values registration 169
11.3 Type2 enum attribute values registration 169
11.4 Type3 enum attribute values registration 170
11.5 Attribute registration 170
11.6 Attribute Syntax registration 171
11.7 Operation registration 171
11.8 Attribute Group registration 171
11.9 Status code registration 172
11.10 Out-of-band Attribute Value registration 172
12. APPENDIX A: Terminology 173
12.1 Conformance Terminology 173
12.1.1 NEED NOT 173
12.2 Model Terminology 173
12.2.1 Keyword 173
12.2.2 Attributes 173
12.2.2.1 Attribute Name 173
12.2.2.2 Attribute Group Name 174
12.2.2.3 Attribute Value 174
12.2.2.4 Attribute Syntax 174
12.2.3 Supports 174
12.2.4 print-stream page 176
12.2.5 impression 177
13. APPENDIX B: Status Codes and Suggested Status Code Messages 177
13.1 Status Codes 178
13.1.1 Informational 178
13.1.2 Successful Status Codes 178
6.5 Attribute Group Extensibility 153 6.6 Status Code Extensibility 153 6.7 Out-of-band Attribute Value Extensibility 154 6.8 Registration of MIME types/sub-types for document-formats 154 6.9 Registration of charsets for use in 'charset' attribute values 154 7. Internationalization Considerations 154 8. Security Considerations 158 8.1 Security Scenarios 159 8.1.1 Client and Server in the Same Security Domain 159 8.1.2 Client and Server in Different Security Domains 159 8.1.3 Print by Reference 160 8.2 URIs in Operation, Job, and Printer attributes 160 8.3 URIs for each authentication mechanisms 160 8.4 Restricted Queries 161 8.5 Operations performed by operators and system administrators 161 8.6 Queries on jobs submitted using non-IPP protocols 162 9. References 162 10. Authors' Addresses 166 11. Formats for IPP Registration Proposals 168 11.1 Type2 keyword attribute values registration 169 11.2 Type3 keyword attribute values registration 169 11.3 Type2 enum attribute values registration 169 11.4 Type3 enum attribute values registration 170 11.5 Attribute registration 170 11.6 Attribute Syntax registration 171 11.7 Operation registration 171 11.8 Attribute Group registration 171 11.9 Status code registration 172 11.10 Out-of-band Attribute Value registration 172 12. APPENDIX A: Terminology 173 12.1 Conformance Terminology 173 12.1.1 NEED NOT 173 12.2 Model Terminology 173 12.2.1 Keyword 173 12.2.2 Attributes 173 12.2.2.1 Attribute Name 173 12.2.2.2 Attribute Group Name 174 12.2.2.3 Attribute Value 174 12.2.2.4 Attribute Syntax 174 12.2.3 Supports 174 12.2.4 print-stream page 176 12.2.5 impression 177 13. APPENDIX B: Status Codes and Suggested Status Code Messages 177 13.1 Status Codes 178 13.1.1 Informational 178 13.1.2 Successful Status Codes 178
Hastings, et al. Standards Track [Page 7] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 7] RFC 2911 IPP/1.1: Model and Semantics September 2000
13.1.2.1 successful-ok (0x0000) 178
13.1.2.2 successful-ok-ignored-or-substituted-attributes
(0x0001) 179
13.1.2.3 successful-ok-conflicting-attributes (0x0002) 179
13.1.3 Redirection Status Codes 179
13.1.4 Client Error Status Codes 179
13.1.4.1 client-error-bad-request (0x0400) 180
13.1.4.2 client-error-forbidden (0x0401) 180
13.1.4.3 client-error-not-authenticated (0x0402) 180
13.1.4.4 client-error-not-authorized (0x0403) 180
13.1.4.5 client-error-not-possible (0x0404) 180
13.1.4.6 client-error-timeout (0x0405) 181
13.1.4.7 client-error-not-found (0x0406) 181
13.1.4.8 client-error-gone (0x0407) 181
13.1.4.9 client-error-request-entity-too-large (0x0408) 182
13.1.4.10 client-error-request-value-too-long (0x0409) 182
13.1.4.11 client-error-document-format-not-supported (0x040A) 182
13.1.4.12 client-error-attributes-or-values-not-supported
(0x040B) 183
13.1.4.13 client-error-uri-scheme-not-supported (0x040C) 183
13.1.4.14 client-error-charset-not-supported (0x040D) 183
13.1.4.15 client-error-conflicting-attributes (0x040E) 183
13.1.4.16 client-error-compression-not-supported (0x040F) 184
13.1.4.17 client-error-compression-error (0x0410) 184
13.1.4.18 client-error-document-format-error (0x0411) 184
13.1.4.19 client-error-document-access-error (0x0412) 184
13.1.5 Server Error Status Codes 185
13.1.5.1 server-error-internal-error (0x0500) 185
13.1.5.2 server-error-operation-not-supported (0x0501) 185
13.1.5.3 server-error-service-unavailable (0x0502) 185
13.1.5.4 server-error-version-not-supported (0x0503) 185
13.1.5.5 server-error-device-error (0x0504) 186
13.1.5.6 server-error-temporary-error (0x0505) 186
13.1.5.7 server-error-not-accepting-jobs (0x0506) 187
13.1.5.8 server-error-busy (0x0507) 187
13.1.5.9 server-error-job-canceled (0x0508) 187
13.1.5.10 server-error-multiple-document-jobs-not-supported
(0x0509) 187
13.2 Status Codes for IPP Operations 187
14. APPENDIX C: "media" keyword values 190
15. APPENDIX D: Processing IPP Attributes 208
15.1 Fidelity 209
15.2 Page Description Language (PDL) Override 210
15.3 Using Job Template Attributes During Document Processing 212
16. APPENDIX E: Generic Directory Schema 214
17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1
"Model and Semantics" Documents 215
18. Full Copyright Statement 224
13.1.2.1 Redirection Status Codes179 13.1うまくいっているOK(0×0000)178 13.1.2.2うまくいっている間違いない無視されたか代入された属性(0×0001)179 13.1.2.3うまくいっている間違いない闘争属性(0×0002)179 13.1.3.4Client Error Status Codes、179、13.1、.4; 1つのクライアントの誤りの悪い要求(0×0400)180 13.1.4禁じられた.2クライアント誤り(0×0401)180 13.1.4誤りが認証しなかった.3クライアント(0×0402)180 13.1.4誤りが権限を与えなかった.4クライアント(0×0403)180 13.1.4可能でない.5クライアント誤り(0×0404)180 13.1.4.6クライアント誤りタイムアウト(0×0405)、181、13; 1.4.7 誤りが当たらなかったクライアント(0×0406)181 13.1、.4、.8、クライアント誤り過ぎ去る、クライアント誤りが大き過ぎる状態で実体を要求している(0×0407)181の.4.4.14charsetがサポートしなかったクライアント誤り(0x040D)183 13.1.4.9(0×0408)182 13.1.4.10クライアント誤り要求価値も切望している(0×0409)182 13.1.4形式が支えなかった.11クライアント誤りドキュメント(0x040A)182 13.1属性か値がサポートしなかった.12クライアント誤り(0x040B)183 13.1uri体系がサポートしなかった.13クライアント誤り(0x040C)183 13.1.4 13.1、.4、.15クライアント誤りconflicting-属性(0x040E)183 13.1.4圧縮がサポートしなかった.16クライアント誤り(0x040F)184 13.1.4.17クライアント誤り圧縮誤り(0×0410)184 13.1.4.18クライアント誤りドキュメント形式誤り(0×0411)184 13.1.4.19クライアント誤りドキュメントアクセスエラー(0×0412)184 13.1.5Server Error Status Codes185 13.1.5.1サーバ誤り内部エラー(0×0500)185 13.1.5操作がサポートしなかった.2サーバ誤り(0×0501)185 13.1.5.3入手できないサーバ誤りサービス(0×0502)、185、13; IPP Operationsのための(0×0507)187 13.1.5中止された.9サーバ誤り仕事(0×0508)の187 13.1.5複数のドキュメント仕事がサポートしなかった.10サーバ誤り(0×0509)187 13.2 1.5.4 誤りが忙しくする誤りバージョンがサポートしなかったサーバ(0×0503)185 13.1.5.5サーバ誤りデバイス誤り(0×0504)186 13.1.5.6のサーバの誤りの一時的な誤り(0×0505)186 13.1.5仕事を受け入れない.7サーバ誤り(0×0506)187 13.1.5.8サーバStatus Codes、187、14 付録C: 「メディア」キーワードは15に190を評価します。 付録D: 処理IPP属性208 15.1信義209 15.2ページ記述言語(PDL)が文書処理の間、15.3の使用の賃仕事のテンプレートが結果と考える210をくつがえす、212、16 付録E: ジェネリックディレクトリ図式214 17。 付録F: IPP/1.0と「モデルと意味論」というIPP/1.1ドキュメント215 18の違い。 完全な著作権宣言文224
Hastings, et al. Standards Track [Page 8] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[8ページ]: モデルと意味論2000年9月
1. Introduction
1. 序論
The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing using Internet tools and technologies. IPP version 1.1 (IPP/1.1) focuses primarily on end user functionality with a few administrative operations included. This document is just one of a suite of documents that fully define IPP. The full set of IPP documents includes:
インターネットPrintingプロトコル(IPP)は分配された印刷にインターネット・ツールと技術を使用することで使用できるアプリケーションレベルプロトコルです。 いくつかの管理操作が含まれている状態で、IPPバージョン1.1(IPP/1.1)は主としてエンドユーザの機能性に焦点を合わせます。 このドキュメントはただIPPを完全に定義するひとそろいのドキュメントの1つです。 IPPドキュメントのフルセットは:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics (this document)
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [RFC2569]
構造とモデルのためのインターネット印刷プロトコル[RFC2567]原理とインターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/1.1のためのプロトコルの目標を設計してください: モデルとSemantics(このドキュメント)インターネットPrintingプロトコル/1.1: コード化と輸送[RFC2910]インターネット印刷プロトコル/1.1: LPDとIPPの間でプロトコルを写像するImplementerのガイド[IPP-IIG][RFC2569]
Anyone reading these documents for the first time is strongly encouraged to read the IPP documents in the above order.
初めてこれらのドキュメントを読んでいるだれでも上記のオーダーにおけるIPPドキュメントを読むよう強く奨励されます。
This document is laid out as follows:
このドキュメントは以下の通り広げられます:
- The rest of Section 1 is an introduction to the IPP simplified
model for distributed printing.
- Section 2 introduces the object types covered in the model with
their basic behaviors, attributes, and interactions.
- Section 3 defines the operations included in IPP/1.1. IPP
operations are synchronous, therefore, for each operation, there is
a both request and a response.
- Section 4 defines the attributes (and their syntaxes) that are used
in the model.
- Sections 5 - 6 summarizes the implementation conformance
requirements for objects that support the protocol and IANA
considerations, respectively.
- Sections 7 - 11 cover the Internationalization and Security
considerations as well as References, Author contact information,
and Formats for Registration Proposals.
- Sections 12 - 14 are appendices that cover Terminology, Status
Codes and Messages, and "media" keyword values.
- セクション1の残りは分配された印刷のためのIPPの簡易型のモデルへの紹介です。 - セクション2はモデルで彼らの基本的な振舞いでカバーされたオブジェクト・タイプ、属性、および相互作用を導入します。 - セクション3はIPP/1.1に含まれていた操作を定義します。 IPP操作が同時である、各操作のために、したがって、aがあります。要求と応答の両方。 - セクション4はモデルで使用される属性(そして、それらの構文)を定義します。 - 5--6が実装順応要件をまとめるセクションは反対します。それは、プロトコルとIANAが問題であるとそれぞれサポートします。 - セクション7--11はRegistration ProposalsのためにReferences、Author問い合わせ先、およびFormatsと同様にInternationalizationとSecurity問題を含んでいます。 - 付録がそのカバーTerminologyと、Status Codesと、Messagesと、「メディア」であるというセクション12--14キーワード値。
Note: This document uses terms such as "attributes", "keywords",
and "support". These terms have special meaning and are defined
in the model terminology section 12.2. Capitalized terms, such
as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT,
and OPTIONAL, have special meaning relating to conformance.
These terms are defined in section 12.1 on conformance
terminology, most of which is taken from RFC 2119 [RFC2119].
以下に注意してください。 このドキュメントは「属性」や、「キーワード」や、「サポート」などの用語を使用します。 これらの用語は、特別な意味を持って、モデル用語部分12.2で定義されます。 大文字で書かれた用語と、そのようなもの、OPTIONAL、NOT、REQUIRED、SHOULD、SHOULD NOT、5月はNOTを必要としなければならなくて、順応に関連する特別な意味を持たなければならなくなってください。 これらの用語は順応用語のセクション12.1で定義されます。その大部分はRFC2119[RFC2119]から取られます。
Hastings, et al. Standards Track [Page 9] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[9ページ]: モデルと意味論2000年9月
- Section 15 is an appendix that helps to clarify the effects of
interactions between related attributes and their values.
- Section 16 is an appendix that enumerates the subset of Printer
attributes that form a generic directory schema. These attributes
are useful when registering a Printer so that a client can find the
Printer not just by name, but by filtered searches as well.
- Section 17 is an appendix summarizing the additions and changes
from the IPP/1.0 "Model and Semantics" document [RFC2566] to make
this IPP/1.1 document.
- Section 18 is the full copyright notice.
- セクション15は関連する属性とそれらの値との相互作用の効果をはっきりさせるのを助ける付録です。 - セクション16はジェネリックディレクトリ図式を形成するPrinter属性の部分集合を列挙する付録です。 クライアントが名前だけで見つけるのではなく、また、フィルターにかけることの検索でPrinterを見つけることができるようにPrinterを登録するとき、これらの属性は役に立ちます。 - セクション17はこのIPP/1.1ドキュメントを作るために「モデルと意味論」というIPP/1.0ドキュメント[RFC2566]から追加と変化をまとめる付録です。 - セクション18は完全な版権情報です。
1.1 Simplified Printing Model
1.1 簡易型の印刷モデル
In order to achieve its goal of realizing a workable printing protocol for the Internet, the Internet Printing Protocol (IPP) is based on a simplified printing model that abstracts the many components of real world printing solutions. The Internet is a distributed computing environment where requesters of print services (clients, applications, printer drivers, etc.) cooperate and interact with print service providers. This model and semantics document describes a simple, abstract model for IPP even though the underlying configurations may be complex "n-tier" client/server systems. An important simplifying step in the IPP model is to expose only the key objects and interfaces required for printing. The model described in this model document does not include features, interfaces, and relationships that are beyond the scope of the first version of IPP (IPP/1.1). IPP/1.1 incorporates many of the relevant ideas and lessons learned from other specification and development efforts [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP]. IPP is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.1 (IPP/1.1) focuses primarily on end user functionality with a few additional OPTIONAL operator operations.
実行可能な印刷プロトコルがインターネットにわかるという目標を達成するために、インターネットPrintingプロトコル(IPP)は本当の世界印刷解決の多くのコンポーネントを抜き取る簡易型の印刷モデルに基づいています。 インターネットは印刷サービス(クライアント、アプリケーション、プリンタドライバなど)のリクエスタが協力して、印刷サービスプロバイダーと対話するところの分散コンピューティング環境です。 基本的な構成は複雑な「n-層」クライアント/サーバーシステムであるかもしれませんが、これはIPPのために簡単で、抽象的なモデルについて説明しますモデルと意味論が、ドキュメントである。IPPモデルにおける重要な簡素化ステップは主要なオブジェクトだけを暴露することです、そして、インタフェースが印刷に必要です。 このモデルドキュメントで説明されたモデルはIPP(IPP/1.1)の最初のバージョンの範囲にある特徴、インタフェース、および関係を入れません。 IPP/1.1は関連考え、他の仕様から学習されたレッスン、および開発努力[HTPP][ISO10175][LDPA][P1387.4][PSIS][RFC1179][SWP]の多くを取り入れます。 IPPはDocument Printing Application(DPA)[ISO10175]規格で紹介された印刷モデルによって大いに影響を及ぼされます。 DPAはエンドユーザと監理上の作業の両方を指定しますが、IPPバージョン1.1(IPP/1.1)はいくつかの追加OPTIONALオペレータ操作で主としてエンドユーザの機能性に焦点を合わせます。
The IPP/1.1 model encapsulates the important components of distributed printing into two object types:
IPP/1.1モデルは分配された印刷の重要な部品を2人のオブジェクト・タイプにカプセル化します:
- Printer (Section 2.1)
- Job (Section 2.2)
- プリンタ(セクション2.1)--仕事(セクション2.2)
Each object type has an associated set of operations (see section 3) and attributes (see section 4).
各オブジェクト・タイプには、関連セットの操作(セクション3を見る)と属性があります(セクション4を見てください)。
Hastings, et al. Standards Track [Page 10] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[10ページ]: モデルと意味論2000年9月
It is important, however, to understand that in real system implementations (which lie underneath the abstracted IPP/1.1 model), there are other components of a print service which are not explicitly defined in the IPP/1.1 model. The following figure illustrates where IPP/1.1 fits with respect to these other components.
しかしながら、実システム実装(放心しているIPP/1.1モデルの下に横たわる)には、IPP/1.1モデルで明らかに定義されない他の印刷サービスのコンポーネントがあるのを理解しているのは重要です。 以下の図は、IPP/1.1がどこでこれらの他のコンポーネントに関して合うかを例証します。
+--------------+
| Application |
o +. . . . . . . |
\|/ | Spooler |
/ \ +. . . . . . . | +---------+
End-User | Print Driver |---| File |
+-----------+ +-----+ +------+-------+ +----+----+
| Browser | | GUI | | |
+-----+-----+ +--+--+ | |
| | | |
| +---+------------+---+ |
N D S | | IPP Client |------------+
O I E | +---------+----------+
T R C | |
I E U |
F C R -------------- Transport ------------------
I T I
C O T | --+
A R Y +--------+--------+ |
T Y | IPP Server | |
I +--------+--------+ |
O | |
N +-----------------+ | IPP Printer
| Print Service | |
+-----------------+ |
| --+
+-----------------+
| Output Device(s)|
+-----------------+
+--------------+ | アプリケーション| o +. . . . . . . | \|/ | スプーラ| / \ +. . . . . . . | +---------+ エンドユーザ| ドライバーを印刷してください。|---| ファイル| +-----------+ +-----+ +------+-------+ +----+----+ | ブラウザ| | クイ| | | +-----+-----+ +--+--+ | | | | | | | +---+------------+---+ | N D S| | IPPクライアント|------------+ ○ I E| +---------+----------+ T R C| | I E U| F C R-------------- 輸送------------------ I T I C O T| --+ R Y+--------+--------+ | T Y| IPPサーバ| | I+--------+--------+ | O| | N+-----------------+ | IPPプリンタ| サービスを印刷してください。| | +-----------------+ | | --+ +-----------------+ | 出力装置| +-----------------+
An IPP Printer object encapsulates the functions normally associated with physical output devices along with the spooling, scheduling and multiple device management functions often associated with a print server. Printer objects are optionally registered as entries in a directory where end users find and select them based on some sort of filtered and context based searching mechanism (see section 16). The directory is used to store relatively static information about the Printer, allowing end users to search for and find Printers that match their search criteria, for example: name, context, printer capabilities, etc. The more dynamic information, such as state, currently loaded and ready media, number of jobs at the Printer,
IPP Printerオブジェクトは、通常、機能がしばしばプリント・サーバに関連している物的生産量デバイスに関連しスプールと共に、計画しおよび複数のデバイス管理機能であることをカプセルに入れります。プリンタオブジェクトはエンドユーザがある種のフィルターにかけることの、そして、文脈に基づいている探すメカニズムに基づいて彼らを見つけて、選択する(セクション16を見てください)ディレクトリにおけるエントリーとして任意に登録されます。 ディレクトリはPrinterの比較的静的な情報を保存するのに使用されます、エンドユーザが例えば彼らの検索評価基準に合っているPrintersを捜し求めて、見つけるのを許容して: 名前、文脈、プリンタ能力など 状態などの、よりダイナミックな情報、Printerでの現在、ロードされて、持ち合わせのメディア、数の仕事
Hastings, et al. Standards Track [Page 11] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[11ページ]: モデルと意味論2000年9月
errors, warnings, and so forth, is directly associated with the Printer object itself rather than with the entry in the directory which only represents the Printer object.
誤り、警告などは直接Printerオブジェクトを表すだけであるディレクトリにおけるエントリーでというよりむしろPrinterオブジェクト自体に関連しています。
IPP clients implement the IPP protocol on the client side and give end users (or programs running on behalf of end users) the ability to query Printer objects and submit and manage print jobs. An IPP server is just that part of the Printer object that implements the server-side protocol. The rest of the Printer object implements (or gateways into) the application semantics of the print service itself. The Printer objects may be embedded in an output device or may be implemented on a host on the network that communicates with an output device.
IPPクライアントは、クライアント側でIPPプロトコルを実装して、印刷仕事をPrinterオブジェクトについて質問して、提出して、管理する能力をエンドユーザ(または、エンドユーザを代表して動くプログラム)に与えます。 IPPサーバはただサーバサイドプロトコルを実装するPrinterオブジェクトのその一部です。 Printerオブジェクト道具の残り、(ゲートウェイ、)、印刷サービス自体のアプリケーション意味論。 Printerオブジェクトは、出力装置に埋め込まれているか、または出力装置とコミュニケートするネットワークでホストの上で実装されるかもしれません。
When a job is submitted to the Printer object and the Printer object validates the attributes in the submission request, the Printer object creates a new Job object. The end user then interacts with this new Job object to query its status and monitor the progress of the job. An end user can also cancel their print jobs by using the Job object's Cancel-Job operation. An end-user can also hold, release, and restart their print jobs using the Job object's OPTIONAL Hold-Job, Release-Job, and Restart-Job operations, if implemented.
Printerオブジェクトに仕事を提出して、Printerオブジェクトが服従要求における属性を有効にすると、Printerオブジェクトは新しいJobオブジェクトを作成します。 そして、エンドユーザは、状態について質問して、仕事の進歩をモニターするためにこの新しいJobオブジェクトと対話します。 また、エンドユーザは、Jobオブジェクトのキャンセル仕事の操作を使用することによって、彼らの印刷仕事を中止できます。 また、エンドユーザは、JobオブジェクトのOPTIONAL Hold-仕事、Release-仕事、およびRestart-仕事の操作を使用することで彼らの印刷仕事を持って、リリースして、再開できます、実装されるなら。
A privileged operator or administrator of a Printer object can cancel, hold, release, and restart any user's job using the REQUIRED Cancel-Job and the OPTIONAL Hold-Job, Release-Job, and Restart-Job operations. In additional privileged operator or administrator of a Printer object can pause, resume, or purge (jobs from) a Printer object using the OPTIONAL Pause-Printer, Resume-Printer, and Purge- Jobs operations, if implemented.
Printerオブジェクトの特権があるオペレータか管理者が、REQUIREDキャンセル仕事、OPTIONAL Hold-仕事、Release-仕事、およびRestart-仕事の操作を使用することでどんなユーザの仕事も中止して、持って、リリースして、再開できます。 オブジェクトがPrinterの追加特権があるオペレータか管理者では、止まるか、再開するか、または除かれることができる、(仕事、)、Resume-プリンタ、およびPurge仕事の操作であって、実装しているOPTIONAL Pause-プリンタを使用するPrinterオブジェクト。
The notification service is out of scope for this IPP/1.1 document, but using such a notification service, the end user is able to register for and receive Printer specific and Job specific events. An end user can query the status of Printer objects and can follow the progress of Job objects by polling using the Get-Printer- Attributes, Get-Jobs, and Get-Job-Attributes operations.
このIPP/1.1ドキュメントのための範囲の外に通知サービスがありますが、そのような通知サービスを利用して、エンドユーザは、Printerの特定の、そして、Job特有のイベントに登録して、受けることができます。 エンドユーザは、Get-プリンタ属性、Get-仕事、およびGet仕事の属性操作を使用しながら、Printerオブジェクトの状態について質問できて、世論調査でJobオブジェクトの進歩の後をつけることができます。
2. IPP Objects
2. IPPオブジェクト
The IPP/1.1 model introduces objects of type Printer and Job. Each type of object models relevant aspects of a real-world entity such as a real printer or real print job. Each object type is defined as a set of possible attributes that may be supported by instances of that object type. For each object (instance), the actual set of supported attributes and values describe a specific implementation. The object's attributes and values describe its state, capabilities, realizable features, job processing functions, and default behaviors
IPP/1.1モデルはタイプPrinterとJobのオブジェクトを導入します。 それぞれのタイプのオブジェクトは本当のプリンタか本当の印刷仕事などの本当の世界実体の関連局面をモデル化します。 各オブジェクト・タイプはそのオブジェクト・タイプのインスタンスによってサポートされるかもしれない1セットの可能な属性と定義されます。 各オブジェクト(インスタンス)に関しては、サポートしている属性と実際の値は、特定の実装について説明します。 オブジェクトの属性と値は状態、能力、実現可能な特徴、ジョブ処理機能、およびデフォルトの振舞いについて説明します。
Hastings, et al. Standards Track [Page 12] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[12ページ]: モデルと意味論2000年9月
and characteristics. For example, the Printer object type is defined as a set of attributes that each Printer object potentially supports. In the same manner, the Job object type is defined as a set of attributes that are potentially supported by each Job object.
そして、特性。 例えば、Printerオブジェクト・タイプはそれぞれのPrinterオブジェクトが潜在的にサポートする1セットの属性と定義されます。 同じ方法では、Jobオブジェクト・タイプはそれぞれのJobオブジェクトによって潜在的にサポートされる1セットの属性と定義されます。
Each attribute included in the set of attributes defining an object type is labeled as:
オブジェクト・タイプを定義する属性のセットに各属性を含んでいるのは以下としてラベルされます。
- "REQUIRED": each object MUST support the attribute. - "RECOMMENDED": each object SHOULD support the attribute. - "OPTIONAL": each object MAY support the attribute.
- 「必要」: 各オブジェクトは属性をサポートしなければなりません。 - 「お勧め」: それぞれのオブジェクトSHOULDは属性をサポートします。 - 「任意」: 各オブジェクトは属性をサポートするかもしれません。
Some definitions of attribute values indicate that an object MUST or SHOULD support the value; otherwise, support of the value is OPTIONAL.
属性値のいくつかの定義が、オブジェクトがそうしなければならないのを示すか、またはSHOULDは値をサポートします。 さもなければ、価値のサポートはOPTIONALです。
However, if an implementation supports an attribute, it MUST support at least one of the possible values for that attribute.
しかしながら、実装が属性をサポートするなら、それはその属性のために少なくとも可能な値の1つをサポートしなければなりません。
2.1 Printer Object
2.1 プリンタオブジェクト
The major component of the IPP/1.1 model is the Printer object. A Printer object implements the server-side of the IPP/1.1 protocol. Using the protocol, end users may query the attributes of the Printer object and submit print jobs to the Printer object. The actual implementation components behind the Printer abstraction may take on different forms and different configurations. However, the model abstraction allows the details of the configuration of real components to remain opaque to the end user. Section 3 describes each of the Printer operations in detail.
IPP/1.1モデルの主要な部品はPrinterオブジェクトです。 PrinterオブジェクトはIPP/1.1プロトコルのサーバ側を実装します。 プロトコルを使用して、エンドユーザは、Printerオブジェクトの属性について質問して、Printerオブジェクトに印刷仕事を提出するかもしれません。 Printer抽象化の後ろの実際の実装コンポーネントは異なったフォームと異なった構成を呈するかもしれません。 しかしながら、モデル抽象化で、本当のコンポーネントの構成の詳細はエンドユーザにとって不透明なままで残っています。 セクション3は詳細にそれぞれのPrinter操作について説明します。
The capabilities and state of a Printer object are described by its attributes. Printer attributes are divided into two groups:
Printerオブジェクトの能力と状態は属性によって説明されます。 プリンタ属性は2つのグループに分割されます:
- "job-template" attributes: These attributes describe supported job
processing capabilities and defaults for the Printer object. (See
section 4.2)
- "printer-description" attributes: These attributes describe the
Printer object's identification, state, location, references to
other sources of information about the Printer object, etc. (see
section 4.4)
- 「仕事テンプレート」属性: これらの属性はPrinterオブジェクトのためにサポートしているジョブ処理能力とデフォルトについて説明します。 (セクション4.2を見ます) - 「プリンタ記述」属性: これらの属性はPrinterオブジェクトの識別、状態、位置、Printerオブジェクトに関する他の情報筋の参照などについて説明します。 (セクション4.4を見ます)
Since a Printer object is an abstraction of a generic document output device and print service provider, a Printer object could be used to represent any real or virtual device with semantics consistent with the Printer object, such as a fax device, an imager, or even a CD writer.
Printerオブジェクトがジェネリックドキュメント出力装置と印刷サービスプロバイダーの抽象化であるので、Printerオブジェクトと一致した意味論でどんな本当の、または、仮想のデバイスも表すのにPrinterオブジェクトを使用できました、ファックスデバイス、イメージャ、またはCD作家などのようにさえ。
Hastings, et al. Standards Track [Page 13] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[13ページ]: モデルと意味論2000年9月
Some examples of configurations supporting a Printer object include:
Printerオブジェクトを支える構成に関するいくつかの例は:
1) An output device with no spooling capabilities
2) An output device with a built-in spooler
3) A print server supporting IPP with one or more associated
output devices
3a) The associated output devices may or may not be capable of
spooling jobs
3b) The associated output devices may or may not support IPP
1) スプール能力2)のない出力装置 内蔵のスプーラ3)がある出力装置 1関連出力装置3a)でIPPをサポートするプリント・サーバ 出力装置を仕事の3bをスプールしながら、関連させることができるかもしれません) 関連出力装置はIPPをサポートするかもしれません。
The following figures show some examples of how Printer objects can be realized on top of various distributed printing configurations. The embedded case below represents configurations 1 and 2. The hosted and fan-out figures below represent configurations 3a and 3b.
以下の数字は様々な分散印刷構成の上でどうPrinterオブジェクトを実感できるかに関するいくつかの例を示しています。 以下の埋め込まれたケースは構成1と2を表します。 以下の数字を接待して、四方八方に広げてください。構成3aと3bを表してください。
In this document the term "client" refers to a software entity that sends IPP operation requests to an IPP Printer object and accepts IPP operation responses. A client MAY be:
本書では「クライアント」という用語はIPP Printerオブジェクトへの操作要求をIPPに送って、IPP操作応答を受け入れるソフトウェア実体について言及します。 クライアントは以下の通りです。
1. contained within software controlled by an end user, e.g.
activated by the "Print" menu item in an application or
または1. 含まれて、例えばエンドユーザによって制御されたソフトウェアがアプリケーションで中では、「印刷」メニュー項目を動かした。
2. the print server component that sends IPP requests to either an
output device or another "downstream" print server.
2. IPPを送るプリント・サーバコンポーネントは出力装置か「川下」のどちらかに別プリント・サーバを要求します。
The term "IPP Printer" is a network entity that accepts IPP operation requests and returns IPP operation responses. As such, an IPP object MAY be:
「IPPプリンタ」という用語はIPP操作要求を受け入れて、操作応答をIPPに返すネットワーク実体です。 そういうものとして、IPPオブジェクトは以下の通りです。
1. an (embedded) device component that accepts IPP requests and
controls the device or
または1. IPPを受け入れる(埋め込まれている)のデバイスの部品がデバイスを要求して、制御する。
2. a component of a print server that accepts IPP requests (where
the print server controls one or more networked devices using
IPP or other protocols).
2. IPPを受け入れるプリント・サーバの成分は(よりプリント・サーバより多くのコントロール1はどこでIPPを使用することでデバイスをネットワークでつないだか、そして、他のプロトコル)を要求します。
Legend:
伝説:
##### indicates a Printer object which is
either embedded in an output device or is
hosted in a server. The Printer object
might or might not be capable of queuing/spooling.
##### 出力装置に埋め込まれているPrinterオブジェクトを示すか. Printerオブジェクトが列に並ばせるかもしれないか、または列に並ばせることができないかもしれないサーバで接待されるか、またはスプールしています。
any indicates any network protocol or direct
connect, including IPP
IPPを含んでいて、いずれもどんなネットワーク・プロトコルも示すか、またはダイレクトに、接続してください。
Hastings, et al. Standards Track [Page 14] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[14ページ]: モデルと意味論2000年9月
embedded printer:
output device
+---------------+
O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
+---------------+
プリンタを埋め込みます: 出力装置+---------------+ ○ +--------+ | ########### | /|\ | クライアント|------------IPP------------># プリンタ#| / \ +--------+ | # オブジェクト#| | ########### | +---------------+
hosted printer:
+---------------+
O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ # Object # | |
########### +---------------+
プリンタを接待します: +---------------+ ○ +--------+ ########### | | /|\ | クライアント|--IPP--、いくらか>#プリンタ#、->| 出力装置| / \ +--------+ #オブジェクト#| | ########### +---------------+
+---------------+
fan out: | |
+-->| output device |
any/ | |
O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+-->| output device |
| |
+---------------+
+---------------+は四方八方に広がります: | | +-->| 出力装置| どんな/| | ○ +--------+ ########### / +---------------+ /|\ | クライアント|-IPP>#プリンタ#--*/\+--------+ #オブジェクト#\+---------------+ ###########どんな\| | +-->| 出力装置| | | +---------------+
2.2 Job Object
2.2 仕事のオブジェクト
A Job object is used to model a print job. A Job object contains documents. The information required to create a Job object is sent in a create request from the end user via an IPP Client to the Printer object. The Printer object validates the create request, and if the Printer object accepts the request, the Printer object creates the new Job object. Section 3 describes each of the Job operations in detail.
Jobオブジェクトは、印刷仕事をモデル化するのに使用されます。 Jobオブジェクトはドキュメントを含んでいます。 aで送られるJobが、反対するaを作成するのに必要である情報はIPP Clientを通したエンドユーザからPrinterオブジェクトまでの要求を作成します。 Printerオブジェクトが有効にする、要求を作成してください。そうすれば、Printerオブジェクトが要請を受け入れるなら、Printerオブジェクトは新しいJobオブジェクトを作成します。 セクション3は詳細にそれぞれのJob操作について説明します。
The characteristics and state of a Job object are described by its attributes. Job attributes are grouped into two groups as follows:
Jobオブジェクトの特性と状態は属性によって説明されます。 仕事の属性は以下の2つのグループに分類されます:
- "job-template" attributes: These attributes can be supplied by
the client or end user and include job processing instructions
which are intended to override any Printer object defaults
and/or instructions embedded within the document data. (See
section 4.2)
- 「仕事テンプレート」属性: これらの属性は、クライアントかエンドユーザによって供給されて、どんなPrinterオブジェクトデフォルトもくつがえすことを意図するジョブ処理指示、そして/または、ドキュメントデータの中で埋め込まれた指示を含むことができます。 (セクション4.2を見ます)
Hastings, et al. Standards Track [Page 15] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[15ページ]: モデルと意味論2000年9月
- "job-description" attributes: These attributes describe the Job
object's identification, state, size, etc. The client supplies
some of these attributes, and the Printer object generates
others. (See section 4.3)
- 「職務記述書」属性: これらの属性はJobオブジェクトの識別、状態、サイズなどについて説明します。 クライアントはこれらの属性のいくつかを供給します、そして、Printerオブジェクトは他のものを生成します。 (セクション4.3を見ます)
An implementation MUST support at least one document per Job object. An implementation MAY support multiple documents per Job object. A document is either:
実装はJobオブジェクトあたり少なくとも1通のドキュメントを支えなければなりません。 実装は複数のJobオブジェクトあたりのドキュメントを支えるかもしれません。 ドキュメントはどちらかです:
- a stream of document data in a format supported by the Printer
object (typically a Page Description Language - PDL), or
- a reference to such a stream of document data
- または、Printerオブジェクト(通常ページ記述Language--PDL)によってサポートされた形式のドキュメントデータのストリーム、--aがドキュメントデータのストリームにそのようなものに参照をつける
In IPP/1.1, a document is not modeled as an IPP object, therefore it has no object identifier or associated attributes. All job processing instructions are modeled as Job object attributes. These attributes are called Job Template attributes and they apply equally to all documents within a Job object.
IPP/1.1では、ドキュメントはIPPオブジェクトとしてモデル化されません、したがって、それには、どんなオブジェクト識別子も関連属性もありません。 すべてのジョブ処理指示がJobオブジェクト属性としてモデル化されます。 これらの属性はJob Template属性と呼ばれます、そして、それらは等しくJobオブジェクトの中のすべてのドキュメントに申し込みます。
2.3 Object Relationships
2.3 オブジェクト関係
IPP objects have relationships that are maintained persistently along with the persistent storage of the object attributes.
IPPオブジェクトには、オブジェクト属性の永続的なストレージと共に持続して維持される関係があります。
A Printer object can represent either one or more physical output devices or a logical device which "processes" jobs but never actually uses a physical output device to put marks on paper. Examples of logical devices include a Web page publisher or a gateway into an online document archive or repository. A Printer object contains zero or more Job objects.
Printerオブジェクトは、どちらか、より物理的な出力装置または仕事を「処理する」論理的なデバイスを表すことができますが、紙上のマークを置くのに実際に物的生産量デバイスを決して使用しません。 論理的なデバイスに関する例はオンラインドキュメントアーカイブか倉庫にウェブページ出版社かゲートウェイを含んでいます。 Printerオブジェクトがゼロを含んでいるか、または、より多くのJobが反対します。
A Job object is contained by exactly one Printer object, however the identical document data associated with a Job object could be sent to either the same or a different Printer object. In this case, a second Job object would be created which would be almost identical to the first Job object, however it would have new (different) Job object identifiers (see section 2.4).
ちょうど1個のPrinterオブジェクトでJobオブジェクトを含んで、しかしながら、Jobオブジェクトに関連している同じドキュメントデータを同じくらいか異なったPrinterオブジェクトのどちらかに送ることができました。 それには、この場合、2番目の最初のJobオブジェクトとほとんど同じJobオブジェクトは作成されて、しかしながら、新しい(異なった)仕事のオブジェクト識別子があるでしょう(セクション2.4を見てください)。
A Job object is either empty (before any documents have been added) or contains one or more documents. If the contained document is a stream of document data, that stream can be contained in only one document. However, there can be identical copies of the stream in other documents in the same or different Job objects. If the contained document is just a reference to a stream of document data, other documents (in the same or different Job object(s)) may contain the same reference.
Jobオブジェクトは、空であるか(どんなドキュメントも加えられる前に)、または1通以上のドキュメントを含んでいます。 含まれたドキュメントがドキュメントデータのストリームであるなら、1通のドキュメントだけにそのストリームを含むことができます。 しかしながら、他のドキュメントにはストリームの同一の複製物が同じであるか異なったJobオブジェクトにあることができます。 ドキュメントデータ、他のドキュメントのストリームにはまさしく参照が含まれたドキュメントであるならあります。(同じであるか異なるところでは、Jobオブジェクト(s))は同じ参照を含むかもしれません。
Hastings, et al. Standards Track [Page 16] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[16ページ]: モデルと意味論2000年9月
2.4 Object Identity
2.4 オブジェクトのアイデンティティ
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.
Uniform Resource Identifier(URI)[RFC2396]によってすべてのPrinterとJobオブジェクトは、持続して明白にそれらに参照をつけることができるように特定されます。 より多くの総称URIがこのドキュメントの残りの間中使用されますが、あらゆるURLがURIの専門化しているフォームであるので、用法がまた、URLの、より特定の概念をカバーすることを意図します。
An administrator configures Printer objects to either support or not support authentication and/or message privacy using Transport Layer Security (TLS) [RFC2246] (the mechanism for security configuration is outside the scope of this IPP/1.1 document). In some situations, both types of connections (both authenticated and unauthenticated) can be established using a single communication channel that has some sort of negotiation mechanism. In other situations, multiple communication channels are used, one for each type of security configuration. Section 8 provides a full description of all security considerations and configurations.
管理者は、Transport Layer Security(TLS)[RFC2246]を使用することでサポートかサポート認証でない、そして/または、メッセージプライバシーのどちらかにPrinterオブジェクトを構成します(このIPP/1.1ドキュメントの範囲の外にセキュリティ設定のためのメカニズムがあります)。 いくつかの状況に、ある種の交渉メカニズムを持っているただ一つの通信チャネルを使用することで両方のタイプの接続(認証されて、非認証される)を確立できます。 他の状況複数の通信チャネルが使用されていて、それぞれのためのものはセキュリティ設定のタイプです。 セクション8はすべてのセキュリティ問題と構成の余すところのない解説を提供します。
If a Printer object supports more than one communication channel, some or all of those channels might support and/or require different security mechanisms. In such cases, an administrator could expose the simultaneous support for these multiple communication channels as multiple URIs for a single Printer object where each URI represents one of the communication channels to the Printer object. To support this flexibility, the IPP Printer object type defines a multi-valued identification attribute called the "printer-uri-supported" attribute. It MUST contain at least one URI. It MAY contain more than one URI. That is, every Printer object will have at least one URI that identifies at least one communication channel to the Printer object, but it may have more than one URI where each URI identifies a different communication channel to the Printer object. The "printer-uri-supported" attribute has two companion attributes, the "uri-security-supported" attribute and the "uri-authentication- supported". Both have the same cardinality as "printer-uri- supported". The purpose of the "uri-security-supported" attribute is to indicate the security mechanisms (if any) used for each URI listed in "printer-uri-supported". The purpose of the "uri-authentication- supported" attribute is to indicate the authentication mechanisms (if any) used for each URI listed in "printer-uri-supported". These three attributes are fully described in sections 4.4.1, 4.4.2, and 4.4.3.
Printerオブジェクトが1つ以上の通信チャネルをサポートするなら、いくつかかそれらのチャンネルが皆、異なったセキュリティー対策をサポートする、そして/または、必要とするかもしれません。そのような場合、独身のPrinterにおいて複数のURIが各URIが通信チャネルの1つをPrinterオブジェクトに表すところで反対するように管理者はこれらの複数の通信チャネルの同時のサポートを暴露することができました。 この柔軟性をサポートするために、IPP Printerオブジェクト・タイプは「uriが支えたプリンタ」属性と呼ばれるマルチ評価された識別属性を定義します。 それは少なくとも1つのURIを含まなければなりません。 それは1つ以上のURIを含むかもしれません。 すなわちあらゆるPrinterオブジェクトが少なくとも1つの通信チャネルを特定する少なくとも1つのURIをPrinterオブジェクトに持つでしょうが、各URIがPrinterオブジェクトへの異なった通信チャネルを特定するところにそれは1つ以上のURIを持っているかもしれません。 「uriが支えたプリンタ」属性に、2つの仲間属性、「セキュリティがサポートしたuri」属性、「uriに認証でサポートされること」があります。 両方には、「プリンタ-uriによってサポートされること」と同じ基数があります。 「セキュリティがサポートしたuri」属性の目的は各URIに使用されるセキュリティー対策(もしあれば)が「uriが支えたプリンタ」に記載したのを示すことです。 「uri-認証でサポートしている」属性の目的は各URIに使用される認証機構(もしあれば)が「uriが支えたプリンタ」に記載したのを示すことです。 完全に説明されたコネセクション4.4.1、4.4は、.2と、4.4です。これらの3つの属性、.3。
When a job is submitted to the Printer object via a create request, the client supplies only a single Printer object URI. The client supplied Printer object URI MUST be one of the values in the "printer-uri-supported" Printer attribute.
aを通して要求を作成するためにPrinterが、反対する仕事を提出するとき、クライアントはただ一つのPrinterオブジェクトURIだけを供給します。 クライアントの供給されたPrinterオブジェクトURIは「uriが支えたプリンタ」Printer属性における値の1つであるに違いありません。
Hastings, et al. Standards Track [Page 17] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[17ページ]: モデルと意味論2000年9月
IPP/1.1 does not specify how the client obtains the client supplied URI, but it is RECOMMENDED that a Printer object be registered as an entry in a directory service. End-users and programs can then interrogate the directory searching for Printers. Section 16 defines a generic schema for Printer object entries in the directory service and describes how the entry acts as a bridge to the actual IPP Printer object. The entry in the directory that represents the IPP Printer object includes the possibly many URIs for that Printer object as values in one its attributes.
IPP/1.1はクライアントがどうクライアントの供給されたURIを得るかを指定しませんが、Printerオブジェクトがエントリーとしてディレクトリサービスに登録されるのは、RECOMMENDEDです。 そして、エンドユーザとプログラムはPrintersを捜し求めるディレクトリについて査問できます。 セクション16は、ディレクトリサービスのPrinterオブジェクトエントリーとジェネリック図式を定義して、実際のIPP Printerオブジェクトへのブリッジとしてエントリーがどう行動するかを記述します。 1で属性を評価するとき、IPP Printerオブジェクトを表すディレクトリにおけるエントリーはそのPrinterオブジェクトのためのことによると多くのURIを含んでいます。
When a client submits a create request to the Printer object, the Printer object validates the request and creates a new Job object. The Printer object assigns the new Job object a URI which is stored in the "job-uri" Job attribute. This URI is then used by clients as the target for subsequent Job operations. The Printer object generates a Job URI based on its configured security policy and the URI used by the client in the create request.
クライアントがaを提出したら、オブジェクト、Printerが要求を有効にして、新しいJobオブジェクトを作成するのを反対させるPrinterに要求を作成してください。 Printerオブジェクトは「仕事-uri」Job属性で保存されるURIを新しいJobオブジェクトに割り当てます。 そして、このURIはその後のJob操作のための目標としてクライアントによって使用されます。 Printerオブジェクトが構成された安全保障政策に基づくJob URIと中でクライアントによって使用されたURIを生成する、要求を作成してください。
For example, consider a Printer object that supports both a communication channel secured by the use of SSL3 (using HTTP over SSL3 with an "https" schemed URI) and another open communication channel that is not secured with SSL3 (using a simple "http" schemed URI). If a client were to submit a job using the secure URI, the Printer object would assign the new Job object a secure URI as well. If a client were to submit a job using the open-channel URI, the Printer would assign the new Job object an open-channel URI.
例えば、両方がSSL3(SSL3の上で"https"計画されたURIでHTTPを使用する)の使用で保証された通信チャネルであるとサポートするPrinterオブジェクトとSSL3と共に固定されていない別のオープンコミュニケーションチャンネルを考えてください(簡単な"http"計画されたURIを使用して)。 クライアントが安全なURIを使用することで仕事を提出するなら、Printerオブジェクトはまた、安全なURIを新しいJobオブジェクトに割り当てるでしょうに。 クライアントが開水路URIを使用することで仕事を提出するなら、Printerは新しいJobオブジェクトに開水路URIを割り当てるでしょうに。
In addition, the Printer object also populates the Job object's "job-printer-uri" attribute. This is a reference back to the Printer object that created the Job object. If a client only has access to a Job object's "job-uri" identifier, the client can query the Job's "job-printer-uri" attribute in order to determine which Printer object created the Job object. If the Printer object supports more than one URI, the Printer object picks the one URI supplied by the client when creating the job to build the value for and to populate the Job's "job-printer-uri" attribute.
また、さらに、PrinterオブジェクトはJobオブジェクトの「仕事のプリンタuri」属性に居住します。 これはJobオブジェクトを作成したPrinterオブジェクトの参照です。 クライアントがJobオブジェクトの「仕事-uri」識別子に近づく手段を持っているだけであるなら、クライアントは、どのPrinterオブジェクトがJobオブジェクトを作成したかを決定するためにJobの「仕事のプリンタuri」属性について質問できます。 値を築き上げて、居住する雇用を創り出すとJobの「仕事のプリンタuri」属性が人が1つのURIを選ぶよりURI、Printerが、反対するクライアントによってPrinterオブジェクトサポートで供給されているなら。
Allowing Job objects to have URIs allows for flexibility and scalability. For example, in some implementations, the Printer object might create Jobs that are processed in the same local environment as the Printer object itself. In this case, the Job URI might just be a composition of the Printer's URI and some unique component for the Job object, such as the unique 32-bit positive integer mentioned later in this paragraph. In other implementations, the Printer object might be a central clearing-house for validating all Job object creation requests, but the Job object itself might be created in some environment that is remote from the Printer object. In this case, the Job object's URI may have no physical-location
JobオブジェクトにはURIがあるのを許容するのが柔軟性とスケーラビリティを考慮します。 例えば、いくつかの実装では、PrinterオブジェクトはPrinterオブジェクト自体と同じ地方の環境で処理されるジョブスを創造するかもしれません。 この場合、Job URIは、まさしくPrinterのURIの構成とJobオブジェクトのための何らかのユニークなコンポーネントであるかもしれません、このパラグラフで後で言及されたユニークな32ビットの正の整数などのように。 他の実装では、PrinterオブジェクトはすべてのJobオブジェクト作成要求を有効にするための中央のクリアリングハウスであるかもしれませんが、Jobオブジェクト自体は何らかのPrinterオブジェクトからリモートな環境で作成されるかもしれません。 この場合、JobオブジェクトのURIには、どんな物理的な位置もないかもしれません。
Hastings, et al. Standards Track [Page 18] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[18ページ]: モデルと意味論2000年9月
relationship at all to the Printer object's URI. Again, the fact that Job objects have URIs allows for flexibility and scalability, however, many existing printing systems have local models or interface constraints that force print jobs to be identified using only a 32-bit positive integer rather than an independent URI. This numeric Job ID is only unique within the context of the Printer object to which the create request was originally submitted. Therefore, in order to allow both types of client access to IPP Job objects (either by Job URI or by numeric Job ID), when the Printer object successfully processes a create request and creates a new Job object, the Printer object MUST generate both a Job URI and a Job ID. The Job ID (stored in the "job-id" attribute) only has meaning in the context of the Printer object to which the create request was originally submitted. This requirement to support both Job URIs and Job IDs allows all types of clients to access Printer objects and Job objects no matter the local constraints imposed on the client implementation.
全くPrinterオブジェクトのURIとの関係。 多くの既存の印刷システムには、一方、JobオブジェクトにURIがあるという事実は柔軟性とスケーラビリティを考慮して、しかしながら、印刷仕事が独立しているURIよりむしろ32ビットの正の整数だけを使用することでやむを得ず特定されるローカルのモデルかインタフェース規制があります。 要求を作成してください。この数値Job IDがPrinterオブジェクトの文脈の中でユニークであるだけである、どれ、元々、提出したか。 したがって、Printerオブジェクトが首尾よくaを処理するときのIPP Jobオブジェクト(Job URIか数値Job IDのそばの)へのクライアントアクセスのタイプは、両方を許容するために要求を作成して、新しいJobオブジェクトを作成して、Printerオブジェクトは、両方がJob URIとJob IDであると生成しなければなりません。 要求を作成してください。Job ID(「賃仕事のイド」属性では、保存される)にはPrinterオブジェクトの文脈での意味があるだけである、どれ、元々、提出したか。 Job URIとJob IDの両方をサポートするというこの要件はPrinterオブジェクトにアクセスするクライアントとJobオブジェクトのすべてのタイプに地方の規制がクライアント実装を課した問題を全く許容しません。
In addition to identifiers, Printer objects and Job objects have
names ("printer-name" and "job-name"). An object name NEED NOT be
unique across all instances of all objects. A Printer object's name
is chosen and set by an administrator through some mechanism outside
the scope of this IPP/1.1 document. A Job object's name is
optionally chosen and supplied by the IPP client submitting the job.
If the client does not supply a Job object name, the Printer object
generates a name for the new Job object. In all cases, the name only
has local meaning.
識別子に加えて、PrinterオブジェクトとJobオブジェクトには、名前(「プリンタ名」と「ジョブ名」)があります。 オブジェクト名はすべてのオブジェクトのすべてのインスタンスの向こう側にユニークである必要はありません。 Printerオブジェクトの名前は、このIPP/1.1ドキュメントの範囲の外の何らかのメカニズムを通して選ばれて、管理者でセットしました。 Jobオブジェクトの名前は、仕事を提出するIPPクライアントによって、任意に選ばれていて、提供されます。 クライアントがJobオブジェクト名を供給しないなら、Printerオブジェクトは新しいJobオブジェクトのために名前を生成します。 すべての場合では、名前は特定の意味を持っているだけです。
To summarize:
まとめるために:
- Each Printer object is identified with one or more URIs. The
Printer's "printer-uri-supported" attribute contains the URI(s).
- The Printer object's "uri-security-supported" attribute
identifies the communication channel security protocols that may
or may not have been configured for the various Printer object
URIs (e.g., 'tls' or 'none').
- The Printer object's "uri-authentication-supported" attribute
identifies the authentication mechanisms that may or may not
have been configured for the various Printer object URIs (e.g.,
'digest' or 'none').
- Each Job object is identified with a Job URI. The Job's "job-
uri" attribute contains the URI.
- Each Job object is also identified with Job ID which is a 32-
bit, positive integer. The Job's "job-id" attribute contains
the Job ID. The Job ID is only unique within the context of the
Printer object which created the Job object.
- それぞれのPrinterオブジェクトは1つ以上のURIと同一視されています。 Printerの「uriが支えたプリンタ」属性はURIを含んでいます。 - Printerオブジェクトの「セキュリティがサポートしたuri」属性は様々なPrinterオブジェクトURI(例えば、'tls'か'なにも')のために構成されたかもしれない通信チャネルセキュリティプロトコルを特定します。 - Printerオブジェクトの「認証がサポートしたuri」属性は様々なPrinterオブジェクトURI(例えば、'ダイジェスト'か'なにも')のために構成されたかもしれない認証機構を特定します。 - それぞれのJobオブジェクトはJob URIと同一視されています。 Jobの「仕事のuri」属性はURIを含んでいます。 - また、それぞれのJobオブジェクトは32ビット、正の整数であるJob IDと同一視されています。 Jobの「仕事イド」属性はJob IDを含んでいます。 Job IDはJobオブジェクトを作成したPrinterオブジェクトの文脈の中でユニークであるだけです。
Hastings, et al. Standards Track [Page 19] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[19ページ]: モデルと意味論2000年9月
- Each Job object has a "job-printer-uri" attribute which contains
the URI of the Printer object that was used to create the Job
object. This attribute is used to determine the Printer object
that created a Job object when given only the URI for the Job
object. This linkage is necessary to determine the languages,
charsets, and operations which are supported on that Job (the
basis for such support comes from the creating Printer object).
- Each Printer object has a name (which is not necessarily
unique). The administrator chooses and sets this name through
some mechanism outside the scope of this IPP/1.1 document. The
Printer object's "printer-name" attribute contains the name.
- Each Job object has a name (which is not necessarily unique).
The client optionally supplies this name in the create request.
If the client does not supply this name, the Printer object
generates a name for the Job object. The Job object's "job-name"
attribute contains the name.
- それぞれのJobオブジェクトには、Jobオブジェクトを作成するのに使用されたPrinterオブジェクトのURIを含む「仕事のプリンタuri」属性があります。 この属性は、JobオブジェクトのためにURIだけを与えるときJobオブジェクトを作成したPrinterオブジェクトを決定するのに使用されます。 このリンケージが、そのJobでサポートされる言語、charsets、および操作を決定するのに必要です(そのようなサポートの基礎は作成しているPrinterオブジェクトから来ます)。 - それぞれのPrinterオブジェクトには、名前(必ずユニークであるというわけではない)があります。 管理者は、このIPP/1.1ドキュメントの範囲の外の何らかのメカニズムを通してこの名前を選んで、設定します。 Printerオブジェクトの「プリンタ名」属性は名前を含んでいます。 - それぞれのJobオブジェクトには、名前(必ずユニークであるというわけではない)があります。 クライアントが任意にこの名前を提供する、要求を作成してください。 クライアントがこの名前を提供しないなら、PrinterオブジェクトはJobオブジェクトのために名前を生成します。 Jobオブジェクトの「ジョブ名」属性は名前を含んでいます。
3. IPP Operations
3. IPP操作
IPP objects support operations. An operation consists of a request and a response. When a client communicates with an IPP object, the client issues an operation request to the URI for that object. Operation requests and responses have parameters that identify the operation. Operations also have attributes that affect the run-time characteristics of the operation (the intended target, localization information, etc.). These operation-specific attributes are called operation attributes (as compared to object attributes such as Printer object attributes or Job object attributes). Each request carries along with it any operation attributes, object attributes, and/or document data required to perform the operation. Each request requires a response from the object. Each response indicates success or failure of the operation with a status code as a response parameter. The response contains any operation attributes, object attributes, and/or status messages generated during the execution of the operation request.
IPPオブジェクトは操作をサポートします。 操作は要求と応答から成ります。 クライアントがIPPオブジェクトで交信するとき、クライアントはその趣意で操作要求をURIに出します。 操作要求と応答には、操作を特定するパラメタがあります。 また、操作には、操作(意図している目標、ローカライズ情報など)のランタイムの特性に影響する属性があります。 これらの操作特有の属性は操作属性と呼ばれます(Printerオブジェクト属性かJobオブジェクト属性などのオブジェクト属性と比べて)。 各要求はそれと共にどんな操作属性も運んで、オブジェクト属性、そして/または、ドキュメントデータが操作を実行するのが必要です。 各要求はオブジェクトから応答を必要とします。 各応答は応答パラメタとしてステータスコードで操作の成否を示します。 応答は操作要求の実行の間に生成されたどんな操作属性、オブジェクト属性、そして/または、ステータスメッセージも含んでいます。
This section describes the semantics of the IPP operations, both requests and responses, in terms of the parameters, attributes, and other data associated with each operation.
このセクションはIPP操作の意味論、要求と応答の両方について説明します、各操作に関連しているパラメタ、属性、および他のデータに関して。
Hastings, et al. Standards Track [Page 20] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[20ページ]: モデルと意味論2000年9月
The IPP/1.1 Printer operations are:
IPP/1.1Printer操作は以下の通りです。
Print-Job (section 3.2.1)
Print-URI (section 3.2.2)
Validate-Job (section 3.2.3)
Create-Job (section 3.2.4)
Get-Printer-Attributes (section 3.2.5)
Get-Jobs (section 3.2.6)
Pause-Printer (section 3.3.5)
Resume-Printer (section 3.3.6)
Purge-Jobs (section 3.3.7)
プリンタ属性を得ている(セクション3.2.5)印刷仕事(セクション3.2.1)の印刷URI(セクション3.2.2)の仕事を有効にしている(セクション3.2.3)雇用を創り出している(セクション3.2.4)ジョブスを得ている(セクション3.2.6)くぎりプリンタ(セクション3.3.5)履歴書プリンタ(セクション3.3.6)パージ仕事(セクション3.3.7)
The Job operations are:
Job操作は以下の通りです。
Send-Document (section 3.3.1)
Send-URI (section 3.3.2)
Cancel-Job (section 3.3.3)
Get-Job-Attributes (section 3.3.4)
Hold-Job (section 3.3.5)
Release-Job (section 3.3.6)
Restart-Job (section 3.3.7)
仕事の属性を得ている(セクション3.3.4)ドキュメントを発信させている(セクション3.3.1)URIを発信させている(セクション3.3.2)キャンセル仕事(セクション3.3.3)の保持仕事(セクション3.3.5)のリリース仕事(セクション3.3.6)の再開仕事(セクション3.3.7)
The Send-Document and Send-URI Job operations are used to add a new document to an existing multi-document Job object created using the Create-Job operation.
Send-ドキュメントとSend-URI Job操作は、Create-仕事の操作を使用することで作成された既存のマルチドキュメントJobオブジェクトに新しいドキュメントを加えるのに使用されます。
3.1 Common Semantics
3.1 一般的な意味論
All IPP operations require some common parameters and operation attributes. These common elements and their semantic characteristics are defined and described in more detail in the following sections.
すべてのIPP操作がいくつかの一般的なパラメタと操作属性を必要とします。 これらの一般的な要素とそれらの意味特性は、さらに詳細に以下のセクションで定義されて、説明されます。
3.1.1 Required Parameters
3.1.1 必要なパラメタ
Every operation request contains the following REQUIRED parameters:
あらゆる操作要求が以下のREQUIREDパラメタを含んでいます:
- a "version-number",
- an "operation-id",
- a "request-id", and
- the attributes that are REQUIRED for that type of request.
- そして、「バージョン番号」--「操作イド」--「要求イド」、--そのタイプの要求のためのREQUIREDである属性。
Every operation response contains the following REQUIRED parameters:
あらゆる操作応答が以下のREQUIREDパラメタを含んでいます:
- a "version-number",
- a "status-code",
- the "request-id" that was supplied in the corresponding request,
and
- the attributes that are REQUIRED for that type of response.
- そして、「バージョン番号」--「ステータスコード」--対応する要求で供給された「要求イド」、--そのタイプの応答のためのREQUIREDである属性。
Hastings, et al. Standards Track [Page 21] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[21ページ]: モデルと意味論2000年9月
The "Encoding and Transport" document [RFC2910] defines special rules for the encoding of these parameters. All other operation elements are represented using the more generic encoding rules for attributes and groups of attributes.
「コード化と輸送」というドキュメント[RFC2910]はこれらのパラメタのコード化のための特別な規則を定義します。 他のすべての操作要素が、属性の属性とグループにより多くのジェネリック符号化規則を使用することで表されます。
3.1.2 Operation IDs and Request IDs
3.1.2 操作免疫不全症候群と要求免疫不全症候群
Each IPP operation request includes an identifying "operation-id" value. Valid values are defined in the "operations-supported" Printer attribute section (see section 4.4.15). The client specifies which operation is being requested by supplying the correct "operation-id" value.
それぞれのIPP操作要求は特定「操作イド」値を含んでいます。 有効値は「操作でサポートしている」Printer属性部で定義されます(セクション4.4.15を見てください)。 クライアントは、どの操作が正しい「操作イド」値を供給することによって要求されているかを指定します。
In addition, every invocation of an operation is identified by a "request-id" value. For each request, the client chooses the "request-id" which MUST be an integer (possibly unique depending on client requirements) in the range from 1 to 2**31 - 1 (inclusive). This "request-id" allows clients to manage multiple outstanding requests. The receiving IPP object copies all 32-bits of the client- supplied "request-id" attribute into the response so that the client can match the response with the correct outstanding request, even if the "request-id" is out of range. If the request is terminated before the complete "request-id" is received, the IPP object rejects the request and returns a response with a "request-id" of 0.
さらに、操作のあらゆる実施が「要求イド」値によって特定されます。 各要求のために、クライアントは(包括的)で1〜2までの範囲の整数であるに違いない(クライアント要件へのことによるとユニークな依存)「要求イド」**31--1を選びます。 この「要求イド」で、クライアントは複数の傑出している要求を管理できます。 受信IPPオブジェクトはクライアントが正しい傑出している要求に応答に合うことができるように、クライアントの供給された「要求イド」属性のすべての32ビットを応答にコピーします、「要求イド」が範囲から脱していても。 完全な「要求イド」が受け取られている前に要求が終えられるなら、IPPオブジェクトは、0の「要求イド」と共に要求を拒絶して、応答を返します。
Note: In some cases, the transport protocol underneath IPP might be a connection oriented protocol that would make it impossible for a client to receive responses in any order other than the order in which the corresponding requests were sent. In such cases, the "request-id" attribute would not be essential for correct protocol operation. However, in other mappings, the operation responses can come back in any order. In these cases, the "request-id" would be essential.
以下に注意してください。 いくつかの場合、IPPの下のトランスポート・プロトコルはクライアントが対応する要求が送られたオーダーを除いて、順不同な応答を受け取るのを不可能にする接続指向のプロトコルであるかもしれません。 そのような場合、正しいプロトコル操作には、「要求イド」属性は不可欠でないでしょう。 しかしながら、他のマッピングでは、操作応答は順不同に戻ることができます。 これらの場合では、「要求イド」は不可欠でしょう。
3.1.3 Attributes
3.1.3 属性
Operation requests and responses are both composed of groups of attributes and/or document data. The attributes groups are:
操作要求と応答は属性、そして/または、ドキュメントデータのグループでともに構成されます。 属性グループは以下の通りです。
- Operation Attributes: These attributes are passed in the
operation and affect the IPP object's behavior while processing
the operation request and may affect other attributes or groups
of attributes. Some operation attributes describe the document
data associated with the print job and are associated with new
Job objects, however most operation attributes do not persist
beyond the life of the operation. The description of each
operation attribute includes conformance statements indicating
which operation attributes are REQUIRED and which are OPTIONAL
- 操作属性: これらの属性は、操作で通過されて、操作要求を処理している間、IPPオブジェクトの行動に影響して、属性の他の属性かグループに影響するかもしれません。 いくつかの操作属性が印刷仕事に関連しているドキュメントデータについて説明して、新しいJobオブジェクトに関連している、しかしながら、ほとんどの操作属性は操作の寿命を超えて持続していません。 それぞれの操作属性の記述はどの操作属性がREQUIREDであるか、そして、どれがOPTIONALであるかを示す順応声明を含んでいます。
Hastings, et al. Standards Track [Page 22] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[22ページ]: モデルと意味論2000年9月
for an IPP object to support and which attributes a client MUST
supply in a request and an IPP object MUST supply in a response.
- Job Template Attributes: These attributes affect the processing
of a job. A client OPTIONALLY supplies Job Template Attributes
in a create request, and the receiving object MUST be prepared
to receive all supported attributes. The Job object can later
be queried to find out what Job Template attributes were
originally requested in the create request, and such attributes
are returned in the response as Job Object Attributes. The
Printer object can be queried about its Job Template attributes
to find out what type of job processing capabilities are
supported and/or what the default job processing behaviors are,
though such attributes are returned in the response as Printer
Object Attributes. The "ipp-attribute-fidelity" operation
attribute affects processing of all client-supplied Job Template
attributes (see sections 3.2.1.2 and 15 for a full description
of "ipp-attribute-fidelity" and its relationship to other
attributes).
- Job Object Attributes: These attributes are returned in response
to a query operation directed at a Job object.
- Printer Object Attributes: These attributes are returned in
response to a query operation directed at a Printer object.
- Unsupported Attributes: In a create request, the client supplies
a set of Operation and Job Template attributes. If any of these
attributes or their values is unsupported by the Printer object,
the Printer object returns the set of unsupported attributes in
the response. Sections 3.1.7, 3.2.1.2, and 15 give a full
description of how Job Template attributes supplied by the
client in a create request are processed by the Printer object
and how unsupported attributes are returned to the client.
Because of extensibility, any IPP object might receive a request
that contains new or unknown attributes or values for which it
has no support. In such cases, the IPP object processes what it
can and returns the unsupported attributes in the response. The
Unsupported Attribute group is defined for all operation
responses for returning unsupported attributes that the client
supplied in the request.
どの属性をサポートとクライアントが要求で供給しなければならなくて、IPPオブジェクトが応答で供給しなければならないかへのIPPオブジェクトのために。 - 仕事のテンプレート属性: これらの属性は仕事の処理に影響します。 aのクライアントOPTIONALLY供給Job Template Attributesは要求を作成します、そして、属性であるとサポートされたすべてを受けるように受信オブジェクトを準備しなければなりません。 後でJob Template属性が元々何で要求されたかを見つけるためにJobオブジェクトについて質問できる、属性がJob Object Attributesとして応答で返される要求、およびそのようなものを作成してください。 どんな仕事の種類処理能力がサポートされるか、そして、デフォルトジョブ処理の振舞いが何であるかを見つけるためにJob Template属性に関してPrinterオブジェクトについて質問できます、そのような属性はPrinter Object Attributesとして応答で返されますが。 「ipp属性信義」操作属性はすべてのクライアントによって供給されたJob Template属性の処理に影響します(「ipp属性信義」ともう一方とのその関係の余すところのない解説のための.2と15が結果と考えるセクション3.2.1を見てください)。 - 仕事のオブジェクト属性: これらの属性はJobオブジェクトが向けられた質問操作に対応して返されます。 - プリンタオブジェクト属性: これらの属性はPrinterオブジェクトが向けられた質問操作に対応して返されます。 - サポートされない属性: aでは、要求を作成してください、そして、クライアントは1セットのOperationとJob Template属性を供給します。 これらの属性かそれらの値のどれかがPrinterオブジェクトでサポートされないなら、Printerオブジェクトは応答におけるサポートされない属性のセットを返します。 セクション3.1 .7 3.2 .1 .2、および15は属性が中のaが創造するクライアントで要求を提供したJob TemplateがPrinterオブジェクトによってどのように処理されるか、そして、サポートされない属性がどのようにクライアントに返されるかに関する余すところのない解説を与えます。 伸展性のために、どんなIPP目的も新しいか未知の属性を含む要求かそれがサポートを全く持っていない値を受け取るかもしれません。 そのような場合、IPPオブジェクトは、それが処理できることを処理して、応答におけるサポートされない属性を返します。 Unsupported Attributeグループはクライアントが要求で供給した戻っているサポートされない属性のためのすべての操作応答のために定義されます。
Later in this section, each operation is formally defined by identifying the allowed and expected groups of attributes for each request and response. The model identifies a specific order for each group in each request or response, but the attributes within each group may be in any order, unless specified otherwise.
その後、このセクションでは、各操作は、各要求と応答のために属性の許容されて予想されたグループを特定することによって、正式に定義されます。 モデルは各要求か応答におけるそれぞれのグループの特定の注文を特定しますが、各グループの中の属性は順不同であるかもしれません、別の方法で指定されない場合。
The attributes within a group MUST be unique; if an attribute with the same name occurs more than once, the group is mal-formed. Clients MUST NOT submit such malformed requests and Printers MUST NOT return such malformed responses. If such a malformed request is
グループの中の属性はユニークであるに違いありません。 同じ名前がある属性が一度より起こるなら、グループは悪-結成されます。 クライアントはそのような奇形の要求を提出してはいけません、そして、Printersはそのような奇形の応答を返してはいけません。 そのような奇形の要求がそうなら
Hastings, et al. Standards Track [Page 23] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[23ページ]: モデルと意味論2000年9月
submitted to a Printer, the Printer MUST either (1) reject the request with the 'client-error-bad-request' status code (see section 13.1.4.1) or (2) process the request normally after selecting only one of the attribute instances, depending on implementation. Which attribute is selected when there are duplicate attributes depends on implementation. The IPP Printer MUST NOT use the values from more than one such duplicate attribute instance.
(1)は'クライアントの誤りの悪い要求'ステータスコードで要求を拒絶しなければなりません。Printer、Printerに提出する、(属性インスタンスの1つだけを選択した後に通常、セクション13.1.4の.1か)(2)が要求を処理するのを見てください、実装によって。 写し属性があるとき、どの属性が選択されるかは実装によります。 IPP Printerはそのようなインスタンスの、より写しより属性1つ以上から値を使用してはいけません。
Each attribute definition includes the attribute's name followed by the name of its attribute syntax(es) in parenthesizes. In addition, each 'integer' attribute is followed by the allowed range in parentheses, (m:n), for values of that attribute. Each 'text' or 'name' attribute is followed by the maximum size in octets in parentheses, (size), for values of that attribute. For more details on attribute syntax notation, see the descriptions of these attributes syntaxes in section 4.1.
定義が属性構文(es)の名前があとに続いた属性の名前を含む各属性はparenthesizesされます。 さらに、許容範囲はその属性の値のために括弧、(m: n)でそれぞれの'整数'属性のあとに続いています。 括弧の八重奏における最大サイズはそれぞれの'テキスト'か'名前'属性のあとに続いています、(サイズ)、その属性の値のために。 属性構文記法に関するその他の詳細に関しては、セクション4.1のこれらの属性構文の記述を見てください。
Note: Document data included in the operation is not strictly an attribute, but it is treated as a special attribute group for ordering purposes. The only operations that support supplying the document data within an operation request are Print-Job and Send- Document. There are no operation responses that include document data.
以下に注意してください。 操作に含まれていたドキュメントデータは全く、属性、しかし、それがあるということではありません。注文目的のために特別な属性グループとして扱われます。 操作要求の中で供給がドキュメントデータであるとサポートする唯一の操作がPrint-仕事とSendドキュメントです。 ドキュメントデータを含んでいる操作応答が全くありません。
Some operations are REQUIRED for IPP objects to support; the others are OPTIONAL (see section 5.2.2). Therefore, before using an OPTIONAL operation, a client SHOULD first use the REQUIRED Get- Printer-Attributes operation to query the Printer's "operations- supported" attribute in order to determine which OPTIONAL Printer and Job operations are actually supported. The client SHOULD NOT use an OPTIONAL operation that is not supported. When an IPP object receives a request to perform an operation it does not support, it returns the 'server-error-operation-not-supported' status code (see section 13.1.5.2). An IPP object is non-conformant if it does not support a REQUIRED operation.
いくつかの操作が支えるIPPオブジェクトのためのREQUIREDです。 他のものはOPTIONAL(セクション5.2.2を見る)です。 したがって、OPTIONAL操作を使用するクライアントSHOULDが最初にどのOPTIONAL PrinterとJobを決定するかためにPrinterの「サポートされた操作」属性について質問するのにREQUIRED Getプリンタ属性操作を使用する前に操作は実際にサポートされます。 クライアントSHOULD NOTはサポートされないOPTIONAL操作を使用します。 セクション13.1を見てください。IPP目的がそれがサポートしない操作を実行するという要求を受け取るとき、'操作がサポートしなかったサーバ誤り'ステータスコードを返す、(.5 .2)。 REQUIREDが操作であるとサポートしないなら、IPPオブジェクトは非conformantです。
3.1.4 Character Set and Natural Language Operation Attributes
3.1.4 文字コードと自然言語操作属性
Some Job and Printer attributes have values that are text strings and names intended for human understanding rather than machine understanding (see the 'text' and 'name' attribute syntax descriptions in section 4.1). The following sections describe two special Operation Attributes called "attributes-charset" and "attributes-natural-language". These attributes are always part of the Operation Attributes group. For most attribute groups, the order of the attributes within the group is not important. However, for these two attributes within the Operation Attributes group, the order is critical. The "attributes-charset" attribute MUST be the first
いくらかのJobとPrinter属性で、マシン理解よりむしろ人知のためにテキスト文字列である値と名前を意図します(セクション4.1の'テキスト'と'名前'属性構文記述を見てください)。 以下のセクションは「属性-charsetと属性自然言語」と呼ばれる2特別なOperation Attributesについて説明します。 いつもこれらの属性はOperation Attributesグループの一部です。 ほとんどの属性グループにおいて、グループの中の属性の注文は重要ではありません。 しかしながら、Operation Attributesグループの中のこれらの2つの属性において、オーダーは重要です。 「属性-charset」属性は1番目であるに違いありません。
Hastings, et al. Standards Track [Page 24] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[24ページ]: モデルと意味論2000年9月
attribute in the group and the "attributes-natural-language" attribute MUST be the second attribute in the group. In other words, these attributes MUST be supplied in every IPP request and response, they MUST come first in the group, and MUST come in the specified order. For job creation operations, the IPP Printer implementation saves these two attributes with the new Job object as Job Description attributes. For the sake of brevity in this document, these operation attribute descriptions are not repeated with every operation request and response, but have a reference back to this section instead.
グループにおける属性と「属性自然言語」属性はグループで2番目の属性であるに違いありません。 言い換えれば、あらゆるIPP要求と応答でこれらの属性を供給しなければならなくて、それらは、グループで一番にならなければならなくて、指定された順序で来なければなりません。 雇用創出操作のために、IPP Printer実装はJob記述属性として新しいJobオブジェクトでこれらの2つの属性を節約します。 簡潔にするためにこのドキュメントでは、これらの操作属性記述はあらゆる操作要求と応答のときに繰り返されるというわけではありませんが、代わりにこのセクションに参照を返してもらってください。
3.1.4.1 Request Operation Attributes
3.1.4.1 操作属性を要求してください。
The client MUST supply and the Printer object MUST support the following REQUIRED operation attributes in every IPP/1.1 operation request:
クライアントは供給しなければならなくて、PrinterオブジェクトはあらゆるIPP/1.1操作における属性が要求する以下のREQUIRED操作をサポートしなければなりません:
"attributes-charset" (charset):
This operation attribute identifies the charset (coded
character set and encoding method) used by any 'text' and
'name' attributes that the client is supplying in this request.
It also identifies the charset that the Printer object MUST use
(if supported) for all 'text' and 'name' attributes and status
messages that the Printer object returns in the response to
this request. See Sections 4.1.1 and 4.1.2 for the definition
of the 'text' and 'name' attribute syntaxes.
「属性-charset」(charset): この操作属性はクライアントがこの要求で供給しているどんな'テキスト'と'名前'属性によっても使用されるcharset(コード化文字集合とメソッドをコード化する)を特定します。 また、それはPrinterオブジェクトがすべての'テキスト'と'名前'属性に使用しなければならない(サポートされるなら)charsetとPrinterオブジェクトがこの要求への応答で返すステータスメッセージを特定します。 セクション4.1.1を見てください。そうすれば、4.1に、'テキスト'と'名前'の定義のための.2は構文を結果と考えます。
All clients and IPP objects MUST support the 'utf-8' charset
[RFC2279] and MAY support additional charsets provided that
they are registered with IANA [IANA-CS]. If the Printer object
does not support the client supplied charset value, the Printer
object MUST reject the request, set the "attributes-charset" to
'utf-8' in the response, and return the 'client-error-charset-
not-supported' status code and any 'text' or 'name' attributes
using the 'utf-8' charset. The Printer NEED NOT return any
attributes in the Unsupported Attributes Group (See sections
3.1.7 and 3.2.1.2). The Printer object MUST indicate the
charset(s) supported as the values of the "charset-supported"
Printer attribute (see Section 4.4.18), so that the client can
query to determine which charset(s) are supported.
すべてのクライアントとIPPオブジェクトは、'utf-8'がcharset[RFC2279]であるとサポートしなければならなくて、それらがIANA[IANA-CS]に登録されれば、追加charsetsをサポートするかもしれません。 Printerオブジェクトがクライアントの供給されたcharset価値をサポートしないなら、'utf-8'charsetを使用して、Printerオブジェクトは、要求を拒絶して、応答で「属性-charset」を'utf-8'に設定して、'クライアント誤り-charsetによってサポートしていない'ステータスコードとどんな'テキスト'か'名前'属性も返さなければなりません。 セクション3.1.7と3.2を見てください。PrinterがUnsupported Attributes Groupでどんな属性も返す必要はない、(.1 .2)。 Printerオブジェクトは「charsetによってサポートしている」Printer属性の値としてサポートされたcharset(s)を示さなければなりません(セクション4.4.18を見てください)、クライアントが、どのcharset(s)がサポートされるかを決定するのを質問できるように。
Note to client implementers: Since IPP objects are only
required to support the 'utf-8' charset, in order to maximize
interoperability with multiple IPP object implementations, a
client may want to supply 'utf-8' in the "attributes-charset"
operation attribute, even though the client is only passing and
able to present a simpler charset, such as US-ASCII [ASCII] or
ISO-8859-1 [ISO8859-1]. Then the client will have to filter
クライアントimplementersに以下に注意してください。 IPPオブジェクトが、'utf-8'がcharsetであるとサポートするだけでよいので、クライアントは複数のIPPオブジェクト実装で相互運用性を最大にするために「属性-charset」操作属性で'utf-8'を供給したがっているかもしれません、クライアントは、通っているだけであり、より簡単なcharsetを寄贈できますが、米国-ASCII[ASCII]やISO-8859-1[ISO8859-1]のように。 クライアントがフィルターにかけなければならないその時
Hastings, et al. Standards Track [Page 25] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[25ページ]: モデルと意味論2000年9月
out (or charset convert) those characters that are returned in
the response that it cannot present to its user. On the other
hand, if both the client and the IPP objects also support a
charset in common besides utf-8, the client may want to use
that charset in order to avoid charset conversion or data loss.
それがユーザに提示できない応答で返されるそれらの(または、charset転向者)キャラクタから。 他方では、また、クライアントとIPPオブジェクトの両方がutf-8以外に一般的でcharsetをサポートするなら、クライアントは、charset変換かデータの損失を避けるのにそのcharsetを使用したがっているかもしれません。
See the 'charset' attribute syntax description in Section 4.1.7
for the syntax and semantic interpretation of the values of
this attribute and for example values.
この属性と例えば、値の値の構文と意味解釈に関してセクション4.1.7における'charset'属性構文記述を見てください。
"attributes-natural-language" (naturalLanguage):
This operation attribute identifies the natural language used
by any 'text' and 'name' attributes that the client is
supplying in this request. This attribute also identifies the
natural language that the Printer object SHOULD use for all
'text' and 'name' attributes and status messages that the
Printer object returns in the response to this request. See
the 'naturalLanguage' attribute syntax description in section
4.1.8 for the syntax and semantic interpretation of the values
of this attribute and for example values.
「属性自然言語」(naturalLanguage): この操作属性はクライアントがこの要求で供給しているどんな'テキスト'と'名前'属性によっても使用される自然言語を特定します。 また、この属性はPrinterオブジェクトSHOULDがすべての'テキスト'と'名前'属性に使用する自然言語とPrinterオブジェクトがこの要求への応答で返すステータスメッセージを特定します。 この属性と例えば、値の値の構文と意味解釈に関してセクション4.1.8における'naturalLanguage'属性構文記述を見てください。
There are no REQUIRED natural languages required for the
Printer object to support. However, the Printer object's
"generated-natural-language-supported" attribute identifies the
natural languages supported by the Printer object and any
contained Job objects for all text strings generated by the IPP
object. A client MAY query this attribute to determine which
natural language(s) are supported for generated messages.
REQUIREDが全くありません。自然言語が支えるPrinterオブジェクトに必要です。 しかしながら、Printerオブジェクトの「サポートされた発生している自然な言語」属性はIPPオブジェクトによって生成されたすべてのテキスト文字列のためにPrinterオブジェクトとどんな含まれたJobオブジェクトによってもサポートされた自然言語を特定します。 クライアントは、どの自然言語が発生しているメッセージのためにサポートされるかを決定するためにこの属性について質問するかもしれません。
For any of the attributes for which the Printer object
generates text, i.e., for the "job-state-message", "printer-
state-message", and status messages (see Section 3.1.6), the
Printer object MUST be able to generate these text strings in
any of its supported natural languages. If the client requests
a natural language that is not supported, the Printer object
MUST return these generated messages in the Printer's
configured natural language as specified by the Printer's
"natural-language-configured" attribute" (see Section 4.4.19).
すなわち、Printerオブジェクトがテキストを作る属性のどれか、「仕事の州のメッセージ」、「プリンタ州メッセージ」、およびステータスメッセージ(セクション3.1.6を見る)に関しては、Printerオブジェクトはサポートしている自然言語のいずれでもこれらのテキスト文字列を生成することができなければなりません。 「クライアントがサポートされない自然言語を要求するなら、Printerオブジェクトは指定されるとしてのPrinterの「構成された自然な言語」属性によるPrinterの構成された自然言語のメッセージであると生成されたこれらを返さなければならない」(セクション4.4.19を見てください)。
For other 'text' and 'name' attributes supplied by the client,
authentication system, operator, system administrator, or
manufacturer (i.e., for "job-originating-user-name", "printer-
name" (name), "printer-location" (text), "printer-info" (text),
and "printer-make-and-model" (text)), the Printer object is
only required to support the configured natural language of the
クライアント、認証システム、オペレータ、システム管理者、またはメーカー(すなわち、「仕事の起因するユーザ名」、「プリンタ名」(名前)、「プリンタ位置」(テキスト)、「プリンタインフォメーション」(テキスト)、および「プリンタメーカーとモデル」(テキスト)のための)によって供給された他の'テキスト'と'名前'属性、オブジェクトが構成された自然言語をサポートしているだけでよいPrinter
Hastings, et al. Standards Track [Page 26] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[26ページ]: モデルと意味論2000年9月
Printer identified by the Printer object's "natural-language-
configured" attribute, though support of additional natural
languages for these attributes is permitted.
これらの属性のための追加自然言語のサポートは受入れられますが、Printerオブジェクトによって特定されたプリンタは「当然の言語で構成された」属性です。
For any 'text' or 'name' attribute in the request that is in a
different natural language than the value supplied in the
"attributes-natural-language" operation attribute, the client
MUST use the Natural Language Override mechanism (see sections
4.1.1.2 and 4.1.2.2) for each such attribute value supplied.
The client MAY use the Natural Language Override mechanism
redundantly, i.e., use it even when the value is in the same
natural language as the value supplied in the "attributes-
natural-language" operation attribute of the request.
そして、異なった自然言語にはある要求におけるどんな'テキスト'か'名前'属性にも、クライアントが値が「属性自然言語」操作属性で供給したよりNatural Language Overrideメカニズムを使用しなければならない、(セクション4.1.1を見てください、.2、4.1 .2 .2) そのような属性値が供給したそれぞれのために。 クライアントは冗長にNatural Language Overrideメカニズムを使用するかもしれません、すなわち、操作が結果と考える要求の「属性自然言語」で供給された値と同じ自然言語に値がありさえするときにはそれを使用してください。
The IPP object MUST accept any natural language and any Natural
Language Override, whether the IPP object supports that natural
language or not (and independent of the value of the "ipp-
attribute-fidelity" Operation attribute). That is the IPP
object accepts all client supplied values no matter what the
values are in the Printer object's "generated-natural-
language-supported" attribute. That attribute, "generated-
natural-language-supported", only applies to generated
messages, not client supplied messages. The IPP object MUST
remember that natural language for all client-supplied
attributes, and when returning those attributes in response to
a query, the IPP object MUST indicate that natural language.
IPPオブジェクトはどんな自然言語とどんなNatural Language Overrideも受け入れなければなりません、IPPオブジェクトがその自然言語をサポートする(そして「ipp属性信義」Operation属性の値の如何にかかわらず)か否かに関係なく。 すなわち、IPPオブジェクトは値がPrinterオブジェクトの「発生して自然に言語でサポートしている」属性において何であってもすべてのクライアント供給値を受け入れます。 「サポートされた自然な言語であると生成された」その属性はクライアントの供給されたメッセージではなく、発生しているメッセージに適用されるだけです。 IPP目的はすべてのクライアントによって供給された属性のためにその自然言語を覚えていなければなりません、そして、質問に対応してそれらの属性を返すとき、IPPオブジェクトはその自然言語を示さなければなりません。
Each value whose attribute syntax type is 'text' or 'name' (see
sections 4.1.1 and 4.1.2) has an Associated Natural-Language.
This document does not specify how this association is stored
in a Printer or Job object. When such a value is encoded in a
request or response, the natural language is either implicit or
explicit:
各値は、属性構文が、タイプする'テキスト'かセクション4.1.1を見て、'名前'です。(4.1に、.2は)Associated Natural-言語を持っています。 このドキュメントはこの協会がPrinterかJobオブジェクトにどう保存されるかを指定しません。 そのような値が要求か応答でコード化されるとき、自然言語は、暗黙である、または明白です:
- In the implicit case, the value contains only the text/name
value, and the language is specified by the "attributes-
natural-language" operation attribute in the request or
response (see sections 4.1.1.1 textWithoutLanguage and
4.1.2.1 nameWithoutLanguage).
- 内在している場合に、値がテキスト/名義の値だけを含んでいて、言語が操作が要求か応答で結果と考える「属性自然言語」によって指定される、(セクション4.1.1を見てください、.1textWithoutLanguageと4.1、.2、.1nameWithoutLanguage)
- In the explicit case (also known as the Natural-Language
Override case), the value contains both the language and the
text/name value (see sections 4.1.1.2 textWithLanguage and
4.1.2.2 nameWithLanguage).
- 明白な場合(また、Natural-言語Overrideケースとして、知られている)に、値が言語と値というテキスト/名前の両方を含んでいる、(セクション4.1.1を見てください、.2textWithLanguageと4.1、.2、.2nameWithLanguage)
For example, the "job-name" attribute MAY be supplied by the
client in a create request. The text value for this attribute
will be in the natural language identified by the "attribute-
例えば、属性がaでクライアントによって供給されるかもしれない「ジョブ名」は要求を作成します。 「属性」によって特定された自然言語にはこの属性のためのテキスト値があるでしょう。
Hastings, et al. Standards Track [Page 27] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[27ページ]: モデルと意味論2000年9月
natural-language" attribute, or if different, as identified by
the Natural Language Override mechanism. If supplied, the IPP
object will use the value of the "job-name" attribute to
populate the Job object's "job-name" attribute. Whenever any
client queries the Job object's "job-name" attribute, the IPP
object returns the attribute as stored and uses the Natural
Language Override mechanism to specify the natural language, if
it is different from that reported in the "attributes-natural-
language" operation attribute of the response. The IPP object
MAY use the Natural Language Override mechanism redundantly,
i.e., use it even when the value is in the same natural
language as the value supplied in the "attributes-natural-
language" operation attribute of the response.
「自然言語」属性、特定されるとして、Natural Language Overrideメカニズムで、異なります。 供給すると、IPPオブジェクトは、Jobオブジェクトの「ジョブ名」属性に居住するのに「ジョブ名」属性の値を使用するでしょう。 どんなクライアントもJobオブジェクトの「ジョブ名」属性について質問するときはいつも、IPPオブジェクトは、保存されるように属性を返して、自然言語を指定するのにNatural Language Overrideメカニズムを使用します、それが応答の「属性当然の言語」の操作属性で報告されたそれと異なるなら。 IPPオブジェクトは冗長にNatural Language Overrideメカニズムを使用するかもしれません、すなわち、応答の「属性当然の言語」の操作属性で供給された値と同じ自然言語に値がありさえするときにはそれを使用してください。
An IPP object MUST NOT reject a request based on a supplied
natural language in an "attributes-natural-language" Operation
attribute or in any attribute that uses the Natural Language
Override.
IPPオブジェクトは「属性自然言語」Operation属性かNatural Language Overrideを使用するどんな属性でも供給された自然言語に基づく要求を拒絶してはいけません。
Clients SHOULD NOT supply 'text' or 'name' attributes that use an illegal combination of natural language and charset. For example, suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and 'iso-8859-7'. Suppose also, that it supports natural languages 'en' (English), 'fr' (French), and 'el' (Greek). Although the Printer object supports the charset 'iso-8859-1' and natural language 'el', it probably does not support the combination of Greek text strings using the 'iso-8859-1' charset. The Printer object handles this apparent incompatibility differently depending on the context in which it occurs:
クライアントSHOULD NOTは自然言語とcharsetの不法な組み合わせを使用する'テキスト'か'名前'属性を供給します。 例えば、Printerオブジェクトが、charsetsが'utf-8'と、'iso-8859-1'と、'iso-8859-7'であるとサポートすると仮定してください。 それも仮定してください。それは、自然言語が'アン'(イギリスの)と、'fr'(フランスの)と、'高架鉄道'(ギリシア語)であるとサポートします。 Printerオブジェクトはcharset'iso-8859-1'と自然言語'高架鉄道'をサポートしますが、それは、たぶん'iso-8859-1'charsetを使用することでギリシアのテキスト文字列の組み合わせをサポートしません。 Printerオブジェクトはそれが起こる文脈に異なってよるこの見かけの不一致を処理します:
- In a create request: If the client supplies a text or name
attribute (for example, the "job-name" operation attribute) that
uses an apparently incompatible combination, it is a client
choice that does not affect the Printer object or its correct
operation. Therefore, the Printer object simply accepts the
client supplied value, stores it with the Job object, and
responds back with the same combination whenever the client (or
any client) queries for that attribute.
- In a query-type operation, like Get-Printer-Attributes: If the
client requests an apparently incompatible combination, the
Printer object responds (as described in section 3.1.4.2) using
the Printer's configured natural language rather than the
natural language requested by the client.
- aでは、要求を作成してください: クライアントが明らかに両立しない組み合わせを使用するテキストか名前属性(例えば、「ジョブ名」操作属性)を供給するなら、それはPrinterオブジェクトかその正しい操作に影響しないクライアント選択です。 したがって、クライアント(または、どんなクライアントも)がそれのために属性について質問するときはいつも、Printerオブジェクトは、単にクライアント供給値を受け入れて、Jobオブジェクトでそれを保存して、同じ組み合わせで応じます。 - Getプリンタ属性のような質問タイプ操作で: クライアントが明らかに両立しない組み合わせを要求するなら、Printerオブジェクトは、クライアントによって要求された自然言語よりむしろPrinterの構成された自然言語を使用することで応じます(セクション3.1.4で.2について説明するので)。
In either case, the Printer object does not reject the request because of the apparent incompatibility. The potential incompatible combination of charset and natural language can occur either at the global operation level or at the Natural Language Override
どちらの場合ではも、Printerオブジェクトは見かけの不一致で要求を拒絶しません。 charsetと自然言語の潜在的両立しない組み合わせはグローバルなオペレーションレベルにおいて、または、Natural Language Overrideに起こることができます。
Hastings, et al. Standards Track [Page 28] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[28ページ]: モデルと意味論2000年9月
attribute-by-attribute level. In addition, since the response always includes explicit charset and natural language information, there is never any question or ambiguity in how the client interprets the response.
属性ごとのレベル。 さらに、応答がいつも明白なcharsetと自然言語情報を含んでいるので、クライアントがどう応答を解釈するかのどんな質問やあいまいさも決してありません。
3.1.4.2 Response Operation Attributes
3.1.4.2 応答操作属性
The Printer object MUST supply and the client MUST support the following REQUIRED operation attributes in every IPP/1.1 operation response:
Printerオブジェクトは供給しなければならなくて、クライアントはあらゆるIPP/1.1操作応答における以下のREQUIRED操作属性をサポートしなければなりません:
"attributes-charset" (charset):
This operation attribute identifies the charset used by any
'text' and 'name' attributes that the Printer object is
returning in this response. The value in this response MUST be
the same value as the "attributes-charset" operation attribute
supplied by the client in the request. If this is not possible
(i.e., the charset requested is not supported), the request
would have been rejected. See "attributes-charset" described
in Section 3.1.4.1 above.
「属性-charset」(charset): この操作属性はPrinterオブジェクトがこの応答で返しているどんな'テキスト'と'名前'属性によっても使用されるcharsetを特定します。 この応答における値は要求でクライアントによって供給された「属性-charset」操作属性と同じ値でなければなりません。 これが可能でないなら(すなわち、要求されたcharsetはサポートされません)、要求は拒絶されたでしょう。 セクション3.1.4で説明された「属性-charset」.1が上であることを見てください。
If the Printer object supports more than just the 'utf-8'
charset, the Printer object MUST be able to code convert
between each of the charsets supported on a highest fidelity
possible basis in order to return the 'text' and 'name'
attributes in the charset requested by the client. However,
some information loss MAY occur during the charset conversion
depending on the charsets involved. For example, the Printer
object may convert from a UTF-8 'a' to a US-ASCII 'a' (with no
loss of information), from an ISO Latin 1 CAPITAL LETTER A WITH
ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a
UTF-8 Japanese Kanji character to some ISO Latin 1 error
character indication such as '?', decimal code equivalent, or
to the absence of a character, depending on implementation.
Printerオブジェクトがまさしく'utf-8'charset以上をサポートするなら、Printerオブジェクトは、クライアントによって要求されたcharsetで'テキスト'と'名前'属性を返すために可能な限り高い信義ベースでサポートされたそれぞれのcharsetsの間で転向者をコード化できなければなりません。 しかしながら、いくらかの情報の損失がかかわったcharsetsによるcharset変換の間、発生するかもしれません。 例えば、PrinterオブジェクトはUTF-8 'a'から米国-ASCII'a'(情報の損失のない)までISOラテン語1CAPITAL LETTER A WITH ACUTE ACCENTから米国-ASCII'A'(アクセントを失う)まで'?'などの1つの誤りのいくつかのISOのラテン語のキャラクタしるし、10進コード同等物、または、キャラクタの欠如へのUTF-8の日本人の漢字から変換されるかもしれません、実装によって。
Whether an implementation that supports more than one charset
stores the data in the charset supplied by the client or code
converts to one of the other supported charsets, depends on
implementation. The strategy should try to minimize loss of
information during code conversion. On each response, such an
implementation converts from its internal charset to that
requested.
1charsetをサポートする実装がクライアントかコードによって供給されたcharsetのデータを保存するかどうかが、charsetsであるとサポートされたもう片方の1つに変えて、実装によります。 戦略はコード変換の間、情報の損失を最小にしようとするべきです。 各応答のときに、そのような実装は内部のcharsetから要求されたそれまで変換されます。
"attributes-natural-language" (naturalLanguage):
This operation attribute identifies the natural language used
by any 'text' and 'name' attributes that the IPP object is
returning in this response. Unlike the "attributes-charset"
operation attribute, the IPP object NEED NOT return the same
「属性自然言語」(naturalLanguage): この操作属性はIPPオブジェクトがこの応答で返しているどんな'テキスト'と'名前'属性によっても使用される自然言語を特定します。 「属性-charset」操作属性と異なって、IPPオブジェクトは同じように戻る必要はありません。
Hastings, et al. Standards Track [Page 29] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[29ページ]: モデルと意味論2000年9月
value as that supplied by the client in the request. The IPP
object MAY return the natural language of the Job object or the
Printer's configured natural language as identified by the
Printer object's "natural-language-configured" attribute,
rather than the natural language supplied by the client. For
any 'text' or 'name' attribute or status message in the
response that is in a different natural language than the value
returned in the "attributes-natural-language" operation
attribute, the IPP object MUST use the Natural Language
Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on each
attribute value returned. The IPP object MAY use the Natural
Language Override mechanism redundantly, i.e., use it even when
the value is in the same natural language as the value supplied
in the "attributes-natural-language" operation attribute of the
response.
要求におけるクライアントによるそんなに供給されるとしての値。 IPPオブジェクトはクライアントによって供給された自然言語よりむしろPrinterオブジェクトの「構成された自然な言語」属性によって特定されるようにJobオブジェクトかPrinterの構成された自然言語の自然言語を返すかもしれません。 そして、異なった自然言語にはある応答におけるどんな'テキスト'か'名前'属性やステータスメッセージにも、IPPオブジェクトが値が「属性自然言語」操作属性で返したよりNatural Language Overrideメカニズムを使用しなければならない、(セクション4.1.1を見てください、.2、4.1 .2 .2) 各属性では、値は戻りました。 IPPオブジェクトは冗長にNatural Language Overrideメカニズムを使用するかもしれません、すなわち、応答の「属性自然言語」操作属性で供給された値と同じ自然言語に値がありさえするときにはそれを使用してください。
3.1.5 Operation Targets
3.1.5 操作目標
All IPP operations are directed at IPP objects. For Printer operations, the operation is always directed at a Printer object using one of its URIs (i.e., one of the values in the Printer object's "printer-uri-supported" attribute). Even if the Printer object supports more than one URI, the client supplies only one URI as the target of the operation. The client identifies the target object by supplying the correct URI in the "printer-uri (uri)" operation attribute.
IPPオブジェクトはすべてのIPP操作に向けられます。 Printer操作において、URIの1つを使用することで(すなわち、Printerオブジェクトの「uriが支えたプリンタ」属性における値の1つ)Printerオブジェクトは操作にいつも向けられます。 Printerオブジェクトが1つ以上のURIをサポートしても、クライアントは操作の目標として1つのURIだけを供給します。 クライアントは、「プリンタ-uri(uri)」操作属性における正しいURIを供給することによって、目標オブジェクトを特定します。
For Job operations, the operation is directed at either:
Job操作において、どちらかが操作に向けられます:
- The Job object itself using the Job object's URI. In this case,
the client identifies the target object by supplying the correct
URI in the "job-uri (uri)" operation attribute.
- The Printer object that created the Job object using both the
Printer objects URI and the Job object's Job ID. Since the
Printer object that created the Job object generated the Job ID,
it MUST be able to correctly associate the client supplied Job
ID with the correct Job object. The client supplies the Printer
object's URI in the "printer-uri (uri)" operation attribute and
the Job object's Job ID in the "job-id (integer(1:MAX))"
operation attribute.
- Job自身は、JobオブジェクトのURIを使用することで反対します。 この場合、クライアントは、「仕事-uri(uri)」操作属性における正しいURIを供給することによって、目標オブジェクトを特定します。 - 両方のPrinterオブジェクトのURIとJobオブジェクトのJob IDを使用することでJobオブジェクトを作成したPrinterオブジェクト。 Jobオブジェクトを作成したPrinterオブジェクトがJob IDを生成したので、それは正しくクライアントの供給されたJob IDを正しいJobオブジェクトに関連づけることができなければなりません。 クライアントは「仕事イド(整数(1: MAX))」操作属性における「プリンタ-uri(uri)」操作属性とJobオブジェクトのJob IDでPrinterオブジェクトのURIを供給します。
If the operation is directed at the Job object directly using the Job object's URI, the client MUST NOT include the redundant "job-id" operation attribute.
Jobオブジェクトが直接JobオブジェクトのURIを使用することで操作に向けられるなら、クライアントは余分な「仕事イド」操作属性を入れてはいけません。
Hastings, et al. Standards Track [Page 30] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[30ページ]: モデルと意味論2000年9月
The operation target attributes are REQUIRED operation attributes that MUST be included in every operation request. Like the charset and natural language attributes (see section 3.1.4), the operation target attributes are specially ordered operation attributes. In all cases, the operation target attributes immediately follow the "attributes-charset" and "attributes-natural-language" attributes within the operation attribute group, however the specific ordering rules are:
操作目標属性はあらゆる操作要求に含まなければならないREQUIRED操作属性です。 特に、charsetと自然言語属性(セクション3.1.4を見る)のように、操作属性は操作目標属性に命令されます。 ケース、目標属性がすぐに続くすべての操作では、「属性-charset」としかしながら、操作属性グループの中の「属性自然言語」属性、特定の注文規則は以下の通りです。
- In the case where there is only one operation target attribute
(i.e., either only the "printer-uri" attribute or only the
"job-uri" attribute), that attribute MUST be the third attribute
in the operation attributes group.
- In the case where Job operations use two operation target
attributes (i.e., the "printer-uri" and "job-id" attributes),
the "printer-uri" attribute MUST be the third attribute and the
"job-id" attribute MUST be the fourth attribute.
- 1つの操作目標属性(すなわち、「プリンタ-uri」属性だけか「仕事-uri」属性のどちらかだけ)しかない場合では、その属性は操作属性グループで3番目の属性であるに違いありません。 - Job操作が2つの操作目標属性(すなわち、「プリンタ-uri」と「仕事イド」属性)を使用する場合では、「プリンタ-uri」属性は3番目の属性であるに違いありません、そして、「仕事イド」属性は4番目の属性であるに違いありません。
In all cases, the target URIs contained within the body of IPP operation requests and responses must be in absolute format rather than relative format (a relative URL identifies a resource with the scope of the HTTP server, but does not include scheme, host or port).
すべての場合には、相対的な形式よりむしろ絶対式にIPP操作要求と応答のボディーの中に含まれた目標URIがあるに違いありません(相対的なURLは、HTTPサーバの範囲とリソースを同一視しますが、体系、ホストまたはポートを含んでいません)。
The following rules apply to the use of port numbers in URIs that identify IPP objects:
以下の規則はIPPオブジェクトを特定するURIにおけるポートナンバーの使用に適用されます:
1. If the URI scheme allows the port number to be explicitly
included in the URI string, and a port number is specified
within the URI, then that port number MUST be used by the
client to contact the IPP object.
1. ポートナンバーがURIストリングがURI体系で明らかに包含して、ポートナンバーがURIの中で指定されるなら、クライアントは、IPPオブジェクトに連絡するのにそのポートナンバーを使用しなければなりません。
2. If the URI scheme allows the port number to be explicitly
included in the URI string, and a port number is not specified
within the URI, then default port number implied by that URI
scheme MUST be used by the client to contact the IPP object.
2. ポートナンバーがURIストリングがURI体系で明らかに包含して、ポートナンバーがURIの中で指定されないなら、クライアントは、IPPオブジェクトに連絡するのにそのURI体系によって含意されたデフォルトポートナンバーを使用しなければなりません。
3. If the URI scheme does not allow an explicit port number to be
specified within the URI, then the default port number implied
by that URI MUST be used by the client to contact the IPP
object.
3. URI体系が、明白なポートナンバーがURIの中で指定されるのを許容しないなら、デフォルトポートナンバーは、それでクライアントがIPPオブジェクトに連絡するのにユリを使用しなければならないのを含意しました。
Note: The IPP "Encoding and Transport document [RFC2910] shows a mapping of IPP onto HTTP/1.1 [RFC2616] and defines a new default port number for using IPP over HTTP/1.1.
以下に注意してください。 IPPは「HTTP/1.1[RFC2616]にIPPに関するマッピングを示していて、IPPを使用するために新しいデフォルトポートナンバーにHTTP/1.1以上を定義コード化とTransportが記録する[RFC2910]」。
Hastings, et al. Standards Track [Page 31] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[31ページ]: モデルと意味論2000年9月
3.1.6 Operation Response Status Codes and Status Messages
3.1.6 操作応答ステータスコードとステータスメッセージ
Every operation response includes a REQUIRED "status-code" parameter and an OPTIONAL "status-message" operation attribute, and an OPTIONAL "detailed-status-message" operation attribute. The Print-URI and Send-URI response MAY include an OPTIONAL "document-access-error" operation attribute.
あらゆる操作応答がREQUIRED「ステータスコード」パラメタ、OPTIONAL「ステータスメッセージ」操作属性、およびOPTIONAL「詳細なステータスメッセージ」操作属性を含んでいます。 Print-URIとSend-URI応答はOPTIONAL「ドキュメントアクセスエラー」操作属性を含むかもしれません。
3.1.6.1 "status-code" (type2 enum)
3.1.6.1 「ステータスコード」(type2 enum)
The REQUIRED "status-code" parameter provides information on the processing of a request.
REQUIRED「ステータスコード」パラメタは要求の処理の情報を提供します。
The status code is intended for use by automata. A client implementation of IPP SHOULD convert status code values into any localized message that has semantic meaning to the end user.
ステータスコードは使用のためにオートマトンで意図します。 いずれへのIPP SHOULD転向者状態コード値のクライアント実装は意味意味をエンドユーザに持っているメッセージをローカライズしました。
The "status-code" value is a numeric value that has semantic meaning. The "status-code" syntax is similar to a "type2 enum" (see section 4.1 on "Attribute Syntaxes") except that values can range only from 0x0000 to 0x7FFF. Section 13 describes the status codes, assigns the numeric values, and suggests a corresponding status message for each status code for use by the client when the user's natural language is English.
「ステータスコード」値は意味意味がある数値です。 値が0×0000だけから0x7FFFまで及ぶことができるのを除いて、「ステータスコード」構文は"type2 enum"(「属性構文」のセクション4.1を見る)と同様です。 ユーザの自然言語がイギリスのであるときに、セクション13は、クライアントによる使用のためにステータスコードについて説明して、数値を割り当てて、各ステータスコードのための対応するステータスメッセージを示します。
If the Printer performs an operation with no errors and it encounters no problems, it MUST return the status code 'successful-ok' in the response. See section 13.
Printerが誤りなしで操作を実行して、問題に全く行きあたらないなら、それは応答におけるステータスコード'うまくいっているOK'を返さなければなりません。 セクション13を見てください。
If the client supplies unsupported values for the following parameters or Operation attributes, the Printer object MUST reject the operation, NEED NOT return the unsupported attribute value in the Unsupported Attributes group, and MUST return the indicated status code:
クライアントが以下のパラメタかOperation属性にサポートされない値を供給するなら、Printerオブジェクトは、操作を拒絶しなければならなくて、Unsupported Attributesグループでサポートされない属性値を返す必要はなくて、示されたステータスコードを返さなければなりません:
Parameter/Attribute Status code
パラメタ/属性Statusコード
version-number server-error-version-not-supported
operation-id server-error-operation-not-supported
attributes-charset client-error-charset-not-supported
compression client-error-compression-not-supported
document-format client-error-document-format-not-supported
document-uri client-error-uri-scheme-not-supported,
client-error-document-access-error
uri体系がサポートしなかったバージョン番号誤りバージョンがサポートしなかったサーバ操作イド操作がサポートしなかったサーバ誤り属性-charset charsetがサポートしなかったクライアント誤り圧縮圧縮がサポートしなかったクライアント誤りドキュメント・フォーマット形式が支えなかったクライアント誤りドキュメントドキュメント-uriクライアント誤り、クライアント誤りドキュメントアクセスエラー
If the client supplies unsupported values for other attributes, or unsupported attributes, the Printer returns the status code defined in section 3.1.7 on Unsupported Attributes.
クライアントが他の属性、またはサポートされない属性にサポートされない値を供給するなら、PrinterはUnsupported Attributesでセクション3.1.7で定義されたステータスコードを返します。
Hastings, et al. Standards Track [Page 32] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[32ページ]: モデルと意味論2000年9月
3.1.6.2 "status-message" (text(255))
3.1.6.2 「ステータスメッセージ」(テキスト(255))
The OPTIONAL "status-message" operation attribute provides a short textual description of the status of the operation. The "status- message" attribute's syntax is "text(255)", so the maximum length is 255 octets (see section 4.1.1). The status message is intended for the human end user. If a response does include a "status-message" attribute, an IPP client NEED NOT examine or display the messages, however it SHOULD do so in some implementation specific manner. The "status-message" is especially useful for a later version of a Printer object to return as supplemental information for the human user to accompany a status code that an earlier version of a client might not understand.
OPTIONAL「ステータスメッセージ」操作属性は操作の状態の短い原文の記述を提供します。 属性の構文が「テキスト(255)」であるという最大の長さが255の八重奏(セクション4.1.1を見る)であることでの「状態メッセージ。」 ステータスメッセージは人間のエンドユーザのために意図します。 応答が「ステータスメッセージ」属性を含んでいるなら、IPPクライアントは、しかしながら、メッセージ、それを調べる必要はありませんし、また表示する必要はありません。SHOULDは何らかの実装の特定の方法でそうします。 Printerオブジェクトの後のバージョンが補足的情報として戻って、人間のユーザがクライアントの以前のバージョンが理解しないかもしれないステータスコードに同伴するように、「ステータスメッセージ」は特に役に立ちます。
If the Printer object supports the "status-message" operation attribute, the Printer object MUST be able to generate this message in any of the natural languages identified by the Printer object's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in section 3.1.4.1. Section 13 suggests the text for the status message returned by the Printer for use with the English natural language.
Printerオブジェクトが「ステータスメッセージ」操作属性をサポートするなら、PrinterオブジェクトはPrinterオブジェクトの「サポートされた発生している自然な言語」属性によって特定された自然言語のどれかのこのメッセージを生成することができなければなりません。(セクション3.1.4.1部分13で指定された「属性自然言語」操作属性が使用のためにPrinterによって返されたステータスメッセージのためにイギリスの自然言語でテキストを示すのを確実にしてください。
As described in section 3.1.4.1 for any returned 'text' attribute, if there is a choice for generating this message, the Printer object uses the natural language indicated by the value of the "attributes- natural-language" in the client request if supported, otherwise the Printer object uses the value in the Printer object's own "natural- language-configured" attribute.
このメッセージを生成するための選択があればどんな返された'テキスト'のための.1も結果と考えるセクション3.1.4で説明されるように、Printerオブジェクトはさもなければ、サポートされるなら、Printerオブジェクトが中のPrinterオブジェクトのものが所有している「生まれつきの名手は言語で構成した」値を使用するというクライアント要求における「属性自然言語」属性の値によって示された自然言語を使用します。
If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for the following error status codes (see section 13): 'client-error-bad-request', 'client-error-charset-not-supported', 'server-error-internal-error', 'server-error-operation-not- supported', and 'server-error-version-not-supported'. In this case, it MUST set the value of the "attributes-charset" operation attribute to 'utf-8' in the error response.
Printerであるなら、オブジェクトは「ステータスメッセージ」操作属性をサポートして、それはREQUIRED'utf-8'が以下の誤りステータスコードのためのステータスメッセージを返すためにcharsetするSHOULD使用(セクション13を見る)です: ''クライアントの誤りの悪い要求'、'charsetがサポートしなかったクライアント誤り'、'サーバ誤り内部エラー'、'サーバ誤り操作でサポートしていない'誤りバージョンがサポートしなかったサーバ'。 この場合、それは誤り応答で「属性-charset」操作属性の値を'utf-8'に設定しなければなりません。
3.1.6.3 "detailed-status-message" (text(MAX))
3.1.6.3 「詳細なステータスメッセージ」(テキスト(最大))
The OPTIONAL "detailed-status-message" operation attribute provides additional more detailed technical and implementation-specific information about the operation. The "detailed-status-message" attribute's syntax is "text(MAX)", so the maximum length is 1023 octets (see section 4.1.1). If the Printer objects supports the "detailed-status-message" operation attribute, the Printer NEED NOT localize the message, since it is intended for use by the system administrator or other experienced technical persons. Localization
OPTIONAL「詳細なステータスメッセージ」操作属性は操作に関する追加より詳細な技術的、そして、実装特殊情報を提供します。 「詳細なステータスメッセージ、」 属性の構文が「テキスト(最大)」であるので、最大の長さは1023の八重奏(セクション4.1.1を見る)です。 Printerオブジェクトが「詳細なステータスメッセージ」操作属性をサポートするなら、Printerはメッセージをローカライズする必要はありません、それが使用のためにシステム管理者か他の経験豊富な技術人々によって意図されるので。 ローカライズ
Hastings, et al. Standards Track [Page 33] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[33ページ]: モデルと意味論2000年9月
might obscure the technical meaning of such messages. Clients MUST NOT attempt to parse the value of this attribute. See the "document-access-error" operation attribute (section 3.1.6.4) for additional errors that a program can process.
そのようなメッセージの技術的な意味をあいまいにするかもしれません。 クライアントは、この属性の値を分析するのを試みてはいけません。 「ドキュメントアクセスエラー」操作属性を見てください、(セクション3.1 .6 .4) プログラムが処理できる追加誤りのために。
3.1.6.4 "document-access-error" (text(MAX))
3.1.6.4 「ドキュメントアクセスエラー」(テキスト(最大))
This OPTIONAL operation attribute provides additional information about any document access errors encountered by the Printer before it returned a response to the Print-URI (section 3.2.2) or Send-URI (section 3.3.1) operation. For errors in the protocol identified by the URI scheme in the "document-uri" operation attribute, such as 'http:' or 'ftp:', the error code is returned in parentheses, followed by the URI. For example:
このOPTIONAL操作属性はPrint-URI(セクション3.2.2)かSend-URI(セクション3.3.1)操作への応答を返す前にPrinterによって遭遇されたどんなドキュメントアクセスエラーに関する追加情報も提供します。 「ドキュメント-uri」操作属性におけるURI体系によって特定されたプロトコルにおける、'http: ''ftpなどの誤りのために: 'エラーコードはURIがあとに続いた括弧で返されます。 例えば:
(404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf
(404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf
Most Internet protocols use decimal error codes (unlike IPP), so the ASCII error code representation is in decimal.
ほとんどのインターネットプロトコルが10進エラーコード(IPPと異なった)を使用するので、小数にはASCIIエラーコード表現があります。
3.1.7 Unsupported Attributes
3.1.7 サポートされない属性
The Unsupported Attributes group contains attributes that are not supported by the operation. This group is primarily for the job creation operations, but all operations can return this group.
Unsupported Attributesグループは操作でサポートされない属性を含みます。 このグループは主として雇用創出操作のためのものですが、すべての操作がこのグループを返すことができます。
A Printer object MUST include an Unsupported Attributes group in a response if the status code is one of the following: 'successful- ok-ignored-or-substituted-attributes', 'successful-ok-conflicting- attributes', 'client-error-attributes-or-values-not-supported' or 'client-error-conflicting-attributes'.
Printerオブジェクトはステータスコードが以下の1つであるなら応答にUnsupported Attributesグループを含まなければなりません: 'うまくいっている間違いない無視されたか代入された属性'、'うまくいってOKに闘争している属性'の'属性か値がサポートしなかったクライアント誤り'または'クライアント誤り闘争属性'。
If the status code is one of the four specified in the preceding paragraph, the Unsupported Attributes group MUST contain all of those attributes and only those attributes that are:
ステータスコードが先行のパラグラフで指定された、4つのものの1つであるなら、Unsupported Attributesグループは以下の通りであるそれらの属性とそれらの属性だけのすべてを含まなければなりません。
a. an Operation or Job Template attribute supplied in the request,
and
そしてa. 要求で供給されたOperationかJob Template属性。
b. unsupported by the printer. See below for details on the three
categories "unsupported" attributes.
b. プリンタで、サポートされないです。 3つのカテゴリ「サポートされない」属性に関する詳細に関して以下を見てください。
If the status code is one of those in the table in section 3.1.6.1, the Unsupported Attributes group NEED NOT contain the unsupported parameter or attribute indicated in that table.
ステータスコードがセクション3.1.6におけるテーブルのそれらの1つであるなら、.1、Unsupported Attributesグループがサポートされないパラメタを含む必要はありませんか、または属性はそれでテーブルを示しました。
Hastings, et al. Standards Track [Page 34] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[34ページ]: モデルと意味論2000年9月
If the Printer object is not returning any Unsupported Attributes in the response, the Printer object SHOULD omit Group 2 rather than sending an empty group. However, a client MUST be able to accept an empty group.
Printerオブジェクトが応答で少しのUnsupported Attributesも返していないなら、PrinterオブジェクトSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、クライアントは空のグループを受け入れることができなければなりません。
Unsupported attributes fall into three categories:
サポートされない属性は3つのカテゴリになります:
1. The Printer object does not support the supplied attribute (no
matter what the attribute syntax or value).
1. Printerオブジェクトは供給された属性をサポートしません(属性構文か値が何であっても)。
2. The Printer object does support the attribute, but does not
support some or all of the particular attribute syntaxes or
values supplied by the client (i.e., the Printer object does
not have those attribute syntaxes or values in its
corresponding "xxx-supported" attribute).
2. Printerオブジェクトは、属性をサポートしますが、クライアントによって供給された特定の属性構文か値のいくつかかすべてはサポートしません(すなわち、Printerオブジェクトには、対応する「xxxによってサポートしている」属性におけるそれらの属性構文か値がありません)。
3. The Printer object does support the attributes and values
supplied, but the particular values are in conflict with one
another, because they violate a constraint, such as not being
able to staple transparencies.
3. Printerオブジェクトは供給された属性と値をサポートしますが、特定の値はお互いとの闘争中です、規制に違反するので、透明をとめることができないのなどように。
In the case of an unsupported attribute name, the Printer object returns the client-supplied attribute with a substituted value of 'unsupported'. This value's syntax type is "out-of-band" and its encoding is defined by special rules for "out-of-band" values in the "Encoding and Transport" document [RFC2910]. Its value indicates no support for the attribute itself (see the beginning of section 4.1).
サポートされない属性名の場合では、Printerオブジェクトは'サポートされないこと'の代入された値があるクライアントによって供給された属性を返します。 「バンドの外で」この値の構文タイプはそうです、そして、「バンドの外」のための「コード化と輸送」における値が記録する特別な規則[RFC2910]でコード化は定義されます。 値は属性自体のサポートを全く示しません(セクション4.1の始まりを見てください)。
In the case of a supported attribute with one or more unsupported attribute syntaxes or values, the Printer object simply returns the client-supplied attribute with the unsupported attribute syntaxes or values as supplied by the client. This indicates support for the attribute, but no support for that particular attribute syntax or value. If the client supplies a multi-valued attribute with more than one value and the Printer object supports the attribute but only supports a subset of the client-supplied attribute syntaxes or values, the Printer object
1つ以上のサポートされない属性構文か値があるサポートしている属性の場合では、クライアントによって供給されるようにPrinterオブジェクトは単にサポートされない属性構文か値があるクライアントによって供給された属性を返します。 属性のサポートを示しますが、これはその特定の属性構文か値のどんなサポートも示しません。 クライアントがマルチ評価された属性に1つ以上の値を供給して、Printerオブジェクトが属性をサポートしますが、クライアントによって供給された属性構文か値の部分集合をサポートするだけであるなら、Printerは反対します。
MUST return only those attribute syntaxes or values that are unsupported.
それらのサポートされない属性構文か値だけを返さなければなりません。
In the case of two (or more) supported attribute values that are in conflict with one another (although each is supported independently, the values conflict when requested together within the same job), the Printer object MUST return all the values that it ignores or substitutes to resolve the conflict, but not any of the values that
Printerオブジェクトは、お互い(それぞれが独自にサポートされますが、同じ仕事の中で一緒に要求されると、値は闘争する)との闘争中であることの属性値であることが支えられた2(さらに)の場合では、それが無視する値をすべてに返さなければならないか、または決議する代用品に闘争を返さなければならなくて、値の唯一のいずれでないのはそれです。
Hastings, et al. Standards Track [Page 35] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[35ページ]: モデルと意味論2000年9月
it is still using. The choice for exactly how to resolve the conflict is implementation dependent. See sections 3.2.1.2 and 15. See The Implementer's Guide [IPP-IIG] for an example.
それはまだ使用されています。 ちょうどどう対立を解決するかためには選択は実装に依存しています。 セクション3.2.1.2と15を見てください。 例に関してImplementerのガイド[IPP-IIG]を見てください。
3.1.8 Versions
3.1.8 バージョン
Each operation request and response carries with it a "version- number" parameter. Each value of the "version-number" is in the form "X.Y" where X is the major version number and Y is the minor version number. By including a version number in the client request, it allows the client to identify which version of IPP it is interested in using, i.e., the version whose conformance requirements the client may be depending upon the Printer to meet.
各操作要求と応答はそれと共に「バージョン番号」パラメタを運びます。 「バージョン番号」の各値がXがメジャーバージョン番号であり、Yがマイナーバージョン番号であるフォーム「X.Y」にあります。 クライアント要求にバージョン番号を含んでいることによって、クライアントは、それでIPPのどのバージョンを使用するかをそれが関心がある特定できます、すなわち、クライアントが会うために順応要件をPrinterを当てにしているかもしれないバージョン。
If the IPP object does not support that major version number supplied by the client, i.e., the major version field of the "version-number" parameter does not match any of the values of the Printer's "ipp- versions-supported" (see section 4.4.14), the object MUST respond with a status code of 'server-error-version-not-supported' along with the closest version number that is supported (see section 13.1.5.4). If the major version number is supported, but the minor version number is not, the IPP object SHOULD accept and attempt to perform the request (or reject the request if the operation is not supported), else it rejects the request and returns the 'server- error-version-not-supported' status code. In all cases, the IPP object MUST return the "version-number" that it supports that is closest to the version number supplied by the client in the request.
セクション13.1を見てください。IPPオブジェクトがクライアントによって供給されたそのメジャーバージョン番号をサポートしないなら、すなわち、「バージョン番号」パラメタの主要なバージョン分野が「ippはバージョンでサポートした」Printerのものの値のいずれにも合わないで(セクション4.4.14を見てください)、オブジェクトがサポートされる中で最も近いバージョン番号と共に'誤りバージョンがサポートしなかったサーバ'のステータスコードで応じなければならない、(.5 .4)。 メジャーバージョン番号がサポートされますが、マイナーバージョン番号がサポートされるというわけではないなら、IPPオブジェクトSHOULDが、受け入れて、要求を実行するのを試みて(操作がサポートされないなら、要求を拒絶してください)、それは、ほかに、要求を拒絶して、'サポートされなかったサーバ誤りバージョン'ステータスコードを返します。 すべての場合では、IPPオブジェクトはそれがサポートする「バージョン番号」を返さなければなりません、すなわち、最も近くでは、バージョンに、数が要求でクライアントを供給しました。
There is no version negotiation per se. However, if after receiving a 'server-error-version-not-supported' status code from an IPP object, a client SHOULD try again with a different version number. A client MAY also determine the versions supported either from a directory that conforms to Appendix E (see section 16) or by querying the Printer object's "ipp-versions-supported" attribute (see section 4.4.14) to determine which versions are supported.
バージョン交渉が全くそういうものとしてありません。 しかしながら、受信した後にIPPオブジェクトからの'誤りバージョンがサポートしなかったサーバ'ステータスコード、クライアントSHOULDは異なった見解番号で再試行します。 また、クライアントは、一致しているディレクトリからAppendix E(セクション16を見ます)までPrinterオブジェクトの「バージョンがサポートしたipp」属性について質問すること(セクション4.4.14を見ます)でサポートされたバージョンが、どのバージョンがサポートされるかを決定すると決心するかもしれません。
An IPP object implementation MUST support version '1.1', i.e., meet the conformance requirements for IPP/1.1 as specified in this document and [RFC2910]. It is recommended that IPP object implementations accept any request with the major version '1' (or reject the request if the operation is not supported).
IPPオブジェクト実装は'1.1にバージョンをサポートしなければなりません。'すなわち、このドキュメントと[RFC2910]の指定されるとしてのIPP/1.1のための順応必要条件を満たしてください。 IPPオブジェクト実装が主要なバージョン'1'でどんな要求も受け入れるのは(操作がサポートされないなら、要求を拒絶してください)、お勧めです。
There is only one notion of "version number" that covers both IPP Model and IPP Protocol changes. Thus the version number MUST change when introducing a new version of the Model and Semantics document (this document) or a new version of the "Encoding and Transport" document [RFC2910].
IPP ModelとIPPプロトコル変化の両方をカバーする「バージョン番号」の1つの概念しかありません。 ModelとSemanticsドキュメントの新しいバージョン(このドキュメント)か「コード化と輸送」というドキュメントの新しいバージョン[RFC2910]を紹介するとき、したがって、バージョン番号は変化しなければなりません。
Hastings, et al. Standards Track [Page 36] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[36ページ]: モデルと意味論2000年9月
Changes to the major version number of the Model and Semantics document indicate structural or syntactic changes that make it impossible for older version of IPP clients and Printer objects to correctly parse and correctly process the new or changed attributes, operations and responses. If the major version number changes, the minor version numbers is set to zero. As an example, adding the REQUIRED "ipp-attribute-fidelity" attribute to version '1.1' (if it had not been part of version '1.0'), would have required a change to the major version number, since an IPP/1.0 Printer would not have processed a request with the correct semantics that contained the "ipp-attribute-fidelity" attribute that it did not know about. Items that might affect the changing of the major version number include any changes to the Model and Semantics document (this document) or the "Encoding and Transport" document [RFC2910] itself, such as:
ModelとSemanticsドキュメントのメジャーバージョン番号への変化は、IPPクライアントとPrinterオブジェクトの旧式のバージョンが正しく分析されるのを不可能にする構造的であるか構文の変化を示して、正しく新しいか変えられた属性、操作、および応答を処理します。 メジャーバージョン番号が変化するなら、マイナーバージョン番号はゼロに設定されます。 IPP/1.0Printerは正しい意味論で要求を処理していないでしょう、REQUIRED「ipp属性信義」属性をバージョン'1.1'に追加して(それがバージョン'1.0'の一部でなかったなら)、例がメジャーバージョン番号への変化を必要として、したがって、それはそれが知らなかった「ipp属性信義」属性を含みました。 メジャーバージョン番号の変化に影響するかもしれない項目がModelとSemanticsドキュメントへのどんな変化(このドキュメント)か「コード化と輸送」という以下などのドキュメント[RFC2910]自体も含んでいます。
- reordering of ordered attributes or attribute sets
- changes to the syntax of existing attributes
- adding REQUIRED (for an IPP object to support) operation
attribute groups
- adding values to existing REQUIRED operation attributes
- adding REQUIRED operations
- REQUIRED操作を加えて、既存のREQUIRED操作属性に価値を高めて、REQUIRED(IPPオブジェクトがサポートする)操作属性グループを加える命令された属性か属性セット(既存の属性の構文への変化)に関する再命令
Changes to the minor version number indicate the addition of new features, attributes and attribute values that may not be understood by all IPP objects, but which can be ignored if not understood. Items that might affect the changing of the minor version number include any changes to the model objects and attributes but not the encoding and transport rules [RFC2910] (except adding attribute syntaxes). Examples of such changes are:
マイナーバージョン番号への変化はすべてのIPPオブジェクトに解釈されないかもしれませんが、無視するか、または理解できる新機能、属性、および属性値の追加を示します。 マイナーバージョン番号の変化に影響するかもしれない項目がコード化と輸送規則[RFC2910]ではなく、モデルオブジェクトと属性(属性構文を加えるのを除いた)へのどんな変化も含んでいます。 そのような変化に関する例は以下の通りです。
- grouping all extensions not included in a previous version into
a new version
- adding new attribute values
- adding new object attributes
- adding OPTIONAL (for an IPP object to support) operation
attributes (i.e., those attributes that an IPP object can ignore
without confusing clients)
- adding OPTIONAL (for an IPP object to support) operation
attribute groups (i.e., those attributes that an IPP object can
ignore without confusing clients)
- adding new attribute syntaxes
- adding OPTIONAL operations
- changing Job Description attributes or Printer Description
attributes from OPTIONAL to REQUIRED or vice versa.
- adding OPTIONAL attribute syntaxes to an existing attribute.
- OPTIONALを加えて、OPTIONAL(IPPオブジェクトがサポートする)操作属性(すなわち、IPPオブジェクトがクライアントを混乱させないで無視できるそれらの属性)を加えて、新しいオブジェクト属性を加えて、新しい属性値を加えて、旧バージョンで新しいバージョンに含められなかったすべての拡大を分類します; (IPPオブジェクトがサポートする) 操作属性グループ(すなわち、IPPオブジェクトがクライアントを混乱させないで無視できるそれらの属性)--新しい状態で加えて、Job記述属性かPrinter記述属性をOPTIONALからREQUIREDに変えて、OPTIONAL操作を加えて、構文を結果と考えなさいか、逆もまた同様です。 - OPTIONAL属性構文を既存の属性に加えます。
The encoding of the "version-number" MUST NOT change over any version number (either major or minor). This rule guarantees that all future
「バージョン番号」のコード化はどんなバージョン番号(主要であるか小さい方の)の上変化してはいけません。 この規則はすべての未来にそれを保証します。
Hastings, et al. Standards Track [Page 37] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[37ページ]: モデルと意味論2000年9月
versions will be backwards compatible with all previous versions (at least for checking the "version-number"). In addition, any protocol elements (attributes, error codes, tags, etc.) that are not carried forward from one version to the next are deprecated so that they can never be reused with new semantics.
バージョンが後方にすべての旧バージョン(少なくとも「バージョン番号」をチェックするための)と互換性があった状態であるでしょう。 さらに、1つのバージョンから次まで進展しない少しのプロトコル要素(属性、エラーコード、タグなど)も、新しい意味論でそれらを決して再利用できないくらい推奨しないです。
Implementations that support a certain version NEED NOT support ALL previous versions. As each new version is defined (through the release of a new IPP specification document), that version will specify which previous versions MUST and which versions SHOULD be supported in compliant implementations.
あるバージョンをサポートする実装はすべての旧バージョンをサポートしなければならないというわけではありません。 それぞれと、新しいバージョンは定義されます、そして、(新しいIPP仕様ドキュメントのリリースで)バージョンは旧バージョンが指定しなければならないものを指定するでしょう、そして、どのバージョンSHOULDが対応する実装でサポートされますか?
3.1.9 Job Creation Operations
3.1.9 雇用創出操作
In order to "submit a print job" and create a new Job object, a client issues a create request. A create request is any one of following three operation requests:
クライアントは、「印刷仕事を提出し」て、新しいJobオブジェクトを作成するためにaを発行します。要求を作成してください。 Aが作成する、要求は3つの操作要求に続くいずれでもあります:
- The Print-Job Request: A client that wants to submit a print job
with only a single document uses the Print-Job operation. The
operation allows for the client to "push" the document data to
the Printer object by including the document data in the request
itself.
- 印刷仕事の要求: ただ一つのドキュメントだけによる印刷仕事を提出したがっているクライアントはPrint-仕事の操作を使用します。 操作は、クライアントが要求自体にドキュメントデータを含んでいることによってPrinterオブジェクトにドキュメントデータを「押すこと」を許容します。
- The Print-URI Request: A client that wants to submit a print job
with only a single document (where the Printer object "pulls"
the document data instead of the client "pushing" the data to
the Printer object) uses the Print-URI operation. In this
case, the client includes in the request only a URI reference to
the document data (not the document data itself).
- 印刷URI要求: ただ一つのドキュメント(PrinterオブジェクトがPrinterオブジェクトにデータを「押している」クライアントの代わりにドキュメントデータを「引く」ところ)だけによる印刷仕事を提出したがっているクライアントはPrint-URI操作を使用します。 この場合、クライアントは要求だけでドキュメントデータ(ドキュメントデータ自体でない)のURI指示するものを入れます。
- The Create-Job Request: A client that wants to submit a print
job with multiple documents uses the Create-Job operation. This
operation is followed by an arbitrary number (one or more) of
Send-Document and/or Send-URI operations (each creating another
document for the newly create Job object). The Send-Document
operation includes the document data in the request (the client
"pushes" the document data to the printer), and the Send-URI
operation includes only a URI reference to the document data in
the request (the Printer "pulls" the document data from the
referenced location). The last Send-Document or Send-URI
request for a given Job object includes a "last-document"
operation attribute set to 'true' indicating that this is the
last request.
- 雇用を創り出している要求: 複数のドキュメントによる印刷仕事を提出したがっているクライアントはCreate-仕事の操作を使用します。 Send-ドキュメント、そして/または、Send-URI操作の特殊活字の数字(1以上)がこの操作のあとに続いている、(それぞれ別のドキュメントを作成する、新たにJobオブジェクトを作成してください、) Send-ドキュメント操作は要求にドキュメントデータを含んでいます、そして、(クライアントはドキュメントデータをプリンタに「押す」)Send-URI操作は要求におけるドキュメントデータのURI指示するものだけを含んでいます(Printerは参照をつけられた位置からドキュメントデータを「引きます」)。 これが最後の要求であることを示しながら、与えられたJobオブジェクトを求める最後のSend-ドキュメントかSend-URI要求が「最後のドキュメント」操作属性セットを'本当に'含んでいます。
Throughout this model document, the term "create request" is used to refer to any of these three operation requests.
このモデルドキュメント中では、「要求を作成する」という用語は、これらの3つの操作要求のどれかを示すのに使用されます。
Hastings, et al. Standards Track [Page 38] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[38ページ]: モデルと意味論2000年9月
A Create-Job operation followed by only one Send-Document operation is semantically equivalent to a Print-Job operation, however, for performance reasons, the client SHOULD use the Print-Job operation for all single document jobs. Also, Print-Job is a REQUIRED operation (all implementations MUST support it) whereas Create-Job is an OPTIONAL operation, hence some implementations might not support it.
1つのSend-ドキュメント操作だけがあとに続いたCreate-仕事の操作がPrint-仕事の操作に意味的に同等である、性能理由で、しかしながら、クライアントSHOULDはすべてのただ一つのドキュメント仕事にPrint-仕事の操作を使用します。 Create-仕事がOPTIONAL操作である、また、Print-仕事はREQUIRED操作(すべての実装がそれをサポートしなければならない)ですが、したがって、いくつかの実装はそれをサポートしないかもしれません。
Job submission time is the point in time when a client issues a create request. The initial state of every Job object is the 'pending', 'pending-held', or 'processing' state (see section 4.3.7). When the Printer object begins processing the print job, the Job object's state moves to 'processing'. This is known as job processing time. There are validation checks that must be done at job submission time and others that must be performed at job processing time.
クライアント問題aが要求を作成する時代の間、ジョブ依頼時間は時点です。 あらゆるJobオブジェクトの初期状態は'未定'、そして、'未定に保持される'か'処理'の状態(セクション4.3.7を見る)です。 Printerオブジェクトが印刷仕事を処理し始めると、Jobオブジェクトの状態は'処理'に移行します。 これはジョブ処理時間として知られています。 ジョブ依頼時にしなければならない合法化チェックとジョブ処理時に実行しなければならない他のものがいます。
At job submission time and at the time a Validate-Job operation is received, the Printer MUST do the following:
ジョブ依頼時、Validate-仕事の操作が受け取られているとき、Printerは以下をしなければなりません:
1. Process the client supplied attributes and either accept or
reject the request
2. Validate the syntax of and support for the scheme of any client
supplied URI
1. クライアントの供給された属性を処理してください、要求2を受け入れるか、または拒絶してください。 どんなクライアントの供給されたURIの体系の構文とサポートも有効にしてください。
At job submission time the Printer object MUST validate whether or not the supplied attributes, attribute syntaxes, and values are supported by matching them with the Printer object's corresponding "xxx-supported" attributes. See section 3.1.7 for details. [IPP- IIG] presents suggested steps for an IPP object to either accept or reject any request and additional steps for processing create requests.
供給された属性、属性構文、および値がPrinterオブジェクトの対応する「xxxによってサポートしている」属性にそれらを合わせることによってサポートされるか否かに関係なく、Printerオブジェクトが有効にしなければならないジョブ依頼時に。 詳細に関してセクション3.1.7を見てください。 IPPオブジェクトがどんな要求も受け入れるか、または拒絶するように、[IPP- IIG]プレゼントはステップを示しました、そして、処理のための追加ステップは要求を作成します。
At job submission time the Printer object NEED NOT perform the validation checks reserved for job processing time such as:
ジョブ依頼時に、Printerオブジェクトは以下などのジョブ処理時間への控えられた合法化チェックを実行する必要はありません。
1. Validating the document data
2. Validating the actual contents of any client supplied URI
(resolve the reference and follow the link to the document
data)
1. ドキュメントデータ2を有効にします。 どんなクライアントの供給されたURIの実際のコンテンツも有効にします。(参照を決議して、ドキュメントデータへのリンクに続きます)
At job submission time, these additional job processing time validation checks are essentially useless, since they require actually parsing and interpreting the document data, are not guaranteed to be 100% accurate, and MUST be done, yet again, at job processing time. Also, in the case of a URI, checking for availability at job submission time does not guarantee availability
ジョブ依頼時に、これらの追加ジョブ処理時間合法化チェックは本質的には役に立ちません、それらを実際にドキュメントデータを分析して、解釈するのが必要であり、100%正確になるように保証されないで、再びまだ終わらなければならないので、ジョブ処理時に。 また、ジョブ依頼時に有用性がないかどうかURIの場合でチェックするのは有用性を保証しません。
Hastings, et al. Standards Track [Page 39] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[39ページ]: モデルと意味論2000年9月
at job processing time. In addition, at job processing time, the Printer object might discover any of the following conditions that were not detectable at job submission time:
ジョブ処理時に。 Printerオブジェクトがジョブ処理時にそうするかもしれない追加では、以下のジョブ依頼時に検出可能でなかった条件のどれかを発見してください:
- runtime errors in the document data,
- nested document data that is in an unsupported format,
- the URI reference is no longer valid (i.e., the server hosting
the document might be down), or
- any other job processing error
- または、ドキュメントデータにおけるランタイム・エラー--サポートされない形式にはある入れ子にされたドキュメントデータ--URI参照がもう有効でない、(すなわち、ドキュメントをホスティングするサーバは下がっているかもしれません)--、いかなる他のジョブ処理誤り
At job submission time, a Printer object, especially a non-spooling Printer, MAY accept jobs that it does not have enough space for. In such a situation, a Printer object MAY stop reading data from a client for an indefinite period of time. A client MUST be prepared for a write operation to block for an indefinite period of time (see section 5.1 on client conformance).
ジョブ依頼時に、Printerオブジェクト(特に非スプールPrinter)はそれが十分な場所がない仕事を受け入れるかもしれません。 そのような状況で、Printerオブジェクトは、時間の無期限の間、クライアントからデータを読むのを止めるかもしれません。 aが時間の無期限の間に妨げる操作を書くので(クライアント順応にセクション5.1を見てください)、クライアントは用意ができていなければなりません。
When a Printer object has too little space for starting a new job, it MAY reject a new create request. In this case, a Printer object MUST return a response (in reply to the rejected request) with a status- code of 'server-error-busy' (see section 14.1.5.8) and it MAY close the connection before receiving all bytes of the operation. A Printer SHOULD indicate that it is temporarily unable to accept jobs by setting the 'spool-space-full' value in its "printer-state- reasons" attribute and removing the value when it can accept another job (see section 4.4.12).
Printerオブジェクトに新しい仕事を始めるためのあまりに少ないスペースがあるとき、それは新しい状態でaを拒絶するかもしれません。要求を作成してください。 この場合、Printerオブジェクトは'誤りが忙しくするサーバ'の状態コードと共に応答を返さなければなりません(拒絶された要求に対して)。(.8と)それが接続を終えるかもしれないセクション14.1.5がバイトのすべての操作を受けているのを見てください。 Printer SHOULDは、「プリンタ理由を述べている」属性における'スペースがいっぱいにスプールしている'値を設定して、別口の仕事を受け入れることができるとき(セクション4.4.12を見てください)値を取り除くことによって一時仕事を受け入れることができないのを示します。
When receiving a 'server-error-busy' status-code in an operation response, a client MUST be prepared for the Printer object to close the connection before the client has sent all of the data (especially for the Print-Job operation). A client MUST be prepared to keep submitting a create request until the IPP Printer object accepts the create request.
操作応答における'誤りが忙しくするサーバ'ステータスコードを受け取るとき、データ(特にPrint-仕事の操作のための)のすべてを送る前にクライアントはPrinterオブジェクトが接続を終える用意ができていなければなりません。 IPP Printerオブジェクトが受け入れるまでaを提出して、クライアントが保つ用意ができていなければならないAが要求を作成する、要求を作成してください。
At job processing time, since the Printer object has already responded with a successful status code in the response to the create request, if the Printer object detects an error, the Printer object is unable to inform the end user of the error with an operation status code. In this case, the Printer, depending on the error, can set the job object's "job-state", "job-state-reasons", or "job- state-message" attributes to the appropriate value(s) so that later queries can report the correct job status.
オブジェクトが応答におけるaうまくいっているステータスコードで既に応じたPrinter以来のジョブ処理時、PrinterがPrinterオブジェクトが誤りを検出するなら操作ステータスコードで誤りについてエンドユーザに知らせることができないのを反対させる要求を作成してください。 この場合、誤りによって、Printerは、後の質問が正しい地位を報告できるように、仕事のオブジェクトの「仕事状態」、「仕事の州の理由」、または「仕事の州メッセージ」属性を適切な値に設定できます。
Note: Asynchronous notification of events is outside the scope of this IPP/1.1 document.
以下に注意してください。 このIPP/1.1ドキュメントの範囲の外にイベントの非同期な通知があります。
Hastings, et al. Standards Track [Page 40] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[40ページ]: モデルと意味論2000年9月
3.2 Printer Operations
3.2 プリンタ操作
All Printer operations are directed at Printer objects. A client MUST always supply the "printer-uri" operation attribute in order to identify the correct target of the operation.
PrinterオブジェクトはすべてのPrinter操作に向けられます。 クライアントは、操作の正しい目標を特定するためにいつも「プリンタ-uri」操作属性を供給しなければなりません。
3.2.1 Print-Job Operation
3.2.1 印刷仕事の操作
This REQUIRED operation allows a client to submit a print job with only one document and supply the document data (rather than just a reference to the data). See Section 15 for the suggested steps for processing create operations and their Operation and Job Template attributes.
このREQUIRED操作で、クライアントは、1通のドキュメントだけによる印刷仕事を提出して、ドキュメントデータ(まさしくデータの参照よりむしろ)を提供します。 処理のための提案されたステップへのセクション15が操作、それらのOperation、およびJob Template属性を作成するのを見てください。
3.2.1.1 Print-Job Request
3.2.1.1 印刷仕事の要求
The following groups of attributes are supplied as part of the Print-Job Request:
Print-仕事のRequestの一部として属性の以下のグループを供給します:
Group 1: Operation Attributes
グループ1: 操作属性
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1. The Printer object
MUST copy these values to the corresponding Job Description
attributes described in sections 4.3.19 and 4.3.20.
自然言語と文字コード: セクション3.1.4で.1に説明される「属性-charset」と「属性自然言語」属性 Printerオブジェクトはセクション4.3.19と4.3で.20に説明された対応するJob記述属性にこれらの値をコピーしなければなりません。
Target:
The "printer-uri" (uri) operation attribute which is the target
for this operation as described in section 3.1.5.
以下を狙ってください。 セクション3.1.5で説明されるようにこの操作のための目標である「プリンタ-uri」(uri)操作属性。
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in section 8.3.
ユーザ名を要求します: 「要求しているユーザ名」(名前(MAX))はSHOULDを結果と考えます。説明されるとしてセクション8.3でクライアントによって供給されてください。
"job-name" (name(MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It contains the client
supplied Job name. If this attribute is supplied by the
client, its value is used for the "job-name" attribute of the
newly created Job object. The client MAY automatically include
any information that will help the end-user distinguish amongst
his/her jobs, such as the name of the application program along
with information from the document, such as the document name,
document subject, or source file name. If this attribute is
not supplied by the client, the Printer generates a name to use
in the "job-name" attribute of the newly created Job object
(see Section 4.3.5).
「ジョブ名」(名前(最大)): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それはクライアントの供給されたJob名を含んでいます。 この属性がクライアントによって供給されるなら、値は新たに作成されたJobオブジェクトの「ジョブ名」属性に使用されます。 クライアントは自動的にエンドユーザがその人の仕事の中で区別するのを助けるどんな情報も入れるかもしれません、ドキュメントからの情報に伴うアプリケーション・プログラムの名前などのように、ドキュメント名、ドキュメント対象、またはソースファイル名などのように。 この属性がクライアントによって供給されないなら、Printerは新たに作成されたJobオブジェクトの「ジョブ名」属性に使用する名前を生成します(セクション4.3.5を見てください)。
Hastings, et al. Standards Track [Page 41] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[41ページ]: モデルと意味論2000年9月
"ipp-attribute-fidelity" (boolean):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. The value 'true' indicates
that total fidelity to client supplied Job Template attributes
and values is required, else the Printer object MUST reject the
Print-Job request. The value 'false' indicates that a
reasonable attempt to print the Job object is acceptable and
the Printer object MUST accept the Print-Job request. If not
supplied, the Printer object assumes the value is 'false'. All
Printer objects MUST support both types of job processing. See
section 15 for a full description of "ipp-attribute-fidelity"
and its relationship to other attributes, especially the
Printer object's "pdl-override-supported" attribute.
「ipp属性信義」(論理演算子): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 '本当値の'は、クライアントの供給されたJob Template属性と値への総信義が必要であり、ほかに、Printer目的がPrint-仕事の要求を拒絶しなければならないのを示します。 '誤値の'は、Jobオブジェクトを印刷する合理的な試みが許容できて、PrinterオブジェクトがPrint-仕事の要求を受け入れなければならないのを示します。 供給されないなら、Printerオブジェクトは、値が'誤っている'と仮定します。 すべてのPrinterオブジェクトが両方のタイプのジョブ処理をサポートしなければなりません。 「ipp属性信義」の余すところのない解説と他の属性(特にPrinterオブジェクトの「オーバーライドがサポートしたpdl」属性)とのその関係に関してセクション15を見てください。
"document-name" (name(MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It contains the client
supplied document name. The document name MAY be different
than the Job name. Typically, the client software
automatically supplies the document name on behalf of the end
user by using a file name or an application generated name. If
this attribute is supplied, its value can be used in a manner
defined by each implementation. Examples include: printed
along with the Job (job start sheet, page adornments, etc.),
used by accounting or resource tracking management tools, or
even stored along with the document as a document level
attribute. IPP/1.1 does not support the concept of document
level attributes.
「ドキュメント名」(名前(最大)): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それはクライアントの供給されたドキュメント名を含んでいます。 ドキュメント名はJob名と異なっているかもしれません。 通常、クライアントソフトウェアは、エンドユーザを代表してファイル名か名前であることが作られたアプリケーションを使用することによって、ドキュメント名前を自動的に提供します。 この属性を供給するなら、各実装によって定義された方法で値を使用できます。 例は: 印刷されて、(仕事のスタートシート、ページ装飾品など)がドキュメントとして会計かリソースの追跡管理ツールで使用したか、またはドキュメントと共に保存さえしたJobと共に、属性を平らにしてください。 IPP/1.1はドキュメントの概念に平らな属性をサポートしません。
"compression" (type3 keyword):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute and the "compression-
supported" attribute (see section 4.4.32). The client supplied
"compression" operation attribute identifies the compression
algorithm used on the document data. The following cases exist:
「圧縮」(type3キーワード): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性と「サポートされた圧縮」属性をサポートしなければなりません(セクション4.4.32を見てください)。 クライアントの供給された「圧縮」操作属性はドキュメントデータで使用される圧縮アルゴリズムを特定します。 以下のケースは存在しています:
a) If the client omits this attribute, the Printer object MUST
assume that the data is not compressed (i.e. the Printer
follows the rules below as if the client supplied the
"compression" attribute with a value of 'none').
b) If the client supplies this attribute, but the value is not
supported by the Printer object, i.e., the value is not one
of the values of the Printer object's "compression-
supported" attribute, the Printer object MUST reject the
request, and return the 'client-error-compression-not-
supported' status code. See section 3.1.7 for returning
unsupported attributes and values.
a) クライアントがこの属性を省略するなら、Printerオブジェクトは、データが圧縮されないと仮定しなければなりません(まるでクライアントが'なにも') . bの値を「圧縮」属性に供給するかのようにすなわち、Printerは以下の規則に従います)。 クライアントがこの属性を供給しますが、値がPrinterオブジェクトによってサポートされないで、またすなわち、値がPrinterオブジェクトの「サポートされた圧縮」属性の値の1つでないなら、Printerオブジェクトは、要求を拒絶して、'クライアント誤り圧縮でサポートしていない'ステータスコードを返さなければなりません。 戻っているサポートされない属性と値に関してセクション3.1.7を見てください。
Hastings, et al. Standards Track [Page 42] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[42ページ]: モデルと意味論2000年9月
c) If the client supplies the attribute and the Printer object
supports the attribute value, the Printer object uses the
corresponding decompression algorithm on the document data.
d) If the decompression algorithm fails before the Printer
returns an operation response, the Printer object MUST
reject the request and return the 'client-error-
compression-error' status code.
e) If the decompression algorithm fails after the Printer
returns an operation response, the Printer object MUST abort
the job and add the 'compression-error' value to the job's
"job-state-reasons" attribute.
f) If the decompression algorithm succeeds, the document data
MUST then have the format specified by the job's "document-
format" attribute, if supplied (see "document-format"
operation attribute definition below).
c) クライアントが属性と属性値、Printerがドキュメントデータで対応する減圧アルゴリズムを使用するのを反対させるPrinterオブジェクトサポートに. d)を供給するなら Printerが操作応答を返す前に減圧アルゴリズムが失敗するなら、Printerオブジェクトが要求を拒絶して、'クライアント誤りを返さなければならない、-、圧縮誤り'ステータスコードe) Printerが操作応答を返した後に減圧アルゴリズムが失敗するなら、Printerオブジェクトは、仕事を中止して、仕事の「仕事の州の理由」属性f)に'圧縮誤り'価値を高めなければなりません。 減圧アルゴリズムが成功するなら、仕事の「ドキュメント形式」属性で形式を指定しなければなりませんドキュメントデータで、供給するなら(以下での「ドキュメント・フォーマット」操作属性定義を見てください)。
"document-format" (mimeMediaType):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. The value of this
attribute identifies the format of the supplied document data.
The following cases exist:
「ドキュメント・フォーマット」(mimeMediaType): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 この属性の値は供給されたドキュメントデータの形式を特定します。 以下のケースは存在しています:
a) If the client does not supply this attribute, the Printer
object assumes that the document data is in the format
defined by the Printer object's "document-format-default"
attribute. (i.e. the Printer follows the rules below as if
the client supplied the "document-format" attribute with a
value equal to the printer's default value).
b) If the client supplies this attribute, but the value is not
supported by the Printer object, i.e., the value is not one
of the values of the Printer object's "document-format-
supported" attribute, the Printer object MUST reject the
request and return the 'client-error-document-format-not-
supported' status code.
c) If the client supplies this attribute and its value is
'application/octet-stream' (i.e. to be auto-sensed, see
Section 4.1.9.1), and the format is not one of the
document-formats that the Printer can auto-sense, and this
check occurs before the Printer returns an operation
response, then the Printer MUST reject the request and
return the 'client-error-document-format-not-supported'
status code.
d) If the client supplies this attribute, and the value is
supported by the Printer object, the Printer is capable of
interpreting the document data.
a) クライアントがこの属性を供給しないなら、Printerオブジェクトは、Printerオブジェクトの「ドキュメント形式デフォルト」属性によって定義された書式にはドキュメントデータがあると仮定します。 (まるでクライアントがプリンタのデフォルト値と等しい値と共に「ドキュメント・フォーマット」属性を供給するかのようにすなわち、Printerは以下の規則に従います) . b) クライアントがこの属性を供給しますが、値がPrinterオブジェクトによってサポートされないで、またすなわち、値がPrinterオブジェクトの「ドキュメント形式でサポートしている」属性の値の1つでないなら、Printerオブジェクトは、要求を拒絶して、'クライアント誤りドキュメント形式でサポートしていない'ステータスコードに. c)を返さなければなりません。 クライアントがこの属性を供給して、値が'八重奏アプリケーション/ストリーム'である、(すなわち、自動感じられるために、セクション4.1.9を見てください、.1)、形式がPrinterがそうすることができるドキュメント・フォーマットの1つの自動感覚でなく、Printerが操作応答を返す前にこのチェックが起こって、次に、Printerは要求を拒絶して、'形式が支えなかったクライアント誤りドキュメント'ステータスコードd)を返さなければなりません。 クライアントがこの属性を供給して、値がPrinterオブジェクトによってサポートされるなら、Printerはドキュメントデータを解釈できます。
Hastings, et al. Standards Track [Page 43] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[43ページ]: モデルと意味論2000年9月
e) If interpreting of the document data fails before the
Printer returns an operation response, the Printer object
MUST reject the request and return the 'client-error-
document-format-error' status code.
f) If interpreting of the document data fails after the Printer
returns an operation response, the Printer object MUST abort
the job and add the 'document-format-error' value to the
job's "job-state-reasons" attribute.
e) ドキュメント形式誤り'ステータスコードf)はPrinterが操作応答を返して、Printerオブジェクトが要求を拒絶して、'クライアント誤りを返さなければならない前にデータが失敗するドキュメントを解釈します。 Printerが操作応答を返した後にデータが失敗するドキュメントを解釈するなら、Printerオブジェクトは、仕事を中止して、仕事の「仕事の州の理由」属性に'ドキュメント形式誤り'価値を高めなければなりません。
"document-natural-language" (naturalLanguage):
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute. This attribute
specifies the natural language of the document for those
document-formats that require a specification of the natural
language in order to image the document unambiguously. There
are no particular values required for the Printer object to
support.
「ドキュメント自然言語」(naturalLanguage): クライアントOPTIONALLYはこの属性を供給します。 PrinterオブジェクトOPTIONALLYはこの属性をサポートします。 この属性は明白にドキュメントに像を描くために自然言語の仕様を必要とするそれらのドキュメント・フォーマットのためのドキュメントの自然言語を指定します。 支えるPrinterオブジェクトに必要であるどんな特定の値もありません。
"job-k-octets" (integer(0:MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "job-k-
octets-supported" attribute (see section 4.4.33). The client
supplied "job-k-octets" operation attribute identifies the
total size of the document(s) in K octets being submitted (see
section 4.3.17.1 for the complete semantics). If the client
supplies the attribute and the Printer object supports the
attribute, the value of the attribute is used to populate the
Job object's "job-k-octets" Job Description attribute.
「仕事のk八重奏」(整数(0: 最大)): クライアントOPTIONALLYはこの属性を供給します。 PrinterオブジェクトOPTIONALLYはこの属性と「仕事k八重奏でサポートされた」属性をサポートします(セクション4.4.33を見てください)。 クライアントの供給された「仕事のk八重奏」操作属性が提出されるK八重奏における、ドキュメントの総サイズを特定する、(.1が、完全な意味論に関して4.3に.17を区分するのを見る、) クライアントが属性を供給して、Printerオブジェクトが属性をサポートするなら、属性の値は、Jobオブジェクトの「仕事のk八重奏」Job記述属性に居住するのに使用されます。
For this attribute and the following two attributes ("job-
impressions", and "job-media-sheets"), if the client supplies
the attribute, but the Printer object does not support the
attribute, the Printer object ignores the client-supplied
value. If the client supplies the attribute and the Printer
supports the attribute, and the value is within the range of
the corresponding Printer object's "xxx-supported" attribute,
the Printer object MUST use the value to populate the Job
object's "xxx" attribute. If the client supplies the attribute
and the Printer supports the attribute, but the value is
outside the range of the corresponding Printer object's "xxx-
supported" attribute, the Printer object MUST copy the
attribute and its value to the Unsupported Attributes response
group, reject the request, and return the 'client-error-
attributes-or-values-not-supported' status code. If the client
does not supply the attribute, the Printer object MAY choose to
populate the corresponding Job object attribute depending on
whether the Printer object supports the attribute and is able
to calculate or discern the correct value.
この属性と以下の2つの属性のために、クライアントが属性を供給しますが、Printerオブジェクトが属性をサポートしないなら、(「仕事の印象」、および「仕事のメディアシート」)はクライアント供給値を無視しますPrinterが、反対する。 クライアントが属性を供給して、Printerが属性をサポートして、対応するPrinterオブジェクトの「xxxによってサポートしている」属性の範囲の中に値があるなら、Printerオブジェクトは、Jobオブジェクトの"xxx"属性に居住するのに値を使用しなければなりません。 クライアントが属性を供給して、Printerが属性をサポートしますが、対応するPrinterオブジェクトの「サポートされたxxx」属性の範囲の外に値があるなら、Printerオブジェクトは、Unsupported Attributes応答グループに属性とその値をコピーして、要求を拒絶して、'サポートされなかったクライアント誤り属性か値'ステータスコードを返さなければなりません。 クライアントが属性を供給しないなら、Printerオブジェクトは、正しい値をPrinterオブジェクトが属性をサポートするかどうかに依存する対応するJobオブジェクト属性に居住するのを選ぶかもしれなくて、計算するか、または裁量できます。
Hastings, et al. Standards Track [Page 44] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[44ページ]: モデルと意味論2000年9月
"job-impressions" (integer(0:MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "job-
impressions-supported" attribute (see section 4.4.34). The
client supplied "job-impressions" operation attribute
identifies the total size in number of impressions of the
document(s) being submitted (see section 4.3.17.2 for the
complete semantics).
「仕事印象」(整数(0: 最大)): クライアントOPTIONALLYはこの属性を供給します。 そして、PrinterオブジェクトOPTIONALLYがこの属性をサポートする、「仕事は」 属性を印象でサポートしました(セクション4.4.34を見てください)。 クライアントが操作属性が提出されるドキュメントの印象の数における総サイズを特定するという「仕事印象」を供給した、(.2が、完全な意味論に関して4.3に.17を区分するのを見る、)
See last paragraph under "job-k-octets".
「仕事のk八重奏」で最後のパラグラフを見てください。
"job-media-sheets" (integer(0:MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "job-media-
sheets-supported" attribute (see section 4.4.35). The client
supplied "job-media-sheets" operation attribute identifies the
total number of media sheets to be produced for this job (see
section 4.3.17.3 for the complete semantics).
「仕事のメディアシート」(整数(0: 最大)): クライアントOPTIONALLYはこの属性を供給します。 PrinterオブジェクトOPTIONALLYはこの属性と「シートで仕事メディアによってサポートしている」属性をサポートします(セクション4.4.35を見てください)。 クライアントの供給された「仕事のメディアシート」操作属性がこの仕事のために生産されるためにメディアシートの総数を特定する、(.3が、完全な意味論に関して4.3に.17を区分するのを見る、)
See last paragraph under "job-k-octets".
「仕事のk八重奏」で最後のパラグラフを見てください。
Group 2: Job Template Attributes
グループ2: 仕事のテンプレート属性
The client OPTIONALLY supplies a set of Job Template attributes as
defined in section 4.2. If the client is not supplying any Job
Template attributes in the request, the client SHOULD omit Group 2
rather than sending an empty group. However, a Printer object
MUST be able to accept an empty group.
クライアントOPTIONALLYはセクション4.2で定義されるように1セットのJob Template属性を供給します。 クライアントが要求におけるどんなJob Template属性も供給していないなら、クライアントSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、Printerオブジェクトは空のグループを受け入れることができなければなりません。
Group 3: Document Content
グループ3: ドキュメント内容
The client MUST supply the document data to be processed.
クライアントは、処理されるためにドキュメントデータを提供しなければなりません。
In addition to the MANDATORY parameters required for every
operation request, the simplest Print-Job Request consists of just
the "attributes-charset" and "attributes-natural-language"
operation attributes; the "printer-uri" target operation
attribute; the Document Content and nothing else. In this simple
case, the Printer object:
あらゆる操作要求に必要であるMANDATORYパラメタに加えて、最も簡単なPrint-仕事のRequestはまさしく「属性-charset」と「属性自然言語」操作属性から成ります。 「プリンタ-uri」目標操作属性。 Document Contentと他に何も。 この簡単な場合では、Printerは反対します:
- creates a new Job object (the Job object contains a single
document),
- stores a generated Job name in the "job-name" attribute in the
natural language and charset requested (see Section 3.1.4.1) (if
those are supported, otherwise using the Printer object's
default natural language and charset), and
- そして自然言語の「ジョブ名」属性における発生しているJob名を保存して、charsetに要求されていて、新しいJobオブジェクト(Jobオブジェクトはただ一つのドキュメントを含んでいる)を作成する、(見る、セクション3.1 .4 .1) (そうでなければ、Printerオブジェクトのデフォルトの自然言語とcharsetを使用して、ものがサポートされるなら)。
Hastings, et al. Standards Track [Page 45] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[45ページ]: モデルと意味論2000年9月
- at job processing time, uses its corresponding default value
attributes for the supported Job Template attributes that were
not supplied by the client as IPP attribute or embedded
instructions in the document data.
- IPP属性としてクライアントによって供給されなかったか、またはドキュメントデータに指示を埋め込んだサポートしているJob Template属性のためのジョブ処理時間、用途の対応するデフォルト値属性。
3.2.1.2 Print-Job Response
3.2.1.2 印刷仕事の応答
The Printer object MUST return to the client the following sets of attributes as part of the Print-Job Response:
PrinterオブジェクトはPrint-仕事のResponseの一部として以下のセットの属性をクライアントに返さなければなりません:
Group 1: Operation Attributes
グループ1: 操作属性
Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text(255)) and/or a "detailed-status-message" (text(MAX))
operation attribute as described in sections 13 and 3.1.6. If
the client supplies unsupported or conflicting Job Template
attributes or values, the Printer object MUST reject or accept
the Print-Job request depending on the whether the client
supplied a 'true' or 'false' value for the "ipp-attribute-
fidelity" operation attribute. See the Implementer's Guide
[IPP-IIG] for a complete description of the suggested steps for
processing a create request.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて応答OPTIONALLYは「ステータスメッセージ」を含んでいます。(テキスト(255))、そして/または、セクション13と3.1.6で説明される「詳細なステータスメッセージ」(テキスト(MAX))操作属性。 クライアントがサポートされないか闘争しているJob Templateに属性か値を供給するなら、Printerオブジェクトは、「ipp信義を結果と考えている」操作属性のためにクライアントが'本当さ'を供給したか、そして、'誤り'値に依存するPrint-仕事の要求を、拒絶しなければならないか、または受け入れなければなりません。 aを処理するための提案されたステップの完全な記述のためのImplementerのガイド[IPP-IIG]が要求を作成するのを見てください。
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
自然言語と文字コード: セクション3.1.4で.2に説明される「属性-charset」と「属性自然言語」属性
Group 2: Unsupported Attributes
グループ2: サポートされない属性
See section 3.1.7 for details on returning Unsupported Attributes.
戻っているUnsupported Attributesに関する詳細に関してセクション3.1.7を見てください。
The value of the "ipp-attribute-fidelity" supplied by the client
does not affect what attributes the Printer object returns in this
group. The value of "ipp-attribute-fidelity" only affects whether
the Print-Job operation is accepted or rejected. If the job is
accepted, the client may query the job using the Get-Job-
Attributes operation requesting the unsupported attributes that
were returned in the create response to see which attributes were
ignored (not stored on the Job object) and which attributes were
stored with other (substituted) values.
クライアントによって供給された「ipp属性信義」の値は、Printerオブジェクトがこのグループでどんな属性を返すかに影響しません。 「ipp属性信義」の値は、Print-仕事の操作を受け入れるか、または拒絶するかに影響するだけです。 仕事を受け入れるなら、クライアントが中に返されたサポートされない属性を要求するGet賃仕事の属性の操作を使用することで仕事について質問するかもしれない、応答を作成して、どの属性が無視されたか、そして、(Jobオブジェクトの上に保存されません)どの属性が他の(代入します)値で保存されたか確認してください。
Hastings, et al. Standards Track [Page 46] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[46ページ]: モデルと意味論2000年9月
Group 3: Job Object Attributes
グループ3: 仕事のオブジェクト属性
"job-uri" (uri):
The Printer object MUST return the Job object's URI by
returning the contents of the REQUIRED "job-uri" Job object
attribute. The client uses the Job object's URI when directing
operations at the Job object. The Printer object always uses
its configured security policy when creating the new URI.
However, if the Printer object supports more than one URI, the
Printer object also uses information about which URI was used
in the Print-Job Request to generated the new URI so that the
new URI references the correct access channel. In other words,
if the Print-Job Request comes in over a secure channel, the
Printer object MUST generate a Job URI that uses the secure
channel as well.
「仕事-uri」(uri): Printerオブジェクトは、REQUIRED「仕事-uri」Jobオブジェクト属性のコンテンツを返すことによって、JobオブジェクトのURIを返さなければなりません。 Jobオブジェクトに操作を向けるとき、クライアントはJobオブジェクトのURIを使用します。 新しいURIを作成するとき、Printerオブジェクトはいつも構成された安全保障政策を使用します。 しかしながら、Printerオブジェクトが、したがって、また、URIがPrint-仕事のRequestにどれに使用されたかに関して使用するURI、Printerが情報を反対させる1つが新しいURIを生成したよりそれが新しいURI参照であるとサポートするなら、正しいアクセスは向けられます。 言い換えれば、Print-仕事のRequestが安全なチャンネルの上に入るなら、Printerオブジェクトはまた、安全なチャンネルを使用するJob URIを生成しなければなりません。
"job-id" (integer(1:MAX)):
The Printer object MUST return the Job object's Job ID by
returning the REQUIRED "job-id" Job object attribute. The
client uses this "job-id" attribute in conjunction with the
"printer-uri" attribute used in the Print-Job Request when
directing Job operations at the Printer object.
「仕事イド」(整数(1: 最大)): Printerオブジェクトは、REQUIRED「仕事イド」Jobオブジェクト属性を返すことによって、JobオブジェクトのJob IDを返さなければなりません。 クライアントはJob操作をPrinterオブジェクトに向けるときPrint-仕事のRequestに使用される「プリンタ-uri」属性に関連してこの「仕事イド」属性を使用します。
"job-state" (type1 enum):
The Printer object MUST return the Job object's REQUIRED "job-
state" attribute. The value of this attribute (along with the
value of the next attribute: "job-state-reasons") is taken
from a "snapshot" of the new Job object at some meaningful
point in time (implementation defined) between when the Printer
object receives the Print-Job Request and when the Printer
object returns the response.
「仕事状態」(type1 enum): PrinterオブジェクトはJobオブジェクトのREQUIRED「仕事の状態」属性を返さなければなりません。 時間内に(定義された実装)、Printer目的がPrint-仕事のRequestを受ける時、Printerオブジェクトが応答を返すときに時何らかの重要なポイントで新しいJobオブジェクトの「スナップ」からこの属性(次の属性の値と共に: 「仕事の状態は推論する」)の値を取ります。
"job-state-reasons" (1setOf type2 keyword):
The Printer object MUST return the Job object's REQUIRED "job-
state-reasons" attribute.
「仕事の状態は推論する」(1setOf type2キーワード): PrinterオブジェクトはJobオブジェクトのREQUIRED「仕事の州理由」属性を返さなければなりません。
"job-state-message" (text(MAX)):
The Printer object OPTIONALLY returns the Job object's OPTIONAL
"job-state-message" attribute. If the Printer object supports
this attribute then it MUST be returned in the response. If
this attribute is not returned in the response, the client can
assume that the "job-state-message" attribute is not supported
and will not be returned in a subsequent Job object query.
「仕事の州のメッセージ」(テキスト(最大)): PrinterオブジェクトOPTIONALLYはJobオブジェクトのOPTIONAL「仕事の州のメッセージ」属性を返します。 Printerオブジェクトがこの属性をサポートするなら、応答でそれを返さなければなりません。 この属性が応答で返されないなら、クライアントは、「仕事の州のメッセージ」属性がサポートされないで、またその後のJobオブジェクト質問で返されないと仮定できます。
"number-of-intervening-jobs" (integer(0:MAX)):
The Printer object OPTIONALLY returns the Job object's OPTIONAL
"number-of-intervening-jobs" attribute. If the Printer object
supports this attribute then it MUST be returned in the
「介入している仕事の数」(整数(0: 最大)): PrinterオブジェクトOPTIONALLYはJobオブジェクトのOPTIONAL「介入している仕事の数」属性を返します。 Printerオブジェクトはそれを返さなければならないその時をこの属性にサポートします。
Hastings, et al. Standards Track [Page 47] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[47ページ]: モデルと意味論2000年9月
response. If this attribute is not returned in the response,
the client can assume that the "number-of-intervening-jobs"
attribute is not supported and will not be returned in a
subsequent Job object query.
応答。 この属性が応答で返されないなら、クライアントは、「介入している仕事の数」属性がサポートされないで、またその後のJobオブジェクト質問で返されないと仮定できます。
Note: Since any printer state information which affects a job's
state is reflected in the "job-state" and "job-state-reasons"
attributes, it is sufficient to return only these attributes
and no specific printer status attributes.
以下に注意してください。 仕事の状態に影響するどんなプリンタ州の情報も「仕事状態」と「仕事の州の理由」属性に反映されるので、これらの属性だけを返しますが、どんな特定のプリンタ状態属性も返さないのが十分です。
Note: In addition to the MANDATORY parameters required for every operation response, the simplest response consists of the just the "attributes-charset" and "attributes-natural-language" operation attributes and the "job-uri", "job-id", and "job-state" Job Object Attributes. In this simplest case, the status code is 'successful- ok' and there is no "status-message" or "detailed-status-message" operation attribute.
以下に注意してください。 あらゆる操作応答に必要であるMANDATORYパラメタに加えて、最も簡単な応答はまさしく「属性-charset」と「属性自然言語」操作属性、「仕事-uri」、「仕事イド」、および「仕事状態」Job Object Attributesから成ります。 この最も簡単な場合では、ステータスコードは'うまくいっているOK'です、そして、「ステータスメッセージ」か「詳細なステータスメッセージ」操作属性が全くありません。
3.2.2 Print-URI Operation
3.2.2 印刷URI操作
This OPTIONAL operation is identical to the Print-Job operation (section 3.2.1) except that a client supplies a URI reference to the document data using the "document-uri" (uri) operation attribute (in Group 1) rather than including the document data itself. Before returning the response, the Printer MUST validate that the Printer supports the retrieval method (e.g., http, ftp, etc.) implied by the URI, and MUST check for valid URI syntax. If the client-supplied URI scheme is not supported, i.e. the value is not in the Printer object's "referenced-uri-scheme-supported" attribute, the Printer object MUST reject the request and return the 'client-error-uri- scheme-not-supported' status code.
クライアントがドキュメントデータ自体を含んでいるよりむしろ、「ドキュメント-uri」(uri)操作属性(Group1の)を使用することでURI参照をドキュメントデータに供給するのを除いて、このOPTIONAL操作はPrint-仕事の操作(セクション3.2.1)と同じです。 応答を返すPrinterがそれを有効にしなければならない前に、Printerは検索がURIによって含意されたメソッド(例えば、http、ftpなど)であるとサポートして、有効なURI構文がないかどうかチェックしなければなりません。 クライアントによって供給されたURI体系がサポートされないなら、すなわち、値がPrinterオブジェクトの「サポートされた参照をつけられたuri体系」属性になくて、Printerオブジェクトは、要求を拒絶して、'サポートされなかったクライアント誤り-uri体系'ステータスコードを返さなければなりません。
The IPP Printer MAY validate the accessibility of the document as part of the operation or subsequently. If the Printer determines an accessibility problem before returning an operation response, it rejects the request and returns the 'client-error-document-access- error' status code. The Printer MAY also return a specific document access error code using the "document-access-error" operation attribute (see section 3.1.6.4).
IPP Printerは次に、操作の一部としてドキュメントのアクセシビリティを有効にするかもしれません。 操作応答を返す前にPrinterがアクセシビリティ問題を決定するなら、それは、要求を拒絶して、'クライアント誤りドキュメントアクセス誤りに'ステータスコードを返します。 セクション3.1を見てください。また、「ドキュメントアクセスエラー」操作属性を使用して、Printerが特定のドキュメントアクセスエラーコードを返すかもしれない、(.6 .4)。
If the Printer determines this document accessibility problem after accepting the request and returning an operation response with one of the successful status codes, the Printer adds the 'document-access- error' value to the job's "job-state-reasons" attribute and MAY populate the job's "job-document-access-errors" Job Description attribute (see section 4.3.11). See The Implementer's Guide [IPP- IIG] for suggested additional checks.
うまくいっているステータスコードの1つと共に要請を受け入れて、操作応答を返した後にPrinterがこのドキュメントアクセシビリティ問題を決定するなら、Printerは'ドキュメント誤りにアクセスしている'価値を仕事の「仕事の州の理由」属性に高めて、仕事の「仕事のドキュメントアクセスエラー」Job記述属性に居住するかもしれません(セクション4.3.11を見てください)。 提案された追加チェックのためのImplementerのガイド[IPP- IIG]を見てください。
Hastings, et al. Standards Track [Page 48] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[48ページ]: モデルと意味論2000年9月
If the Printer object supports this operation, it MUST support the "reference-uri-schemes-supported" Printer attribute (see section 4.4.27).
Printerオブジェクトがこの操作をサポートするなら、それは「uri体系がサポートした参照」Printer属性をサポートしなければなりません(セクション4.4.27を見てください)。
It is up to the IPP object to interpret the URI and subsequently "pull" the document from the source referenced by the URI string.
URIストリングによって参照をつけられるソースからURIを解釈して、次にドキュメントを「引くこと」は、IPPオブジェクト次第です。
3.2.3 Validate-Job Operation
3.2.3 仕事を有効にしている操作
This REQUIRED operation is similar to the Print-Job operation (section 3.2.1) except that a client supplies no document data and the Printer allocates no resources (i.e., it does not create a new Job object). This operation is used only to verify capabilities of a printer object against whatever attributes are supplied by the client in the Validate-Job request. By using the Validate-Job operation a client can validate that an identical Print-Job operation (with the document data) would be accepted. The Validate-Job operation also performs the same security negotiation as the Print-Job operation (see section 8), so that a client can check that the client and Printer object security requirements can be met before performing a Print-Job operation.
クライアントがドキュメントデータを全く提供しないで、またPrinterがリソースを全く割り当てないのを除いて(すなわち、それは新しいJobオブジェクトを作成しません)、このREQUIRED操作はPrint-仕事の操作(セクション3.2.1)と同様です。 この操作は使用されますが、Validate-仕事の要求でクライアントによって供給されるどんな属性に対してプリンタオブジェクトの能力について確かめます。 クライアントが有効にすることができる同じPrint-仕事の操作(ドキュメントデータがある)が使用するValidate-仕事の操作を使用することによって、受け入れてください。 また、Validate-仕事の操作はPrint-仕事の操作と同じセキュリティ交渉を実行します(セクション8を見てください)、クライアントが、Print-仕事の操作を実行する前にクライアントとPrinterオブジェクトセキュリティ必要条件を満たすことができるのをチェックできるように。
The Validate-Job operation does not accept a "document-uri" attribute in order to allow a client to check that the same Print-URI operation will be accepted, since the client doesn't send the data with the Print-URI operation. The client SHOULD just issue the Print-URI request.
Validate-仕事の操作はクライアントが、同じPrint-URI操作が受け入れられるのをチェックするのを許容するために「ドキュメント-uri」属性を受け入れません、クライアントがPrint-URI操作と共にデータを送らないので。 クライアントSHOULDはただPrint-URI要求を出します。
The Printer object returns the same status codes, Operation Attributes (Group 1) and Unsupported Attributes (Group 2) as the Print-Job operation. However, no Job Object Attributes (Group 3) are returned, since no Job object is created.
PrinterオブジェクトはPrint-仕事の操作として同じステータスコード、Operation Attributes(グループ1)、およびUnsupported Attributes(グループ2)を返します。 しかしながら、Jobオブジェクトが全く作成されないので、Job Object Attributes(グループ3)を全く返しません。
3.2.4 Create-Job Operation
3.2.4 雇用を創り出している操作
This OPTIONAL operation is similar to the Print-Job operation (section 3.2.1) except that in the Create-Job request, a client does not supply document data or any reference to document data. Also, the client does not supply any of the "document-name", "document- format", "compression", or "document-natural-language" operation attributes. This operation is followed by one or more Send-Document or Send-URI operations. In each of those operation requests, the client OPTIONALLY supplies the "document-name", "document-format", and "document-natural-language" attributes for each document in the multi-document Job object.
クライアントがCreate-仕事の要求でドキュメントデータか少しの参照もドキュメントデータに供給しないのを除いて、このOPTIONAL操作はPrint-仕事の操作(セクション3.2.1)と同様です。 また、クライアントは「ドキュメント名」、「ドキュメント形式」、「圧縮」、または「ドキュメント自然言語」操作属性のいずれも供給しません。 1通以上のSend-ドキュメントかSend-URI操作はこの操作のあとに続いています。 それぞれのそれらの操作要求では、クライアントOPTIONALLYは「ドキュメント名」、「ドキュメント・フォーマット」、および「ドキュメント自然言語」属性をマルチドキュメントJobオブジェクトの各ドキュメントに供給します。
Hastings, et al. Standards Track [Page 49] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[49ページ]: モデルと意味論2000年9月
If a Printer object supports the Create-Job operation, it MUST also support the Send-Document operation and also MAY support the Send-URI operation.
PrinterオブジェクトがCreate-仕事の操作をサポートするなら、それは、また、Send-ドキュメントが操作であるとサポートしなければならなくて、また、Send-URI操作をサポートするかもしれません。
If the Printer object supports this operation, it MUST support the "multiple-operation-time-out" Printer attribute (see section 4.4.31).
Printerオブジェクトがこの操作をサポートするなら、それは「複数の操作タイムアウト」Printer属性をサポートしなければなりません(セクション4.4.31を見てください)。
If the Printer object supports this operation, then it MUST support the "multiple-document-jobs-supported" Printer Description attribute (see section 4.4.16) and indicate whether or not it supports multiple-document jobs.
Printerオブジェクトがこの操作をサポートするなら、それは、「仕事が支えた複数のドキュメント」Printer記述属性(セクション4.4.16を見る)をサポートして、複数のドキュメント仕事をサポートするかどうかを示さなければなりません。
If the Printer object supports this operation and supports multiple documents in a job, then it MUST support the "multiple-document- handling" Job Template job attribute with at least one value (see section 4.2.4) and the associated "multiple-document-handling- default" and "multiple-document-handling-supported" Job Template Printer attributes (see section 4.2).
Printerオブジェクトがこの操作をサポートして、仕事で複数のドキュメントを支えるなら、それは少なくとも1つの値(セクション4.2.4を見る)と関連が「複数のドキュメントの取り扱っているデフォルト」であることでの「複数のドキュメントの取り扱い」のJob Template仕事の属性と「取り扱いが支えた複数のドキュメント」Job Template Printer属性をサポートしなければなりません(セクション4.2を見てください)。
After the Create-Job operation has completed, the value of the "job- state" attribute is similar to the "job-state" after a Print-Job, even though no document-data has arrived. A Printer MAY set the 'job-data-insufficient' value of the job's "job-state-reason" attribute to indicate that processing cannot begin until sufficient data has arrived and set the "job-state" to either 'pending' or 'pending-held'. A non-spooling printer that doesn't implement the 'pending' job state may even set the "job-state" to 'processing', even though there is not yet any data to process. See sections 4.3.7 and 4.3.8.
Create-仕事の操作が同様であった後に、完成していて、「仕事の状態」属性の値はPrint-仕事の後に「仕事状態」と同様です、ドキュメントデータは全く到着していませんが。 Printerがセットするかもしれない、'、仕事のデータ不十分である、'その処理を示す仕事の「仕事の州の理由」属性の値は、'未定である'か'未定に保持されること'に十分なデータが到着するまで始まって、「仕事状態」を設定できません。 '未定'の仕事が状態であると実装しない非スプールプリンタは「仕事状態」を'処理'に設定さえするかもしれません、処理する少しのデータもまだありませんが。 .8にセクション4.3 .7と4.3を見てください。
3.2.5 Get-Printer-Attributes Operation
3.2.5 プリンタ属性を得ている操作
This REQUIRED operation allows a client to request the values of the attributes of a Printer object. In the request, the client supplies the set of Printer attribute names and/or attribute group names in which the requester is interested. In the response, the Printer object returns a corresponding attribute set with the appropriate attribute values filled in.
このREQUIRED操作で、クライアントはPrinterオブジェクトの属性の値を要求できます。 要求では、クライアントはリクエスタが興味を持っているPrinter属性名、そして/または、属性グループ名のセットを供給します。 応答では、適切な属性値が記入されている状態で、Printerオブジェクトは対応する属性セットを返します。
For Printer objects, the possible names of attribute groups are:
Printerオブジェクトに関しては、属性グループの可能な名前は以下の通りです。
- 'job-template': the subset of the Job Template attributes that
apply to a Printer object (the last two columns of the table in
Section 4.2) that the implementation supports for Printer
objects.
- 'printer-description': the subset of the attributes specified in
Section 4.4 that the implementation supports for Printer
objects.
- '仕事テンプレート': 実装がPrinterオブジェクトのために支えるPrinterオブジェクト(セクション4.2における、テーブルに関する最後の2つのコラム)に適用されるJob Template属性の部分集合。 - 'プリンタ記述': 属性の部分集合は、セクション4.4で実装がPrinterのためにオブジェクトを支えると指定しました。
Hastings, et al. Standards Track [Page 50] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[50ページ]: モデルと意味論2000年9月
- 'all': the special group 'all' that includes all attributes that
the implementation supports for Printer objects.
- 'すべて': 実装がPrinterオブジェクトのためにサポートするすべての属性を含んでいる特別なグループ'すべて'。
Since a client MAY request specific attributes or named groups, there is a potential that there is some overlap. For example, if a client requests, 'printer-name' and 'all', the client is actually requesting the "printer-name" attribute twice: once by naming it explicitly, and once by inclusion in the 'all' group. In such cases, the Printer object NEED NOT return each attribute only once in the response even if it is requested multiple times. The client SHOULD NOT request the same attribute in multiple ways.
特定の属性であり、グループと命名されて、ある可能性があるというクライアント5月の要求以来、或るものは重なります。 例えば、クライアントが、'プリンタ名'と'すべて'よう要求するなら、クライアントは実際に「プリンタ名」属性を二度要求しています: 明らかに、そして、'すべて'での包含による一度それを命名するのによる一度、分類してください。 そのような場合、それが複数の回要求されても、Printerオブジェクトは応答で各属性を一度だけ返す必要はありません。 クライアントSHOULD NOTは複数の方法で同じ属性を要求します。
It is NOT REQUIRED that a Printer object support all attributes belonging to a group (since some attributes are OPTIONAL). However, it is REQUIRED that each Printer object support all group names.
それはPrinterがグループに属すすべての属性をサポートするのを反対させるNOT REQUIRED(いくつかの属性がOPTIONALであるので)です。 しかしながら、それは各Printerがすべてのグループ名をサポートするのを反対させるREQUIREDです。
3.2.5.1 Get-Printer-Attributes Request
3.2.5.1 プリンタ属性を得ている要求
The following sets of attributes are part of the Get-Printer- Attributes Request:
以下のセットの属性はGet-プリンタ属性Requestの一部です:
Group 1: Operation Attributes
グループ1: 操作属性
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
自然言語と文字コード: セクション3.1.4で.1に説明される「属性-charset」と「属性自然言語」属性
Target:
The "printer-uri" (uri) operation attribute which is the target
for this operation as described in section 3.1.5.
以下を狙ってください。 セクション3.1.5で説明されるようにこの操作のための目標である「プリンタ-uri」(uri)操作属性。
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in section 8.3.
ユーザ名を要求します: 「要求しているユーザ名」(名前(MAX))はSHOULDを結果と考えます。説明されるとしてセクション8.3でクライアントによって供給されてください。
"requested-attributes" (1setOf keyword):
The client OPTIONALLY supplies a set of attribute names and/or
attribute group names in whose values the requester is
interested. The Printer object MUST support this attribute.
If the client omits this attribute, the Printer MUST respond as
if this attribute had been supplied with a value of 'all'.
「要求された属性」(1setOfキーワード): クライアントOPTIONALLYはリクエスタが値に興味を持っている1セットの属性名、そして/または、属性グループ名を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 クライアントがこの属性を省略するなら、Printerはまるで'すべて'の値をこの属性に供給したかのように応じなければなりません。
"document-format" (mimeMediaType):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. This attribute is useful
for a Printer object to determine the set of supported
attribute values that relate to the requested document format.
The Printer object MUST return the attributes and values that
「ドキュメント・フォーマット」(mimeMediaType): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 Printer目的が要求されたドキュメント・フォーマットに関連するサポートしている属性値のセットを決定するように、この属性は役に立ちます。 Printerオブジェクトは、属性を返さなければならなくて、それを評価します。
Hastings, et al. Standards Track [Page 51] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[51ページ]: モデルと意味論2000年9月
it uses to validate a job on a create or Validate-Job operation
in which this document format is supplied. The Printer object
SHOULD return only (1) those attributes that are supported for
the specified format and (2) the attribute values that are
supported for the specified document format. By specifying the
document format, the client can get the Printer object to
eliminate the attributes and values that are not supported for
a specific document format. For example, a Printer object
might have multiple interpreters to support both
'application/postscript' (for PostScript) and 'text/plain' (for
text) documents. However, for only one of those interpreters
might the Printer object be able to support "number-up" with
values of '1', '2', and '4'. For the other interpreter it
might be able to only support "number-up" with a value of '1'.
Thus a client can use the Get-Printer-Attributes operation to
obtain the attributes and values that will be used to
accept/reject a create job operation.
aで仕事を有効にするのに使用する、作成、または、このドキュメント・フォーマットが供給されるValidate-仕事の操作。 PrinterオブジェクトSHOULDは(1) 指定された形式のためにサポートされるそれらの属性と(2) 指定されたドキュメント・フォーマットのためにサポートされる属性値だけを返します。 ドキュメント・フォーマットを指定することによって、クライアントはPrinterオブジェクトに特定のドキュメント・フォーマットのためにサポートされない属性と値を排除させることができます。 例えば、Printerオブジェクトには、両方が'アプリケーション/追伸'(ポストスクリプトのための)と'テキスト/明瞭な'(テキストのための)ドキュメントであるとサポートする複数のインタプリタがあるかもしれません。 しかしながら、それらのインタプリタの唯一の1において、Printerオブジェクトは'1'、'2'、および'4'の値に従った「上に数」をサポートすることができるかもしれませんか? もう片方のインタプリタに関しては、それは'1'の値に従った「上に数」をサポートすることができるだけであるかもしれません。 したがって、クライアントは属性を得るのにGetプリンタ属性操作を使用できます、そして、aを受け入れるか、または拒絶するのに使用される値は仕事の操作を作成します。
If the Printer object does not distinguish between different
sets of supported values for each different document format
when validating jobs in the create and Validate-Job operations,
it MUST NOT distinguish between different document formats in
the Get-Printer-Attributes operation. If the Printer object
does distinguish between different sets of supported values for
each different document format specified by the client, this
specialization applies only to the following Printer object
attributes:
If the Printer object does not distinguish between different sets of supported values for each different document format when validating jobs in the create and Validate-Job operations, it MUST NOT distinguish between different document formats in the Get-Printer-Attributes operation. If the Printer object does distinguish between different sets of supported values for each different document format specified by the client, this specialization applies only to the following Printer object attributes:
- Printer attributes that are Job Template attributes ("xxx-
default" "xxx-supported", and "xxx-ready" in the Table in
Section 4.2),
- "pdl-override-supported",
- "compression-supported",
- "job-k-octets-supported",
- "job-impressions-supported",
- "job-media-sheets-supported",
- "printer-driver-installer",
- "color-supported", and
- "reference-uri-schemes-supported"
- Printer attributes that are Job Template attributes ("xxx- default" "xxx-supported", and "xxx-ready" in the Table in Section 4.2), - "pdl-override-supported", - "compression-supported", - "job-k-octets-supported", - "job-impressions-supported", - "job-media-sheets-supported", - "printer-driver-installer", - "color-supported", and - "reference-uri-schemes-supported"
The values of all other Printer object attributes (including
"document-format-supported") remain invariant with respect to the
client supplied document format (except for new Printer
description attribute as registered according to section 6.2).
The values of all other Printer object attributes (including "document-format-supported") remain invariant with respect to the client supplied document format (except for new Printer description attribute as registered according to section 6.2).
If the client omits this "document-format" operation attribute,
the Printer object MUST respond as if the attribute had been
supplied with the value of the Printer object's "document-format-
If the client omits this "document-format" operation attribute, the Printer object MUST respond as if the attribute had been supplied with the value of the Printer object's "document-format-
Hastings, et al. Standards Track [Page 52] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 52] RFC 2911 IPP/1.1: Model and Semantics September 2000
default" attribute. It is RECOMMENDED that the client always
supply a value for "document-format", since the Printer object's
"document-format-default" may be 'application/octet-stream', in
which case the returned attributes and values are for the union of
the document formats that the Printer can automatically sense.
For more details, see the description of the 'mimeMediaType'
attribute syntax in section 4.1.9.
default" attribute. It is RECOMMENDED that the client always supply a value for "document-format", since the Printer object's "document-format-default" may be 'application/octet-stream', in which case the returned attributes and values are for the union of the document formats that the Printer can automatically sense. For more details, see the description of the 'mimeMediaType' attribute syntax in section 4.1.9.
If the client supplies a value for the "document-format" Operation
attribute that is not supported by the Printer, i.e., is not among
the values of the Printer object's "document-format-supported"
attribute, the Printer object MUST reject the operation and return
the 'client-error-document-format-not-supported' status code.
If the client supplies a value for the "document-format" Operation attribute that is not supported by the Printer, i.e., is not among the values of the Printer object's "document-format-supported" attribute, the Printer object MUST reject the operation and return the 'client-error-document-format-not-supported' status code.
3.2.5.2 Get-Printer-Attributes Response
3.2.5.2 Get-Printer-Attributes Response
The Printer object returns the following sets of attributes as part of the Get-Printer-Attributes Response:
The Printer object returns the following sets of attributes as part of the Get-Printer-Attributes Response:
Group 1: Operation Attributes
Group 1: Operation Attributes
Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text(255)) and/or a "detailed-status-message" (text(MAX))
operation attribute as described in sections 13 and 3.1.6.
Status Message: In addition to the REQUIRED status code returned in every response, the response OPTIONALLY includes a "status-message" (text(255)) and/or a "detailed-status-message" (text(MAX)) operation attribute as described in sections 13 and 3.1.6.
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in section 3.1.4.2.
Group 2: Unsupported Attributes
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
See section 3.1.7 for details on returning Unsupported Attributes.
The response NEED NOT contain the "requested-attributes" operation
attribute with any supplied values (attribute keywords) that were
requested by the client but are not supported by the IPP object.
If the Printer object does return unsupported attributes
referenced in the "requested-attributes" operation attribute and
that attribute included group names, such as 'all', the
unsupported attributes MUST NOT include attributes described in
the standard but not supported by the implementation.
The response NEED NOT contain the "requested-attributes" operation attribute with any supplied values (attribute keywords) that were requested by the client but are not supported by the IPP object. If the Printer object does return unsupported attributes referenced in the "requested-attributes" operation attribute and that attribute included group names, such as 'all', the unsupported attributes MUST NOT include attributes described in the standard but not supported by the implementation.
Hastings, et al. Standards Track [Page 53] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 53] RFC 2911 IPP/1.1: Model and Semantics September 2000
Group 3: Printer Object Attributes
Group 3: Printer Object Attributes
This is the set of requested attributes and their current values.
The Printer object ignores (does not respond with) any requested
attribute which is not supported. The Printer object MAY respond
with a subset of the supported attributes and values, depending on
the security policy in force. However, the Printer object MUST
respond with the 'unknown' value for any supported attribute
(including all REQUIRED attributes) for which the Printer object
does not know the value. Also the Printer object MUST respond
with the 'no-value' for any supported attribute (including all
REQUIRED attributes) for which the system administrator has not
configured a value. See the description of the "out-of-band"
values in the beginning of Section 4.1.
This is the set of requested attributes and their current values. The Printer object ignores (does not respond with) any requested attribute which is not supported. The Printer object MAY respond with a subset of the supported attributes and values, depending on the security policy in force. However, the Printer object MUST respond with the 'unknown' value for any supported attribute (including all REQUIRED attributes) for which the Printer object does not know the value. Also the Printer object MUST respond with the 'no-value' for any supported attribute (including all REQUIRED attributes) for which the system administrator has not configured a value. See the description of the "out-of-band" values in the beginning of Section 4.1.
3.2.6 Get-Jobs Operation
3.2.6 Get-Jobs Operation
This REQUIRED operation allows a client to retrieve the list of Job objects belonging to the target Printer object. The client may also supply a list of Job attribute names and/or attribute group names. A group of Job object attributes will be returned for each Job object that is returned.
This REQUIRED operation allows a client to retrieve the list of Job objects belonging to the target Printer object. The client may also supply a list of Job attribute names and/or attribute group names. A group of Job object attributes will be returned for each Job object that is returned.
This operation is similar to the Get-Job-Attributes operation, except that this Get-Jobs operation returns attributes from possibly more than one object.
This operation is similar to the Get-Job-Attributes operation, except that this Get-Jobs operation returns attributes from possibly more than one object.
3.2.6.1 Get-Jobs Request
3.2.6.1 Get-Jobs Request
The client submits the Get-Jobs request to a Printer object.
The client submits the Get-Jobs request to a Printer object.
The following groups of attributes are part of the Get-Jobs Request:
The following groups of attributes are part of the Get-Jobs Request:
Group 1: Operation Attributes
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in section 3.1.4.1.
Target:
The "printer-uri" (uri) operation attribute which is the target
for this operation as described in section 3.1.5.
Target: The "printer-uri" (uri) operation attribute which is the target for this operation as described in section 3.1.5.
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in section 8.3.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in section 8.3.
Hastings, et al. Standards Track [Page 54] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 54] RFC 2911 IPP/1.1: Model and Semantics September 2000
"limit" (integer(1:MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It is an integer value that
determines the maximum number of jobs that a client will
receive from the Printer even if "which-jobs" or "my-jobs"
constrain which jobs are returned. The limit is a "stateless
limit" in that if the value supplied by the client is 'N', then
only the first 'N' jobs are returned in the Get-Jobs Response.
There is no mechanism to allow for the next 'M' jobs after the
first 'N' jobs. If the client does not supply this attribute,
the Printer object responds with all applicable jobs.
"limit" (integer(1:MAX)): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. It is an integer value that determines the maximum number of jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. There is no mechanism to allow for the next 'M' jobs after the first 'N' jobs. If the client does not supply this attribute, the Printer object responds with all applicable jobs.
"requested-attributes" (1setOf type2 keyword):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It is a set of Job
attribute names and/or attribute groups names in whose values
the requester is interested. This set of attributes is
returned for each Job object that is returned. The allowed
attribute group names are the same as those defined in the
Get-Job-Attributes operation in section 3.3.4. If the client
does not supply this attribute, the Printer MUST respond as if
the client had supplied this attribute with two values: 'job-
uri' and 'job-id'.
"requested-attributes" (1setOf type2 keyword): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. It is a set of Job attribute names and/or attribute groups names in whose values the requester is interested. This set of attributes is returned for each Job object that is returned. The allowed attribute group names are the same as those defined in the Get-Job-Attributes operation in section 3.3.4. If the client does not supply this attribute, the Printer MUST respond as if the client had supplied this attribute with two values: 'job- uri' and 'job-id'.
"which-jobs" (type2 keyword):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It indicates which Job
objects MUST be returned by the Printer object. The values for
this attribute are:
"which-jobs" (type2 keyword): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. It indicates which Job objects MUST be returned by the Printer object. The values for this attribute are:
'completed': This includes any Job object whose state is
'completed', 'canceled', or 'aborted'.
'not-completed': This includes any Job object whose state is
'pending', 'processing', 'processing-stopped', or 'pending-
held'.
'completed': This includes any Job object whose state is 'completed', 'canceled', or 'aborted'. 'not-completed': This includes any Job object whose state is 'pending', 'processing', 'processing-stopped', or 'pending- held'.
A Printer object MUST support both values. However, if the
implementation does not keep jobs in the 'completed',
'canceled', and 'aborted' states, then it returns no jobs when
the 'completed' value is supplied.
A Printer object MUST support both values. However, if the implementation does not keep jobs in the 'completed', 'canceled', and 'aborted' states, then it returns no jobs when the 'completed' value is supplied.
If a client supplies some other value, the Printer object MUST
copy the attribute and the unsupported value to the Unsupported
Attributes response group, reject the request, and return the
'client-error-attributes-or-values-not-supported' status code.
If a client supplies some other value, the Printer object MUST copy the attribute and the unsupported value to the Unsupported Attributes response group, reject the request, and return the 'client-error-attributes-or-values-not-supported' status code.
Hastings, et al. Standards Track [Page 55] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 55] RFC 2911 IPP/1.1: Model and Semantics September 2000
If the client does not supply this attribute, the Printer
object MUST respond as if the client had supplied the attribute
with a value of 'not-completed'.
If the client does not supply this attribute, the Printer object MUST respond as if the client had supplied the attribute with a value of 'not-completed'.
"my-jobs" (boolean):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It indicates whether jobs
from all users or just the jobs submitted by the requesting
user of this request MUST be considered as candidate jobs to be
returned by the Printer object. If the client does not supply
this attribute, the Printer object MUST respond as if the
client had supplied the attribute with a value of 'false',
i.e., jobs from all users. The means for authenticating the
requesting user and matching the jobs is described in section
8.
"my-jobs" (boolean): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. It indicates whether jobs from all users or just the jobs submitted by the requesting user of this request MUST be considered as candidate jobs to be returned by the Printer object. If the client does not supply this attribute, the Printer object MUST respond as if the client had supplied the attribute with a value of 'false', i.e., jobs from all users. The means for authenticating the requesting user and matching the jobs is described in section 8.
3.2.6.2 Get-Jobs Response
3.2.6.2 Get-Jobs Response
The Printer object returns all of the Job objects up to the number specified by the "limit" attribute that match the criteria as defined by the attribute values supplied by the client in the request. It is possible that no Job objects are returned since there may literally be no Job objects at the Printer, or there may be no Job objects that match the criteria supplied by the client. If the client requests any Job attributes at all, there is a set of Job Object Attributes returned for each Job object.
The Printer object returns all of the Job objects up to the number specified by the "limit" attribute that match the criteria as defined by the attribute values supplied by the client in the request. It is possible that no Job objects are returned since there may literally be no Job objects at the Printer, or there may be no Job objects that match the criteria supplied by the client. If the client requests any Job attributes at all, there is a set of Job Object Attributes returned for each Job object.
It is not an error for the Printer to return 0 jobs. If the response returns 0 jobs because there are no jobs matching the criteria, and the request would have returned 1 or more jobs with a status code of 'successful-ok' if there had been jobs matching the criteria, then the status code for 0 jobs MUST be 'successful-ok'.
It is not an error for the Printer to return 0 jobs. If the response returns 0 jobs because there are no jobs matching the criteria, and the request would have returned 1 or more jobs with a status code of 'successful-ok' if there had been jobs matching the criteria, then the status code for 0 jobs MUST be 'successful-ok'.
Group 1: Operation Attributes
Group 1: Operation Attributes
Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text(255)) and/or a "detailed-status-message" (text(MAX))
operation attribute as described in sections 13 and 3.1.6.
Status Message: In addition to the REQUIRED status code returned in every response, the response OPTIONALLY includes a "status-message" (text(255)) and/or a "detailed-status-message" (text(MAX)) operation attribute as described in sections 13 and 3.1.6.
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in section 3.1.4.2.
Hastings, et al. Standards Track [Page 56] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 56] RFC 2911 IPP/1.1: Model and Semantics September 2000
Group 2: Unsupported Attributes
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
See section 3.1.7 for details on returning Unsupported Attributes.
The response NEED NOT contain the "requested-attributes" operation
attribute with any supplied values (attribute keywords) that were
requested by the client but are not supported by the IPP object.
If the Printer object does return unsupported attributes
referenced in the "requested-attributes" operation attribute and
that attribute included group names, such as 'all', the
unsupported attributes MUST NOT include attributes described in
the standard but not supported by the implementation.
The response NEED NOT contain the "requested-attributes" operation attribute with any supplied values (attribute keywords) that were requested by the client but are not supported by the IPP object. If the Printer object does return unsupported attributes referenced in the "requested-attributes" operation attribute and that attribute included group names, such as 'all', the unsupported attributes MUST NOT include attributes described in the standard but not supported by the implementation.
Groups 3 to N: Job Object Attributes
Groups 3 to N: Job Object Attributes
The Printer object responds with one set of Job Object Attributes
for each returned Job object. The Printer object ignores (does
not respond with) any requested attribute or value which is not
supported or which is restricted by the security policy in force,
including whether the requesting user is the user that submitted
the job (job originating user) or not (see section 8). However,
the Printer object MUST respond with the 'unknown' value for any
supported attribute (including all REQUIRED attributes) for which
the Printer object does not know the value, unless it would
violate the security policy. See the description of the "out-of-
band" values in the beginning of Section 4.1.
The Printer object responds with one set of Job Object Attributes for each returned Job object. The Printer object ignores (does not respond with) any requested attribute or value which is not supported or which is restricted by the security policy in force, including whether the requesting user is the user that submitted the job (job originating user) or not (see section 8). However, the Printer object MUST respond with the 'unknown' value for any supported attribute (including all REQUIRED attributes) for which the Printer object does not know the value, unless it would violate the security policy. See the description of the "out-of- band" values in the beginning of Section 4.1.
Jobs are returned in the following order:
Jobs are returned in the following order:
- If the client requests all 'completed' Jobs (Jobs in the
'completed', 'aborted', or 'canceled' states), then the Jobs are
returned newest to oldest (with respect to actual completion
time)
- If the client requests all 'not-completed' Jobs (Jobs in the
'pending', 'processing', 'pending-held', and 'processing-
stopped' states), then Jobs are returned in relative
chronological order of expected time to complete (based on
whatever scheduling algorithm is configured for the Printer
object).
- If the client requests all 'completed' Jobs (Jobs in the 'completed', 'aborted', or 'canceled' states), then the Jobs are returned newest to oldest (with respect to actual completion time) - If the client requests all 'not-completed' Jobs (Jobs in the 'pending', 'processing', 'pending-held', and 'processing- stopped' states), then Jobs are returned in relative chronological order of expected time to complete (based on whatever scheduling algorithm is configured for the Printer object).
3.2.7 Pause-Printer Operation
3.2.7 Pause-Printer Operation
This OPTIONAL operation allows a client to stop the Printer object from scheduling jobs on all its devices. Depending on implementation, the Pause-Printer operation MAY also stop the Printer from processing the current job or jobs. Any job that is currently being printed is either stopped as soon as the implementation permits
This OPTIONAL operation allows a client to stop the Printer object from scheduling jobs on all its devices. Depending on implementation, the Pause-Printer operation MAY also stop the Printer from processing the current job or jobs. Any job that is currently being printed is either stopped as soon as the implementation permits
Hastings, et al. Standards Track [Page 57] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 57] RFC 2911 IPP/1.1: Model and Semantics September 2000
or is completed, depending on implementation. The Printer object MUST still accept create operations to create new jobs, but MUST prevent any jobs from entering the 'processing' state.
or is completed, depending on implementation. The Printer object MUST still accept create operations to create new jobs, but MUST prevent any jobs from entering the 'processing' state.
If the Pause-Printer operation is supported, then the Resume-Printer operation MUST be supported, and vice-versa.
If the Pause-Printer operation is supported, then the Resume-Printer operation MUST be supported, and vice-versa.
The IPP Printer stops the current job(s) on its device(s) that were in the 'processing' or 'processing-stopped' states as soon as the implementation permits. If the implementation will take appreciable time to stop, the IPP Printer adds the 'moving-to-paused' value to the Printer object's "printer-state-reasons" attribute (see section 4.4.12). When the device(s) have all stopped, the IPP Printer transitions the Printer object to the 'stopped' state, removes the 'moving-to-paused' value, if present, and adds the 'paused' value to the Printer object's "printer-state-reasons" attribute.
The IPP Printer stops the current job(s) on its device(s) that were in the 'processing' or 'processing-stopped' states as soon as the implementation permits. If the implementation will take appreciable time to stop, the IPP Printer adds the 'moving-to-paused' value to the Printer object's "printer-state-reasons" attribute (see section 4.4.12). When the device(s) have all stopped, the IPP Printer transitions the Printer object to the 'stopped' state, removes the 'moving-to-paused' value, if present, and adds the 'paused' value to the Printer object's "printer-state-reasons" attribute.
When the current job(s) complete that were in the 'processing' state, the IPP Printer transitions them to the 'completed' state. When the current job(s) stop in mid processing that were in the 'processing' state, the IPP Printer transitions them to the 'processing-stopped' state and adds the 'printer-stopped' value to the job's "job-state- reasons" attribute.
When the current job(s) complete that were in the 'processing' state, the IPP Printer transitions them to the 'completed' state. When the current job(s) stop in mid processing that were in the 'processing' state, the IPP Printer transitions them to the 'processing-stopped' state and adds the 'printer-stopped' value to the job's "job-state- reasons" attribute.
For any jobs that are 'pending' or 'pending-held', the 'printer- stopped' value of the jobs' "job-state-reasons" attribute also applies. However, the IPP Printer NEED NOT update those jobs' "job- state-reasons" attributes and only need return the 'printer-stopped' value when those jobs are queried (so-called "lazy evaluation").
For any jobs that are 'pending' or 'pending-held', the 'printer- stopped' value of the jobs' "job-state-reasons" attribute also applies. However, the IPP Printer NEED NOT update those jobs' "job- state-reasons" attributes and only need return the 'printer-stopped' value when those jobs are queried (so-called "lazy evaluation").
Whether the Pause-Printer operation affects jobs that were submitted to the device from other sources than the IPP Printer object in the same way that the Pause-Printer operation affects jobs that were submitted to the IPP Printer object using IPP, depends on implementation, i.e., on whether the IPP protocol is being used as a universal management protocol or just to manage IPP jobs, respectively.
Whether the Pause-Printer operation affects jobs that were submitted to the device from other sources than the IPP Printer object in the same way that the Pause-Printer operation affects jobs that were submitted to the IPP Printer object using IPP, depends on implementation, i.e., on whether the IPP protocol is being used as a universal management protocol or just to manage IPP jobs, respectively.
The IPP Printer MUST accept the request in any state and transition the Printer to the indicated new "printer-state" before returning as follows:
The IPP Printer MUST accept the request in any state and transition the Printer to the indicated new "printer-state" before returning as follows:
Hastings, et al. Standards Track [Page 58] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 58] RFC 2911 IPP/1.1: Model and Semantics September 2000
Current New "printer IPP Printer's response status
"printer- "printer- -state- code and action:
state" state" reasons"
Current New "printer IPP Printer's response status "printer- "printer- -state- code and action: state" state" reasons"
'idle' 'stopped' 'paused' 'successful-ok'
'processing' 'processing' 'moving- OPTION 1: 'successful-ok';
to- Later, when all output has
paused' stopped, the "printer-state"
becomes 'stopped', and the
'paused' value replaces the
'moving-to-paused' value in the
"printer-state-reasons"
attribute
'processing' 'stopped' 'paused' OPTION 2: 'successful-ok';
all device output stopped
immediately
'stopped' 'stopped' 'paused' 'successful-ok'
'idle' 'stopped' 'paused' 'successful-ok' 'processing' 'processing' 'moving- OPTION 1: 'successful-ok'; to- Later, when all output has paused' stopped, the "printer-state" becomes 'stopped', and the 'paused' value replaces the 'moving-to-paused' value in the "printer-state-reasons" attribute 'processing' 'stopped' 'paused' OPTION 2: 'successful-ok'; all device output stopped immediately 'stopped' 'stopped' 'paused' 'successful-ok'
Access Rights: The authenticated user (see section 8.3) performing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the operation and return: 'client-error-forbidden', 'client- error-not-authenticated', or 'client-error-not-authorized' as appropriate.
Access Rights: The authenticated user (see section 8.3) performing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the operation and return: 'client-error-forbidden', 'client- error-not-authenticated', or 'client-error-not-authorized' as appropriate.
3.2.7.1 Pause-Printer Request
3.2.7.1 Pause-Printer Request
The following groups of attributes are part of the Pause-Printer Request:
The following groups of attributes are part of the Pause-Printer Request:
Group 1: Operation Attributes
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in section 3.1.4.1.
Target:
The "printer-uri" (uri) operation attribute which is the target
for this operation as described in section 3.1.5.
Target: The "printer-uri" (uri) operation attribute which is the target for this operation as described in section 3.1.5.
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in section 8.3.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in section 8.3.
Hastings, et al. Standards Track [Page 59] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 59] RFC 2911 IPP/1.1: Model and Semantics September 2000
3.2.7.2 Pause-Printer Response
3.2.7.2 Pause-Printer Response
The following groups of attributes are part of the Pause-Printer Response:
The following groups of attributes are part of the Pause-Printer Response:
Group 1: Operation Attributes
Group 1: Operation Attributes
Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text(255)) and/or a "detailed-status-message" (text(MAX))
operation attribute as described in sections 13 and 3.1.6.
Status Message: In addition to the REQUIRED status code returned in every response, the response OPTIONALLY includes a "status-message" (text(255)) and/or a "detailed-status-message" (text(MAX)) operation attribute as described in sections 13 and 3.1.6.
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in section 3.1.4.2.
Group 2: Unsupported Attributes
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
See section 3.1.7 for details on returning Unsupported Attributes.
3.2.8 Resume-Printer Operation
3.2.8 Resume-Printer Operation
This operation allows a client to resume the Printer object scheduling jobs on all its devices. The Printer object MUST remove the 'paused' and 'moving-to-paused' values from the Printer object's "printer-state-reasons" attribute, if present. If there are no other reasons to keep a device paused (such as media-jam), the IPP Printer is free to transition itself to the 'processing' or 'idle' states, depending on whether there are jobs to be processed or not, respectively, and the device(s) resume processing jobs.
This operation allows a client to resume the Printer object scheduling jobs on all its devices. The Printer object MUST remove the 'paused' and 'moving-to-paused' values from the Printer object's "printer-state-reasons" attribute, if present. If there are no other reasons to keep a device paused (such as media-jam), the IPP Printer is free to transition itself to the 'processing' or 'idle' states, depending on whether there are jobs to be processed or not, respectively, and the device(s) resume processing jobs.
If the Pause-Printer operation is supported, then the Resume-Printer operation MUST be supported, and vice-versa.
If the Pause-Printer operation is supported, then the Resume-Printer operation MUST be supported, and vice-versa.
The IPP Printer removes the 'printer-stopped' value from any job's "job-state-reasons" attributes contained in that Printer.
The IPP Printer removes the 'printer-stopped' value from any job's "job-state-reasons" attributes contained in that Printer.
The IPP Printer MUST accept the request in any state, transition the Printer object to the indicated new state as follows:
The IPP Printer MUST accept the request in any state, transition the Printer object to the indicated new state as follows:
Hastings, et al. Standards Track [Page 60] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 60] RFC 2911 IPP/1.1: Model and Semantics September 2000
Current New "printer- IPP Printer's response status code and
"printer- state" action:
state"
Current New "printer- IPP Printer's response status code and "printer- state" action: state"
'idle' 'idle' 'successful-ok' 'processing' 'processing' 'successful-ok'
'idle' 'idle' 'successful-ok' 'processing' 'processing' 'successful-ok'
'stopped' 'processing' 'successful-ok';
when there are jobs to be processed
'stopped' 'idle' 'successful-ok';
when there are no jobs to be processed.
'stopped' 'processing' 'successful-ok'; when there are jobs to be processed 'stopped' 'idle' 'successful-ok'; when there are no jobs to be processed.
Access Rights: The authenticated user (see section 8.3) performing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the operation and return: 'client-error-forbidden', 'client- error-not-authenticated', or 'client-error-not-authorized' as appropriate.
Access Rights: The authenticated user (see section 8.3) performing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the operation and return: 'client-error-forbidden', 'client- error-not-authenticated', or 'client-error-not-authorized' as appropriate.
The Resume-Printer Request and Resume-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see sections 3.2.7.1 and 3.2.7.2).
The Resume-Printer Request and Resume-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see sections 3.2.7.1 and 3.2.7.2).
3.2.9 Purge-Jobs Operation
3.2.9 Purge-Jobs Operation
This OPTIONAL operation allows a client to remove all jobs from an IPP Printer object, regardless of their job states, including jobs in the Printer object's Job History (see Section 4.3.7.2). After a Purge-Jobs operation has been performed, a Printer object MUST return no jobs in subsequent Get-Job-Attributes and Get-Jobs responses (until new jobs are submitted).
This OPTIONAL operation allows a client to remove all jobs from an IPP Printer object, regardless of their job states, including jobs in the Printer object's Job History (see Section 4.3.7.2). After a Purge-Jobs operation has been performed, a Printer object MUST return no jobs in subsequent Get-Job-Attributes and Get-Jobs responses (until new jobs are submitted).
Whether the Purge-Jobs (and Get-Jobs) operation affects jobs that were submitted to the device from other sources than the IPP Printer object in the same way that the Purge-Jobs operation affects jobs that were submitted to the IPP Printer object using IPP, depends on implementation, i.e., on whether the IPP protocol is being used as a universal management protocol or just to manage IPP jobs, respectively.
Whether the Purge-Jobs (and Get-Jobs) operation affects jobs that were submitted to the device from other sources than the IPP Printer object in the same way that the Purge-Jobs operation affects jobs that were submitted to the IPP Printer object using IPP, depends on implementation, i.e., on whether the IPP protocol is being used as a universal management protocol or just to manage IPP jobs, respectively.
Note: if an operator wants to cancel all jobs without clearing out the Job History, the operator uses the Cancel-Job operation on each job instead of using the Purge-Jobs operation.
Note: if an operator wants to cancel all jobs without clearing out the Job History, the operator uses the Cancel-Job operation on each job instead of using the Purge-Jobs operation.
The Printer object MUST accept this operation in any state and transition the Printer object to the 'idle' state.
The Printer object MUST accept this operation in any state and transition the Printer object to the 'idle' state.
Hastings, et al. Standards Track [Page 61] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 61] RFC 2911 IPP/1.1: Model and Semantics September 2000
Access Rights: The authenticated user (see section 8.3) performing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: client-error-forbidden, client- error-not-authenticated, and client-error-not-authorized as appropriate.
Access Rights: The authenticated user (see section 8.3) performing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: client-error-forbidden, client- error-not-authenticated, and client-error-not-authorized as appropriate.
The Purge-Jobs Request and Purge-Jobs Response have the same attribute groups and attributes as the Pause-Printer operation (see sections 3.2.7.1 and 3.2.7.2).
The Purge-Jobs Request and Purge-Jobs Response have the same attribute groups and attributes as the Pause-Printer operation (see sections 3.2.7.1 and 3.2.7.2).
3.3 Job Operations
3.3 Job Operations
All Job operations are directed at Job objects. A client MUST always supply some means of identifying the Job object in order to identify the correct target of the operation. That job identification MAY either be a single Job URI or a combination of a Printer URI with a Job ID. The IPP object implementation MUST support both forms of identification for every job.
All Job operations are directed at Job objects. A client MUST always supply some means of identifying the Job object in order to identify the correct target of the operation. That job identification MAY either be a single Job URI or a combination of a Printer URI with a Job ID. The IPP object implementation MUST support both forms of identification for every job.
3.3.1 Send-Document Operation
3.3.1 Send-Document Operation
This OPTIONAL operation allows a client to create a multi-document Job object that is initially "empty" (contains no documents). In the Create-Job response, the Printer object returns the Job object's URI (the "job-uri" attribute) and the Job object's 32-bit identifier (the "job-id" attribute). For each new document that the client desires to add, the client uses a Send-Document operation. Each Send- Document Request contains the entire stream of document data for one document.
This OPTIONAL operation allows a client to create a multi-document Job object that is initially "empty" (contains no documents). In the Create-Job response, the Printer object returns the Job object's URI (the "job-uri" attribute) and the Job object's 32-bit identifier (the "job-id" attribute). For each new document that the client desires to add, the client uses a Send-Document operation. Each Send- Document Request contains the entire stream of document data for one document.
If the Printer supports this operation but does not support multiple documents per job, the Printer MUST reject subsequent Send-Document operations supplied with data and return the 'server-error-multiple- document-jobs-not-supported'. However, the Printer MUST accept the first document with a 'true' or 'false' value for the "last-document" operation attribute (see below), so that clients MAY always submit one document jobs with a 'false' value for "last-document" in the first Send-Document and a 'true' for "last-document" in the second Send-Document (with no data).
Printerがこの操作をサポートしますが、複数の1仕事あたりのドキュメントを支えないなら、Printerはデータが供給されたその後のSend-ドキュメント操作を拒絶して、'仕事が支えなかったサーバ誤り複数のドキュメント'を返さなければなりません。 しかしながら、Printerは「最後のドキュメント」操作属性のために'本当'の、または、'誤った'値で最初のドキュメントを受け入れなければなりません(以下を見てください)、クライアントが最初のSend-ドキュメントの「最後のドキュメント」と2番目の「最後のドキュメント」のための'本当に'というSend-ドキュメント(データのない)のためにいつも'誤った'値で1つのドキュメント仕事を提出できるように。
Since the Create-Job and the send operations (Send-Document or Send- URI operations) that follow could occur over an arbitrarily long period of time for a particular job, a client MUST send another send operation within an IPP Printer defined minimum time interval after the receipt of the previous request for the job. If a Printer object supports the Create-Job and Send-Document operations, the Printer object MUST support the "multiple-operation-time-out" attribute (see
操作(ドキュメントを発信させるか、Send URI操作)を送ってください。そして、Create-仕事、尾行が特定の仕事のための時間の任意に長い期間にわたって起こることができて、クライアントが別のものを送らなければならないのが仕事を求める前の要求の領収書の後の間隔に最小の時間定義されたIPP Printerの中で操作を送ります。 Printerオブジェクトが、Create-仕事とSend-ドキュメントが操作であるとサポートするなら、Printerオブジェクトが「複数の操作タイムアウト」属性をサポートしなければならない、(見る。
Hastings, et al. Standards Track [Page 62] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[62ページ]: モデルと意味論2000年9月
section 4.4.31). This attribute indicates the minimum number of seconds the Printer object will wait for the next send operation before taking some recovery action.
セクション4.4.31)。 この属性は、何らかの回復行動を取る前に待っているPrinterが次を反対させる秒の最小の数が操作を送るのを示します。
An IPP object MUST recover from an errant client that does not supply a send operation, sometime after the minimum time interval specified by the Printer object's "multiple-operation-time-out" attribute. Such recovery MAY include any of the following or other recovery actions:
IPPオブジェクトはaが操作を送る供給ではなく、それがする誤ったクライアントから回収されなければなりません、最小の時間間隔がPrinterオブジェクトの「複数の操作タイムアウト」属性で指定したいつか後に。 そのような回復は以下か他の回復動作のどれかを含むかもしれません:
1. Assume that the Job is an invalid job, start the process of
changing the job state to 'aborted', add the 'aborted-by-
system' value to the job's "job-state-reasons" attribute (see
section 4.3.8), and clean up all resources associated with the
Job. In this case, if another send operation is finally
received, the Printer responds with an "client-error-not-
possible" or "client-error-not-found" depending on whether or
not the Job object is still around when the send operation
finally arrives.
2. Assume that the last send operation received was in fact the
last document (as if the "last-document" flag had been set to
'true'), close the Job object, and proceed to process it (i.e.,
move the Job's state to 'pending').
3. Assume that the last send operation received was in fact the
last document, close the Job, but move it to the 'pending-held'
and add the 'submission-interrupted' value to the job's "job-
state-reasons" attribute (see section 4.3.8). This action
allows the user or an operator to determine whether to continue
processing the Job by moving it back to the 'pending' state
using the Release-Job operation (see section 3.3.6) or to
cancel the job using the Cancel-Job operation (see section
3.3.3).
1. Jobが無効の仕事であると仮定してください、そして、'中止になっ'て、仕事の「仕事の州の理由」属性(セクション4.3.8を見る)に'中止になっているシステム'の価値を高めて、Jobに関連しているすべてのリソースをきれいにするために仕事の状態を変えるプロセスを始めてください。 操作を送ってください。別のものが発信するならこの場合最終的に操作を受けて、Printerが「クライアント誤り可能でない」かいつの周りでJobオブジェクトがスチール写真であるかどうかによる「誤りが当たらなかったクライアント」と共に応じる、最終的に、到着します。 2. 事実上、最終が受けられた操作を送るのが、最後のドキュメント(まるで「最後のドキュメント」旗が'本当に'設定されたかのように)であり、Jobが近くでは、反対して、それを処理しかける(すなわち、Jobの状態を'未定に'動かす)と仮定してください。 3. 事実上、最終が受けられた操作を送るのが、最後のドキュメントでしたが、Jobを閉じますが、それを'未定に保持'に動かすように仮定してください、そして、仕事の「仕事の州理由」属性に'服従で中断している'価値を高めてください(セクション4.3.8を見てください)。 この動作で、ユーザかオペレータが、'未定'の状態にそれをRelease-仕事の操作(セクション3.3.6を見る)を使用することで戻らせることによってJobを処理し続けているかどうかと決心しているか、またはキャンセル仕事の操作を使用することで仕事を中止します(セクション3.3.3を見てください)。
Each implementation is free to decide the "best" action to take depending on local policy, whether any documents have been added, whether the implementation spools jobs or not, and/or any other piece of information available to it. If the choice is to abort the Job object, it is possible that the Job object may already have been processed to the point that some media sheet pages have been printed.
各実装は、それに利用可能な情報のローカルの方針、実装が仕事をスプールするか否かに関係なく、何かドキュメントが加えられるか、そして、そして/または、いかなる他の断片にもよって、取るために自由に「最も良い」動作について決めることができます。 選択がJobオブジェクトを中止することであるなら、Jobオブジェクトが既にいくつかのメディアシートページが印刷されたというポイントに処理されたのは、可能です。
Access Rights: The authenticated user (see section 8.3) performing this operation must either be the job owner (as determined in the Create-Job operation) or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client- error-not-authenticated', or 'client-error-not-authorized' as appropriate.
アクセス権: この操作を実行している認証されたユーザ(セクション8.3を見る)は、Printerオブジェクトの仕事の所有者(Create-仕事の操作で決定するように)、オペレータまたは管理者のどちらかであるに違いありません(セクション1と8.5を見てください)。 さもなければ、IPPオブジェクトは、操作を拒絶して、戻らなければなりません: '禁じられたクライアント誤り'、'認証されなかったクライアント誤り'、または'誤りが権限を与えなかったクライアント'、適宜。
Hastings, et al. Standards Track [Page 63] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[63ページ]: モデルと意味論2000年9月
3.3.1.1 Send-Document Request
3.3.1.1 資料請求を発信させます。
The following attribute sets are part of the Send-Document Request:
以下の属性セットはSend-ドキュメントRequestの一部です:
Group 1: Operation Attributes
グループ1: 操作属性
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
自然言語と文字コード: セクション3.1.4で.1に説明される「属性-charset」と「属性自然言語」属性
Target:
Either (1) the "printer-uri" (uri) plus "job-id"
(integer(1:MAX))or (2) the "job-uri" (uri) operation
attribute(s) which define the target for this operation as
described in section 3.1.5.
以下を狙ってください。 (1) 「プリンタ-uri」(uri)と「仕事イド」(整数(1: MAX))か(2) セクション3.1.5で説明されるこの操作のための目標を定義する「仕事-uri」(uri)操作属性のどちらか。
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in section 8.3.
ユーザ名を要求します: 「要求しているユーザ名」(名前(MAX))はSHOULDを結果と考えます。説明されるとしてセクション8.3でクライアントによって供給されてください。
"document-name" (name(MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It contains the client
supplied document name. The document name MAY be different than
the Job name. It might be helpful, but NEED NOT be unique
across multiple documents in the same Job. Typically, the
client software automatically supplies the document name on
behalf of the end user by using a file name or an application
generated name. See the description of the "document-name"
operation attribute in the Print-Job Request (section 3.2.1.1)
for more information about this attribute.
「ドキュメント名」(名前(最大)): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それはクライアントの供給されたドキュメント名を含んでいます。 ドキュメント名はJob名と異なっているかもしれません。 それは、役立つかもしれませんが、同じJobの複数のドキュメントの向こう側にユニークである必要はありません。 通常、クライアントソフトウェアは、エンドユーザを代表してファイル名か名前であることが作られたアプリケーションを使用することによって、ドキュメント名前を自動的に提供します。 Print-仕事のRequestにおける、「ドキュメント名」操作属性の記述を見てください、(セクション3.2 .1 .1) この属性に関する詳しい情報のために。
"compression" (type3 keyword):
See the description of "compression" for the Print-Job operation
in Section 3.2.1.1.
「圧縮」(type3キーワード): .1にセクション3.2.1におけるPrint-仕事の操作のための「圧縮」の記述を見てください。
"document-format" (mimeMediaType):
See the description of "document-format" for the Print-Job
operation in Section 3.2.1.1.
「ドキュメント・フォーマット」(mimeMediaType): セクション3.2.1におけるPrint-仕事の操作のための「ドキュメント・フォーマット」.1の記述を見てください。
"document-natural-language" (naturalLanguage):
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute. This attribute
specifies the natural language of the document for those
document-formats that require a specification of the natural
language in order to image the document unambiguously. There
are no particular values required for the Printer object to
support.
「ドキュメント自然言語」(naturalLanguage): クライアントOPTIONALLYはこの属性を供給します。 PrinterオブジェクトOPTIONALLYはこの属性をサポートします。 この属性は明白にドキュメントに像を描くために自然言語の仕様を必要とするそれらのドキュメント・フォーマットのためのドキュメントの自然言語を指定します。 支えるPrinterオブジェクトに必要であるどんな特定の値もありません。
Hastings, et al. Standards Track [Page 64] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[64ページ]: モデルと意味論2000年9月
"last-document" (boolean):
The client MUST supply this attribute. The Printer object MUST
support this attribute. It is a boolean flag that is set to
'true' if this is the last document for the Job, 'false'
otherwise.
「最後のドキュメント」(論理演算子): クライアントはこの属性を供給しなければなりません。 Printerオブジェクトはこの属性をサポートしなければなりません。 それはこれがJobのための最後のドキュメントであるなら'本当に'設定される論理演算子旗です、そうでなければ、'誤っています'。
Group 2: Document Content
グループ2: ドキュメント内容
The client MUST supply the document data if the "last-document"
flag is set to 'false'. However, since a client might not know
that the previous document sent with a Send-Document (or Send-URI)
operation was the last document (i.e., the "last-document"
attribute was set to 'false'), it is legal to send a Send-Document
request with no document data where the "last-document" flag is
set to 'true'. Such a request MUST NOT increment the value of the
Job object's "number-of-documents" attribute, since no real
document was added to the job. It is not an error for a client to
submit a job with no actual document data, i.e., only a single
Create-Job and Send-Document request with a "last-document"
operation attribute set to 'true' with no document data.
「最後のドキュメント」旗が'誤っていること'に設定されるなら、クライアントはドキュメントデータを提供しなければなりません。 しかしながら、クライアントが、Send-ドキュメント(または、Send-URI)操作と共に送られた前のドキュメントが最後のドキュメントであったのを知らないかもしれないので(すなわち、「最後のドキュメント」属性は'誤っていること'に設定されました)、'本当に'「最後のドキュメント」旗が設定されるドキュメントデータのないSend-資料請求を送るのは法的です。 そのような要求はJobオブジェクトの「ドキュメントの数」属性の値を増加してはいけません、どんな本当のドキュメントも仕事に加えられなかったので。 それは、'本当に'ドキュメントデータなしで設定された「最後のドキュメント」操作属性があるクライアントが実際のドキュメントデータのない仕事、すなわち、ただ一つのCreate-仕事だけを提出する誤りとまたはSend-資料請求ではありません。
3.3.1.2 Send-Document Response
3.3.1.2 ドキュメントを発信させている応答
The following sets of attributes are part of the Send-Document Response:
以下のセットの属性はSend-ドキュメントResponseの一部です:
Group 1: Operation Attributes
グループ1: 操作属性
Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text(255)) and/or a "detailed-status-message" (text(MAX))
operation attribute as described in sections 13 and 3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて応答OPTIONALLYは「ステータスメッセージ」を含んでいます。(テキスト(255))、そして/または、セクション13と3.1.6で説明される「詳細なステータスメッセージ」(テキスト(MAX))操作属性。
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
自然言語と文字コード: セクション3.1.4で.2に説明される「属性-charset」と「属性自然言語」属性
Group 2: Unsupported Attributes
グループ2: サポートされない属性
See section 3.1.7 for details on returning Unsupported Attributes.
戻っているUnsupported Attributesに関する詳細に関してセクション3.1.7を見てください。
Group 3: Job Object Attributes
グループ3: 仕事のオブジェクト属性
This is the same set of attributes as described in the Print-Job
response (see section 3.2.1.2).
セクション3.2を見てください。これがPrint-仕事の応答で説明されるように同じセットの属性である、(.1 .2)。
Hastings, et al. Standards Track [Page 65] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[65ページ]: モデルと意味論2000年9月
3.3.2 Send-URI Operation
3.3.2 URIを発信させている操作
This OPTIONAL operation is identical to the Send-Document operation
(see section 3.3.1) except that a client MUST supply a URI reference
("document-uri" operation attribute) rather than the document data
itself. If a Printer object supports this operation, clients can use
both Send-URI or Send-Document operations to add new documents to an
existing multi-document Job object. However, if a client needs to
indicate that the previous Send-URI or Send-Document was the last
document, the client MUST use the Send-Document operation with no
document data and the "last-document" flag set to 'true' (rather than
using a Send-URI operation with no "document-uri" operation
attribute).
クライアントがドキュメントデータ自体よりむしろURI参照(「ドキュメント-uri」操作属性)を提供しなければならないのを除いて、このOPTIONAL操作はSend-ドキュメント操作(セクション3.3.1を見る)と同じです。 Printerオブジェクトがこの操作をサポートするなら、クライアントは、既存のマルチドキュメントJobオブジェクトに新しいドキュメントを加えるのに両方のSend-URIかSend-ドキュメント操作を使用できます。 しかしながら、クライアントが、前のSend-URIかSend-ドキュメントが最後のドキュメントであったのを示す必要があるなら、クライアントはドキュメントデータなしでSend-ドキュメント操作を使用しなければなりません、そして、「最後のドキュメント」旗は'本当(「ドキュメント-uri」操作属性なしでSend-URI操作を使用するよりむしろ)に'セットしました。
If a Printer object supports this operation, it MUST also support the Print-URI operation (see section 3.2.2).
また、Printerオブジェクトがこの操作をサポートするなら、それは、Print-URIが操作であるとサポートしなければなりません(セクション3.2.2を見てください)。
The Printer object MUST validate the syntax and URI scheme of the supplied URI before returning a response, just as in the Print-URI operation. The IPP Printer MAY validate the accessibility of the document as part of the operation or subsequently (see section 3.2.2).
応答を返す前にPrinterオブジェクトは供給されたURIの構文とURI体系を有効にしなければなりません、ちょうどPrint-URI操作のように。 IPP Printerは次に、操作の一部としてドキュメントのアクセシビリティを有効にするかもしれません(セクション3.2.2を見てください)。
3.3.3 Cancel-Job Operation
3.3.3 キャンセル仕事の操作
This REQUIRED operation allows a client to cancel a Print Job from the time the job is created up to the time it is completed, canceled, or aborted. Since a Job might already be printing by the time a Cancel-Job is received, some media sheet pages might be printed before the job is actually terminated.
このREQUIRED操作で、クライアントはPrint Jobを雇用が創り出される時からそれが完成されるか、取り消されるか、または中止される時まで取り消すことができます。 キャンセル仕事が受け取られている時までにJobが既に印刷しているかもしれないので、仕事が実際に終えられる前に、いくつかのメディアシートページが印刷されるかもしれません。
The IPP object MUST accept or reject the request based on the job's current state and transition the job to the indicated new state as follows:
IPPオブジェクトは、仕事の現状に基づいて要求を受け入れなければならないか、または拒絶しなければなりません、そして、変遷は以下の示された新しい状態への仕事を拒絶します:
Hastings, et al. Standards Track [Page 66] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[66ページ]: モデルと意味論2000年9月
Current "job- New "job- IPP object's response status
state" state" code and action:
現在の「仕事の新しい「仕事のIPPオブジェクトの応答状態状態」状態」コードと動き:
'pending' 'canceled' 'successful-ok'
'pending-held' 'canceled' 'successful-ok'
'processing' 'canceled' 'successful-ok'
'processing' 'processing' 'successful-ok' See Rule 1
'processing' 'processing' 'client-error-not-possible'
See Rule 2
'processing- 'canceled' 'successful-ok'
stopped'
'processing- 'processing- 'successful-ok' See Rule 1
stopped' stopped'
'processing- 'processing- 'client-error-not-possible'
stopped' stopped' See Rule 2
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'
'pending' 'canceled' 'successful-ok' 'pending-held' 'canceled' 'successful-ok' 'processing' 'canceled' 'successful-ok' 'processing' 'processing' 'successful-ok' See Rule 1 'processing' 'processing' 'client-error-not-possible' See Rule 2 'processing- 'canceled' 'successful-ok' stopped' 'processing- 'processing- 'successful-ok' See Rule 1 stopped' stopped' 'processing- 'processing- 'client-error-not-possible' stopped' stopped' See Rule 2 'completed' 'completed' 'client-error-not-possible' 'canceled' 'canceled' 'client-error-not-possible' 'aborted' 'aborted' 'client-error-not-possible'
Rule 1: If the implementation requires some measurable time to cancel the job in the 'processing' or 'processing-stopped' job states, the IPP object MUST add the 'processing-to-stop-point' value to the job's "job-state-reasons" attribute and then transition the job to the 'canceled' state when the processing ceases (see section 4.3.8).
規則1: 実装が'処理'か'処理で止まっている'仕事の州で仕事を中止するいくらかの測定できる時間を必要とするなら、処理がやむと(セクション4.3.8を見てください)、IPPオブジェクトは仕事への'ポイントを止めるには処理する'値が「仕事の状態は推論する」という属性であり、次に、変遷が'取り消された'状態への仕事であると言い足さなければなりません。
Rule 2: If the Job object already has the 'processing-to-stop-point' value in its "job-state-reasons" attribute, then the Printer object MUST reject a Cancel-Job operation.
規則2: Jobオブジェクトに「仕事の州の理由」属性における'ポイントを止めるために処理する'値が既にあるなら、Printerオブジェクトはキャンセル仕事の操作を拒絶しなければなりません。
Access Rights: The authenticated user (see section 8.3) performing
this operation must either be the job owner or an operator or
administrator of the Printer object (see Sections 1 and 8.5).
Otherwise, the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated', or
'client-error-not-authorized' as appropriate.
アクセス権: この操作を実行している認証されたユーザ(セクション8.3を見る)は、Printerオブジェクトの仕事の所有者、オペレータまたは管理者のどちらかであるに違いありません(セクション1と8.5を見てください)。 さもなければ、IPPオブジェクトは、操作を拒絶して、戻らなければなりません: '禁じられたクライアント誤り'、'誤りが認証しなかったクライアント'、または'誤りが権限を与えなかったクライアント'、適宜。
3.3.3.1 Cancel-Job Request
3.3.3.1 キャンセル仕事の要求
The following groups of attributes are part of the Cancel-Job Request:
属性の以下のグループはキャンセル仕事のRequestの一部です:
Group 1: Operation Attributes
グループ1: 操作属性
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
自然言語と文字コード: セクション3.1.4で.1に説明される「属性-charset」と「属性自然言語」属性
Hastings, et al. Standards Track [Page 67] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[67ページ]: モデルと意味論2000年9月
Target:
Either (1) the "printer-uri" (uri) plus "job-id"
(integer(1:MAX))or (2) the "job-uri" (uri) operation
attribute(s) which define the target for this operation as
described in section 3.1.5.
以下を狙ってください。 (1) 「プリンタ-uri」(uri)と「仕事イド」(整数(1: MAX))か(2) セクション3.1.5で説明されるこの操作のための目標を定義する「仕事-uri」(uri)操作属性のどちらか。
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in section 8.3.
ユーザ名を要求します: 「要求しているユーザ名」(名前(MAX))はSHOULDを結果と考えます。説明されるとしてセクション8.3でクライアントによって供給されてください。
"message" (text(127)):
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute. It is a message to
the operator. This "message" attribute is not the same as the
"job-message-from-operator" attribute. That attribute is used
to report a message from the operator to the end user that
queries that attribute. This "message" operation attribute is
used to send a message from the client to the operator along
with the operation request. It is an implementation decision
of how or where to display this message to the operator (if at
all).
「メッセージ、」 (テキスト(127)): クライアントOPTIONALLYはこの属性を供給します。 PrinterオブジェクトOPTIONALLYはこの属性をサポートします。 それはオペレータへのメッセージです。 この「メッセージ」属性は「オペレータからの仕事のメッセージ」属性と同じではありません。 その属性は、オペレータからその属性について質問するエンドユーザにメッセージを報告するのに使用されます。 この「メッセージ」操作属性は、操作要求と共にクライアントからオペレータにメッセージを送るのに使用されます。 それはどのようにかどこにオペレータ(せいぜい)にこのメッセージを表示するかに関する実装決定です。
3.3.3.2 Cancel-Job Response
3.3.3.2 キャンセル仕事の応答
The following sets of attributes are part of the Cancel-Job Response:
以下のセットの属性はキャンセル仕事のResponseの一部です:
Group 1: Operation Attributes
グループ1: 操作属性
Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text(255)) and/or a "detailed-status-message" (text(MAX))
operation attribute as described in sections 13 and 3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて応答OPTIONALLYは「ステータスメッセージ」を含んでいます。(テキスト(255))、そして/または、セクション13と3.1.6で説明される「詳細なステータスメッセージ」(テキスト(MAX))操作属性。
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
自然言語と文字コード: セクション3.1.4で.2に説明される「属性-charset」と「属性自然言語」属性
Group 2: Unsupported Attributes
グループ2: サポートされない属性
See section 3.1.7 for details on returning Unsupported Attributes.
戻っているUnsupported Attributesに関する詳細に関してセクション3.1.7を見てください。
Once a successful response has been sent, the implementation guarantees that the Job will eventually end up in the 'canceled' state. Between the time of the Cancel-Job operation is accepted and when the job enters the 'canceled' job-state (see section 4.3.7), the "job-state-reasons" attribute SHOULD contain the 'processing-to- stop-point'
いったんうまくいっている応答を送ると、実装は、Jobが結局'取り消された'状態で終わるのを保証します。 間に、キャンセル仕事の操作の時間を受け入れて、仕事が'取り消された'仕事状態に入るとき(セクション4.3.7を見てください)「仕事の州の理由」属性SHOULDが'処理を含んでいる、-、-停止して指してください、'
Hastings, et al. Standards Track [Page 68] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[68ページ]: モデルと意味論2000年9月
value which indicates to later queries that although the Job might still be 'processing', it will eventually end up in the 'canceled' state, not the 'completed' state.
Jobがまだ'処理'であるかもしれませんが、後の質問にそれを示す値、それは結局、'完成した'状態ではなく、'取り消された'状態で終わるでしょう。
3.3.4 Get-Job-Attributes Operation
3.3.4 仕事の属性を得ている操作
This REQUIRED operation allows a client to request the values of attributes of a Job object and it is almost identical to the Get- Printer-Attributes operation (see section 3.2.5). The only differences are that the operation is directed at a Job object rather than a Printer object, there is no "document-format" operation attribute used when querying a Job object, and the returned attribute group is a set of Job object attributes rather than a set of Printer object attributes.
クライアントはこのREQUIRED操作からJobオブジェクトの属性の値を要求できます、そして、それはGetプリンタ属性操作とほとんど同じです(セクション3.2.5を見てください)。 唯一の違いはPrinterオブジェクトよりむしろJobオブジェクトが操作に向けられるということです、そして、Jobオブジェクトについて質問するとき使用される「ドキュメント・フォーマット」操作属性が全くありません、そして、返された属性グループは1セットのPrinterオブジェクト属性よりむしろ1セットのJobオブジェクト属性です。
For Jobs, the possible names of attribute groups are:
ジョブスにとって、属性グループの可能な名前は以下の通りです。
- 'job-template': the subset of the Job Template attributes that
apply to a Job object (the first column of the table in Section
4.2) that the implementation supports for Job objects.
- 'job-description': the subset of the Job Description attributes
specified in Section 4.3 that the implementation supports for
Job objects.
- 'all': the special group 'all' that includes all attributes that
the implementation supports for Job objects.
- '仕事テンプレート': 実装がJobオブジェクトのために支えるJobオブジェクト(セクション4.2における、テーブルの最初のコラム)に適用されるJob Template属性の部分集合。 - '職務記述書': Job記述属性の部分集合は、セクション4.3で実装がJobのためにオブジェクトを支えると指定しました。 - 'すべて': 実装がJobオブジェクトのためにサポートするすべての属性を含んでいる特別なグループ'すべて'。
Since a client MAY request specific attributes or named groups, there is a potential that there is some overlap. For example, if a client requests, 'job-name' and 'job-description', the client is actually requesting the "job-name" attribute once by naming it explicitly, and once by inclusion in the 'job-description' group. In such cases, the Printer object NEED NOT return the attribute only once in the response even if it is requested multiple times. The client SHOULD NOT request the same attribute in multiple ways.
特定の属性であり、グループと命名されて、ある可能性があるというクライアント5月の要求以来、或るものは重なります。 例えば、クライアントが、'ジョブ名'と'職務記述書'よう要求するなら、クライアントは実際に「ジョブ名」属性を明らかに、そして、'職務記述書'グループでの包含による一度それを命名するのによる一度要求しています。 そのような場合、それが複数の回要求されても、Printerオブジェクトは応答で属性を一度だけ返す必要はありません。 クライアントSHOULD NOTは複数の方法で同じ属性を要求します。
It is NOT REQUIRED that a Job object support all attributes belonging to a group (since some attributes are OPTIONAL). However it is REQUIRED that each Job object support all these group names.
それはJobがグループに属すすべての属性をサポートするのを反対させるNOT REQUIRED(いくつかの属性がOPTIONALであるので)です。 しかしながら、それは各Jobがこれらのすべてのグループ名をサポートするのを反対させるREQUIREDです。
3.3.4.1 Get-Job-Attributes Request
3.3.4.1 仕事の属性を得ている要求
The following groups of attributes are part of the Get-Job-Attributes Request when the request is directed at a Job object:
Jobオブジェクトが要求に向けられるとき、属性の以下のグループはGet仕事の属性Requestの一部です:
Hastings, et al. Standards Track [Page 69] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[69ページ]: モデルと意味論2000年9月
Group 1: Operation Attributes
グループ1: 操作属性
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
自然言語と文字コード: セクション3.1.4で.1に説明される「属性-charset」と「属性自然言語」属性
Target:
Either (1) the "printer-uri" (uri) plus "job-id"
(integer(1:MAX)) or (2) the "job-uri" (uri) operation
attribute(s) which define the target for this operation as
described in section 3.1.5.
以下を狙ってください。 (1) 「プリンタ-uri」(uri)と「仕事イド」(整数(1: MAX))か(2) セクション3.1.5で説明されるこの操作のための目標を定義する「仕事-uri」(uri)操作属性のどちらか。
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in section 8.3.
ユーザ名を要求します: 「要求しているユーザ名」(名前(MAX))はSHOULDを結果と考えます。説明されるとしてセクション8.3でクライアントによって供給されてください。
"requested-attributes" (1setOf keyword):
The client OPTIONALLY supplies this attribute. The IPP object
MUST support this attribute. It is a set of attribute names
and/or attribute group names in whose values the requester is
interested. If the client omits this attribute, the IPP object
MUST respond as if this attribute had been supplied with a value
of 'all'.
「要求された属性」(1setOfキーワード): クライアントOPTIONALLYはこの属性を供給します。 IPPオブジェクトはこの属性をサポートしなければなりません。 それは、リクエスタが値に興味を持っている1セットの属性名、そして/または、属性グループ名です。 クライアントがこの属性を省略するなら、IPPオブジェクトはまるで'すべて'の値をこの属性に供給したかのように応じなければなりません。
3.3.4.2 Get-Job-Attributes Response
3.3.4.2 仕事の属性を得ている応答
The Printer object returns the following sets of attributes as part of the Get-Job-Attributes Response:
PrinterオブジェクトはGet仕事の属性Responseの一部として以下のセットの属性を返します:
Group 1: Operation Attributes
グループ1: 操作属性
Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text(255)) and/or a "detailed-status-message" (text(MAX))
operation attribute as described in sections 13 and 3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて応答OPTIONALLYは「ステータスメッセージ」を含んでいます。(テキスト(255))、そして/または、セクション13と3.1.6で説明される「詳細なステータスメッセージ」(テキスト(MAX))操作属性。
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2. The "attributes-
natural-language" MAY be the natural language of the Job
object, rather than the one requested.
自然言語と文字コード: セクション3.1.4で.2に説明される「属性-charset」と「属性自然言語」属性 「属性自然言語」は要求されたものよりむしろJobオブジェクトの自然言語であるかもしれません。
Group 2: Unsupported Attributes
グループ2: サポートされない属性
See section 3.1.7 for details on returning Unsupported Attributes.
戻っているUnsupported Attributesに関する詳細に関してセクション3.1.7を見てください。
Hastings, et al. Standards Track [Page 70] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[70ページ]: モデルと意味論2000年9月
The response NEED NOT contain the "requested-attributes" operation
attribute with any supplied values (attribute keywords) that were
requested by the client but are not supported by the IPP object.
If the Printer object does return unsupported attributes
referenced in the "requested-attributes" operation attribute and
that attribute included group names, such as 'all', the
unsupported attributes MUST NOT include attributes described in
the standard but not supported by the implementation.
応答はクライアントによって要求されましたが、IPPオブジェクトによってサポートされない少しの供給値(属性キーワード)がある「要求された属性」操作属性も含む必要はありません。 Printerオブジェクトが戻るなら、サポートされない属性は「要求された属性」操作属性とその属性を含む際にグループ名に参照をつけました、'すべて'などのようにサポートされない属性は規格で説明されますが、実装によってサポートされなかった属性を含んではいけません。
Group 3: Job Object Attributes
グループ3: 仕事のオブジェクト属性
This is the set of requested attributes and their current values.
The IPP object ignores (does not respond with) any requested
attribute or value which is not supported or which is restricted
by the security policy in force, including whether the requesting
user is the user that submitted the job (job originating user) or
not (see section 8). However, the IPP object MUST respond with
the 'unknown' value for any supported attribute (including all
REQUIRED attributes) for which the IPP object does not know the
value, unless it would violate the security policy. See the
description of the "out-of-band" values in the beginning of
Section 4.1.
これは要求された属性とそれらの現行価値のセットです。 IPPオブジェクトが無視する、(応じない、)、いずれもサポートされないか、または安全保障政策によって大挙して制限される属性か値を要求しました、要求しているユーザが仕事(賃仕事の起因しているユーザ)を提出したユーザであるかどうかを含んでいて(セクション8を見てください)。 しかしながら、IPPオブジェクトはIPP目的が値を知らないどんなサポートしている属性(すべてのREQUIRED属性を含んでいる)のためにも'未知'の値で応じなければなりません、安全保障政策に違反しないなら。 初めに「バンドの外」というセクション4.1の値の記述を見てください。
3.3.5 Hold-Job Operation
3.3.5 保持仕事の操作
This OPTIONAL operation allows a client to hold a pending job in the queue so that it is not eligible for scheduling. If the Hold-Job operation is supported, then the Release-Job operation MUST be supported, and vice-versa. The OPTIONAL "job-hold-until" operation attribute allows a client to specify whether to hold the job indefinitely or until a specified time period, if supported.
クライアントがこのOPTIONAL操作で待ち行列における未定の仕事を持つことができるので、スケジューリングには、それは適任ではありません。 Hold-仕事の操作がサポートされるなら、Release-仕事の操作をサポートしなければなりません、そして、逆もまた同様です。 OPTIONAL、「仕事の保持、」 クライアントは、操作属性で無期限か指定された期間まで仕事を持っているかどうか指定できます、サポートされるなら。
The IPP object MUST accept or reject the request based on the job's current state and transition the job to the indicated new state as follows:
IPPオブジェクトは、仕事の現状に基づいて要求を受け入れなければならないか、または拒絶しなければなりません、そして、変遷は以下の示された新しい状態への仕事を拒絶します:
Hastings, et al. Standards Track [Page 71] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[71ページ]: モデルと意味論2000年9月
Current "job- New "job-state" IPP object's response status
state" code and action:
現在の「「という」 IPPオブジェクトのものを仕事して述べてください仕事の新しい応答状態状態」コードと動き:
'pending' 'pending-held' 'successful-ok' See Rule 1
'pending' 'pending' 'successful-ok' See Rule 2
'pending-held' 'pending-held' 'successful-ok' See Rule 1
'pending-held' 'pending' 'successful-ok' See Rule 2
'processing' 'processing' 'client-error-not-possible'
'processing- 'processing- 'client-error-not-possible'
stopped' stopped'
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'
'pending' 'pending-held' 'successful-ok' See Rule 1 'pending' 'pending' 'successful-ok' See Rule 2 'pending-held' 'pending-held' 'successful-ok' See Rule 1 'pending-held' 'pending' 'successful-ok' See Rule 2 'processing' 'processing' 'client-error-not-possible' 'processing- 'processing- 'client-error-not-possible' stopped' stopped' 'completed' 'completed' 'client-error-not-possible' 'canceled' 'canceled' 'client-error-not-possible' 'aborted' 'aborted' 'client-error-not-possible'
Rule 1: If the implementation supports multiple reasons for a job to be in the 'pending-held' state, the IPP object MUST add the 'job- hold-until-specified' value to the job's "job-state-reasons" attribute.
規則1: 実装が、複数の理由には仕事が'未定に保持された'状態にあるとサポートするなら、IPPオブジェクトは仕事の「仕事の州の理由」属性に'指定されるまでの仕事の保持'価値を高めなければなりません。
Rule 2: If the IPP object supports the "job-hold-until" operation attribute, but the specified time period has already started (or is the 'no-hold' value) and there are no other reasons to hold the job, the IPP object MUST make the job be a candidate for processing immediately (see Section 4.2.2) by putting the job in the 'pending' state.
規則2: IPPオブジェクトサポートである、「仕事の保持、」 操作属性、指定された期間だけが既に始まって('保持がありません'は値です)、仕事を持つ他の理由が全くなくて、IPPオブジェクトは、すぐに(セクション4.2.2を見る)'未定'の状態に仕事を置くことによって仕事が処理の候補であることを作らなければなりません。
Note: In order to keep the Hold-Job operation simple, such a request is rejected when the job is in the 'processing' or 'processing- stopped' states. If an operation is needed to hold jobs while in these states, it will be added as an additional operation, rather than overloading the Hold-Job operation. Then it is clear to clients by querying the Printer object's "operations-supported" (see Section 4.4.15) and the Job object's "job-state" (see Section 4.3.7) attributes which operations are possible.
以下に注意してください。 ''処理'に仕事があるとき、Hold-仕事の操作を簡単に保つために、そのような要求が拒絶されたか、または処理は'州を止めました。 これらの州では、それがHold-仕事の操作を積みすぎるより兼業としてむしろ加えられますが、操作が仕事を持つのに必要であるなら。 その時、クライアントにとって、どの操作が可能であるかは、「操作でサポートしている」(セクション4.4.15を見ます)Printerが、反対する質問とJobオブジェクトの「仕事状態」(セクション4.3.7を見る)属性で明確です。
Access Rights: The authenticated user (see section 8.3) performing this operation must either be the job owner or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate.
アクセス権: この操作を実行している認証されたユーザ(セクション8.3を見る)は、Printerオブジェクトの仕事の所有者、オペレータまたは管理者のどちらかであるに違いありません(セクション1と8.5を見てください)。 さもなければ、IPPオブジェクトは、操作を拒絶して、戻らなければなりません: '禁じられたクライアント誤り'、'誤りが認証しなかったクライアント'、または'誤りが権限を与えなかったクライアント'、適宜。
3.3.5.1 Hold-Job Request
3.3.5.1 保持仕事の要求
The groups and operation attributes are the same as for a Cancel-Job request (see section 3.3.3.1), with the addition of the following Group 1 Operation attribute:
グループと操作属性がキャンセル仕事の要求のように同じである、(.1は、)以下のGroup1Operation属性の追加で3.3に.3を区分するのを見ます:
Hastings, et al. Standards Track [Page 72] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[72ページ]: モデルと意味論2000年9月
"job-hold-until" (type3 keyword | name(MAX)):
The client OPTIONALLY supplies this Operation attribute. The
IPP object MUST support this operation attribute in a Hold-Job
request, if it supports the "job-hold-until" Job template
attribute in create operations. See section 4.2.2. The IPP
object SHOULD support the "job-hold-until" Job Template
attribute for use in job create operations with at least the
'indefinite' value, if it supports the Hold-Job operation.
Otherwise, a client cannot create a job and hold it immediately
(without picking some supported time period in the future).
「仕事の保持、」 (type3キーワード| 名前(MAX)): クライアントOPTIONALLYはこのOperation属性を供給します。 IPPオブジェクトはHold-仕事の要求でこの操作属性をサポートしなければなりません、それであるならサポート、「仕事の保持、」 Jobテンプレート属性が操作を中に作成します。 セクション4.2.2を見てください。 IPPオブジェクトSHOULDがサポートする、「仕事の保持、」 仕事における使用のためのJob Template属性は少なくとも'無期'の値で操作を作成します、Hold賃仕事の操作をサポートするなら。 さもなければ、クライアントは、すぐに(将来いくつかのサポートしている期間を選ばないで)、雇用を創り出して、それを開催できません。
If supplied and supported as specified in the Printer's "job-
hold-until-supported" attribute, the IPP object copies the
supplied operation attribute to the Job object, replacing the
job's previous "job-hold-until" attribute, if present, and
makes the job a candidate for scheduling during the supplied
named time period.
Printerの「サポートされるまでの仕事の保持」属性で指定されるように供給されて、サポートされるなら、IPPオブジェクトは供給された操作属性をJobオブジェクトにコピーします、前であることの状態で仕事のものを取り替えて「仕事の保持、」 供給された名前付の期間、スケジューリングの仕事のa候補を存在しているなら結果と考えて、作ります。
If supplied, but either the "job-hold-until" Operation
attribute itself or the value supplied is not supported, the
IPP object accepts the request, returns the unsupported
attribute or value in the Unsupported Attributes Group
according to section 3.1.7, returns the 'successful-ok-
ignored-or-substituted-attributes, and holds the job
indefinitely until a client performs a subsequent Release-Job
operation.
しかし、供給する、「仕事の保持、」 それ自体か値が供給したOperation属性がサポートされないで、IPPオブジェクトが要請を受け入れて、セクション3.1.7に応じてUnsupported Attributes Groupでサポートされない属性か値を返して、'うまくいって間違いない無視されたか代入された属性を返して、クライアントがその後のRelease-仕事の操作を実行するまで仕事を無期限に持っている、'
If the client (1) supplies a value that specifies a time period
that has already started or the 'no-hold' value (meaning don't
hold the job) and (2) the IPP object supports the "job-hold-
until" operation attribute and there are no other reasons to
hold the job, the IPP object MUST accept the operation and make
the job be a candidate for processing immediately (see Section
4.2.2).
そして、クライアント(1)が既に始まった期間か'保持がありません'値(仕事を持たないように意味する)を指定する値とIPPオブジェクトがサポートする(2)を供給する、「仕事保持、-、」 操作属性、仕事を持つ他の理由が全くなくて、IPPオブジェクトは、操作を受け入れて、すぐに仕事が処理の候補であることを作らなければなりません(セクション4.2.2を見てください)。
If the client does not supply a "job-hold-until" Operation
attribute in the request, the IPP object MUST populate the job
object with a "job-hold-until" attribute with the 'indefinite'
value (if IPP object supports the "job-hold-until" attribute)
and hold the job indefinitely, until a client performs a
Release-Job operation.
クライアントがaを供給しない、「仕事の保持、」 要求におけるOperation属性、IPPオブジェクトがaで仕事のオブジェクトに居住しなければならない、「仕事の保持、」 '無期'の値がある属性、(IPPオブジェクトサポートである、「仕事の保持、」 属性、)、仕事を無期限に持ってください、クライアントがRelease-仕事の操作を実行するまで。
3.3.5.2 Hold-Job Response
3.3.5.2 保持仕事の応答
The groups and attributes are the same as for a Cancel-Job response (see section 3.3.3.2).
セクション3.3を見てください。グループと属性がキャンセル仕事の応答のように同じである、(.3 .2)。
Hastings, et al. Standards Track [Page 73] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[73ページ]: モデルと意味論2000年9月
3.3.6 Release-Job Operation
3.3.6 リリース仕事の操作
This OPTIONAL operation allows a client to release a previously held job so that it is again eligible for scheduling. If the Hold-Job operation is supported, then the Release-Job operation MUST be supported, and vice-versa.
クライアントがこのOPTIONAL操作で以前に開催された仕事をリリースできるので、スケジューリングに、それは再び、適任です。 Hold-仕事の操作がサポートされるなら、Release-仕事の操作をサポートしなければなりません、そして、逆もまた同様です。
This operation removes the "job-hold-until" job attribute, if present, from the job object that had been supplied in the create or most recent Hold-Job or Restart-Job operation and removes its effect on the job. The IPP object MUST remove the 'job-hold-until- specified' value from the job's "job-state-reasons" attribute, if present. See section 4.3.8.
そして、この操作が取り外される、「仕事の保持、」 存在している中に供給された仕事のオブジェクトからの仕事の属性、作成、最新のHold-仕事かRestart-仕事の操作、仕事への効果を取り除きます。 IPPオブジェクトが'仕事保持を取り除かなければならない、-、-'指定されて、存在しているなら仕事からの値による「仕事の州の理由」属性であるまで。 セクション4.3.8を見てください。
The IPP object MUST accept or reject the request based on the job's current state and transition the job to the indicated new state as follows:
IPPオブジェクトは、仕事の現状に基づいて要求を受け入れなければならないか、または拒絶しなければなりません、そして、変遷は以下の示された新しい状態への仕事を拒絶します:
Current "job- New "job-state" IPP object's response status
state" code and action:
現在の「「という」 IPPオブジェクトのものを仕事して述べてください仕事の新しい応答状態状態」コードと動き:
'pending' 'pending' 'successful-ok'
No effect on the job.
'pending-held' 'pending-held' 'successful-ok' See Rule 1
'pending-held' 'pending' 'successful-ok'
'processing' 'processing' 'successful-ok'
No effect on the job.
'processing- 'processing- 'successful-ok'
stopped' stopped' No effect on the job.
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'
仕事への'未定'の'未定'の'うまくいっているOK'いいえ効果。 仕事への'未定に保持された''未定に保持された''うまくいっているOK'See Rule1'未定に保持された''未定'の'うまくいっているOK''処理''処理''うまくいっているOK'いいえ効果。 'うまくいっているOK'が止めた'処理'処理は仕事への効果を全く'止まりませんでした'。 '完成した''完成した''可能でないクライアント誤り''取り消された''取り消された''可能でないクライアント誤り''は中止になったこと'が'可能でないクライアント誤り'を'中止になりました'。
Rule 1: If there are other reasons to keep the job in the 'pending- held' state, such as 'resources-are-not-ready', the job remains in the 'pending-held' state. Thus the 'pending-held' state is not just for jobs that have the 'job-hold-until' applied to them, but are for any reason to keep the job from being a candidate for scheduling and processing, such as 'resources-are-not-ready'. See the "job-hold- until" attribute (section 4.2.2).
規則1: '未定の保持された'状態に仕事を保つ他の理由があれば、'リソースは準備ができていません'などのような仕事は'未定に保持された'州に残っています。 その結果、'未定に保持された'状態がそうした仕事だけのためのものでない、'、仕事の保持、'それらに適用しますが、仕事がスケジューリングと処理の'リソースは準備ができないことなど'の候補であることを妨げるどんな理由でも、あります。 見る、「仕事保持、-、」 属性(セクション4.2.2)まで。
Access Rights: The authenticated user (see section 8.3) performing this operation must either be the job owner or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate.
アクセス権: この操作を実行している認証されたユーザ(セクション8.3を見る)は、Printerオブジェクトの仕事の所有者、オペレータまたは管理者のどちらかであるに違いありません(セクション1と8.5を見てください)。 さもなければ、IPPオブジェクトは、操作を拒絶して、戻らなければなりません: '禁じられたクライアント誤り'、'誤りが認証しなかったクライアント'、または'誤りが権限を与えなかったクライアント'、適宜。
Hastings, et al. Standards Track [Page 74] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[74ページ]: モデルと意味論2000年9月
The Release-Job Request and Release-Job Response have the same attribute groups and attributes as the Cancel-Job operation (see section 3.3.3.1 and 3.3.3.2).
Release-仕事のRequestとRelease-仕事のResponseにはキャンセル仕事の操作として同じ属性グループと属性がある、(.1と3.3が、3.3に.3を区分するのを見る、.3 .2)。
3.3.7 Restart-Job Operation
3.3.7 再開仕事の操作
This OPTIONAL operation allows a client to restart a job that is retained in the queue after processing has completed (see section 4.3.7.2).
セクション4.3を見てください。完成されて、処理が再開した後にこのOPTIONAL操作でクライアントを待ち行列で保有される仕事を再開する、(.7 .2)。
The job is moved to the 'pending' or 'pending-held' job state and restarts at the beginning on the same IPP Printer object with the same attribute values. If any of the documents in the job were passed by reference (Print-URI or Send-URI), the Printer MUST re- fetch the data, since the semantics of Restart-Job are to repeat all Job processing. The Job Description attributes that accumulate job progress, such as "job-impressions-completed", "job-media-sheets- completed", and "job-k-octets-processed", MUST be reset to 0 so that they give an accurate record of the job from its restart point. The job object MUST continue to use the same "job-uri" and "job-id" attribute values.
仕事は、'未定'の、または、'未定に保持された'仕事の状態に動かされて、同じIPP Printerオブジェクトの始めに同じ属性値で再開します。 参照(印刷URIかSend-URI)で仕事におけるドキュメントのどれかが渡されたなら、Printerはデータを再とって来なければなりません、Restart-仕事の意味論がすべてのJob処理を繰り返すことであるので。 「印象が完了した仕事」などのように「仕事メディアシートで完成した」仕事の進歩を蓄積するJob記述属性、「仕事のk八重奏は処理したこと」を0にリセットしなければならないので、それらは再開ポイントから仕事の正確な記録を与えます。 仕事のオブジェクトは、同じ「仕事-uri」と「仕事イド」属性値を使用し続けなければなりません。
Note: If in the future an operation is needed that does not reset the job progress attributes, then a new operation will be defined which makes a copy of the job, assigns a new "job-uri" and "job-id" to the copy and resets the job progress attributes in the new copy only.
以下に注意してください。 仕事の進歩属性をリセットしない操作が将来必要であるなら、新しい操作は定義されるでしょう(仕事のコピーを作って、新しい「仕事-uri」と「仕事イド」をコピーに割り当てて、新しいコピーだけの仕事の進歩属性をリセットします)。
The IPP object MUST accept or reject the request based on the job's current state, transition the job to the indicated new state as follows:
IPPオブジェクトは、仕事の現状に基づいて要求を受け入れなければならないか、または拒絶しなければならなくて、変遷は以下の示された新しい状態への仕事です:
Hastings, et al. Standards Track [Page 75] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[75ページ]: モデルと意味論2000年9月
Current "job- New "job-state" IPP object's response status
state" code and action:
現在の「「という」 IPPオブジェクトのものを仕事して述べてください仕事の新しい応答状態状態」コードと動き:
'pending' 'pending' 'client-error-not-possible'
'pending-held' 'pending-held' 'client-error-not-possible'
'processing' 'processing' 'client-error-not-possible'
'processing- 'processing- 'client-error-not-possible'
stopped' stopped'
'completed' 'pending' or 'successful-ok' - job is started
'pending-held' over.
'completed' 'completed' 'client-error-not-possible' -
see Rule 1
'canceled' 'pending' or 'successful-ok' - job is started
'pending-held' over.
'canceled' 'canceled' 'client-error-not-possible' -
see Rule 1
'aborted' 'pending' or 'successful-ok' - job is started
'pending-held' over.
'aborted' 'aborted' 'client-error-not-possible' -
see Rule 1
'完成した''完成した''可能でないクライアント誤り'--仕事が. '取り消しにされた''取り消しにされた''可能でないクライアント誤り'の上に'未定に保持する'状態で始められるという'未定であること'に'取り消しにされた'Rule1か'うまくいっているOK'が、仕事が. '中止している''中止している''可能でないクライアント誤り'の上に'未定に保持する'状態で始められるという'未定'で'中止された'Rule1か'うまくいっているOK'がRule1を見るのを見るのを見てください。
Rule 1: If the Job Retention Period has expired for the job in this state, then the IPP object rejects the operation. See section 4.3.7.2.
規則1: Job Retention Periodが期限が切れたなら、これでの仕事には、次に、IPPオブジェクトが操作を拒絶すると述べてください。 .2にセクション4.3.7を見てください。
Note: In order to prevent a user from inadvertently restarting a job in the middle, the Restart-Job request is rejected when the job is in the 'processing' or 'processing-stopped' states. If in the future an operation is needed to hold or restart jobs while in these states, it will be added as an additional operation, rather than overloading the Restart-Job operation, so that it is clear that the user intended that the current job not be completed.
以下に注意してください。 仕事が'処理'か'処理で止まっている'州にあるとき、ユーザが中央でうっかり仕事を再開するのを防ぐために、Restart-仕事の要求は拒絶されます。 操作が将来仕事を持っているか、または再開するのにこれらの州にある間、必要であるなら、それはRestart-仕事の操作を積みすぎるより兼業としてむしろ加えられるでしょう、ユーザが、現在の仕事が完了していないことを意図したのが、明確であるように。
Access Rights: The authenticated user (see section 8.3) performing this operation must either be the job owner or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate.
アクセス権: この操作を実行している認証されたユーザ(セクション8.3を見る)は、Printerオブジェクトの仕事の所有者、オペレータまたは管理者のどちらかであるに違いありません(セクション1と8.5を見てください)。 さもなければ、IPPオブジェクトは、操作を拒絶して、戻らなければなりません: '禁じられたクライアント誤り'、'誤りが認証しなかったクライアント'、または'誤りが権限を与えなかったクライアント'、適宜。
3.3.7.1 Restart-Job Request
3.3.7.1 再開仕事の要求
The groups and attributes are the same as for a Cancel-Job request (see section 3.3.3.1), with the addition of the following Group 1 Operation attribute:
グループと属性がキャンセル仕事の要求のように同じである、(.1は、)以下のGroup1Operation属性の追加で3.3に.3を区分するのを見ます:
Hastings, et al. Standards Track [Page 76] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[76ページ]: モデルと意味論2000年9月
"job-hold-until" (type3 keyword | name(MAX)):
The client OPTIONALLY supplies this attribute. The IPP object
MUST support this Operation attribute in a Restart-Job request,
if it supports the "job-hold-until" Job Template attribute in
create operations. See section 4.2.2. Otherwise, the IPP
object NEED NOT support the "job-hold-until" Operation
attribute in a Restart-Job request.
「仕事の保持、」 (type3キーワード| 名前(MAX)): クライアントOPTIONALLYはこの属性を供給します。 IPPオブジェクトはRestart-仕事の要求でこのOperation属性をサポートしなければなりません、それであるならサポート、「仕事の保持、」 Job Template属性が操作を中に作成します。 セクション4.2.2を見てください。 さもなければ、IPPオブジェクトがサポートする必要はない、「仕事の保持、」 Restart-仕事の要求におけるOperation属性。
If supplied and supported as specified in the Printer's "job-
hold-until-supported" attribute, the IPP object copies the
supplied Operation attribute to the Job object, replacing the
job's previous "job-hold-until" attribute, if present, and
makes the job a candidate for scheduling during the supplied
named time period. See section 4.2.2.
Printerの「サポートされるまでの仕事の保持」属性で指定されるように供給されて、サポートされるなら、IPPオブジェクトは供給されたOperation属性をJobオブジェクトにコピーします、前であることの状態で仕事のものを取り替えて「仕事の保持、」 供給された名前付の期間、スケジューリングの仕事のa候補を存在しているなら結果と考えて、作ります。 セクション4.2.2を見てください。
If supplied, but the value is not supported, the IPP object
accepts the request, returns the unsupported attribute or value
in the Unsupported Attributes Group according to section 3.1.7,
returns the 'successful-ok-ignored-or-substituted-attributes'
status code, and holds the job indefinitely until a client
performs a subsequent Release-Job operation.
供給しています、値だけがサポートされないで、IPPオブジェクトが要請を受け入れて、セクション3.1.7に応じてUnsupported Attributes Groupでサポートされない属性か値を返して、'うまくいっている間違いない無視されたか代入された属性'ステータスコードを返して、クライアントがその後のRelease-仕事の操作を実行するまで仕事を無期限に持っているなら。
If supplied, but the "job-hold-until" Operation attribute
itself is not supported, the IPP object accepts the request,
returns the unsupported attribute with the out-of-band
'unsupported' value in the Unsupported Attributes Group
according to section 3.1.7, returns the 'successful-ok-
ignored-or-substituted-attributes' status code, and restarts
the job, i.e., ignores the "job-hold-until" attribute.
しかし、供給する、「仕事の保持、」 Operation属性自体がサポートされないで、IPPオブジェクトが要請を受け入れて、セクション3.1.7に応じてバンドで出ている'サポートされない'値がUnsupported Attributes Groupにある状態でサポートされない属性を返して、'うまくいって間違いない無視されたか代入された属性'ステータスコードを返して、すなわち、仕事を再開する、無視、「仕事の保持、」 結果と考えます。
If the client (1) supplies a value that specifies a time period
that has already started or the 'no-hold' value (meaning don't
hold the job) and (2) the IPP object supports the "job-hold-
until" operation attribute and there are no other reasons to
hold the job, the IPP object makes the job a candidate for
processing immediately (see Section 4.2.2).
クライアント(1)が既に始まった期間か'保持がありません'値(仕事を持たないように意味する)を指定する値とIPPオブジェクトがサポートする(2)を供給する、「仕事保持、-、」 操作属性、仕事(オブジェクトがすぐに(セクション4.2.2を見る)処理の仕事のa候補を作るIPP)を持つ他の理由が全くありません。
If the client does not supply a "job-hold-until" operation
attribute in the request, the IPP object removes the "job-
hold-until" attribute, if present, from the job. If there are
no other reasons to hold the job, the Restart-Job operation
makes the job a candidate for processing immediately (see
Section 4.2.2).
クライアントがaを供給しない、「仕事の保持、」 要求における操作属性、IPPオブジェクトが取り外される、「仕事、保持、-、」 仕事によって存在しているなら、結果と考えます。 仕事を持つ他の理由が全くなければ、Restart-仕事の操作はすぐに、処理の候補に仕事を作ります(セクション4.2.2を見てください)。
Hastings, et al. Standards Track [Page 77] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[77ページ]: モデルと意味論2000年9月
3.3.7.2 Restart-Job Response
3.3.7.2 再開仕事の応答
The groups and attributes are the same as for a Cancel-Job response (see section 3.3.3.2).
セクション3.3を見てください。グループと属性がキャンセル仕事の応答のように同じである、(.3 .2)。
Note: In the future an OPTIONAL Modify-Job or Set-Job-Attributes operation may be specified that allows the client to modify other attributes before releasing the restarted job.
以下に注意してください。 将来、再開している仕事をリリースする前にクライアントが他の属性を変更できるOPTIONAL Modify-仕事かSet仕事の属性操作は指定されるかもしれません。
4. Object Attributes
4. オブジェクト属性
This section describes the attributes with their corresponding attribute syntaxes and values that are part of the IPP model. The sections below show the objects and their associated attributes which are included within the scope of this protocol. Many of these attributes are derived from other relevant documents:
このセクションはそれらの対応する属性構文とIPPモデルの一部である値で属性について説明します。 下のセクションは、どれがこのプロトコルの範囲の中に含まれているかをオブジェクトとそれらの関連属性に示します。 他の関連ドキュメントからこれらの属性の多くを得ます:
- Document Printing Application (DPA) [ISO10175]
- RFC 1759 Printer MIB [RFC1759]
- ドキュメント印刷アプリケーション(DPA)[ISO10175]--RFC1759プリンタMIB[RFC1759]
Each attribute is uniquely identified in this document using a "keyword" (see section 12.2.1) which is the name of the attribute. The keyword is included in the section header describing that attribute.
各属性は、本書では属性の名前である「キーワード」(セクション12.2.1を見る)を使用することで唯一特定されます。 キーワードはその属性について説明する節の見出しに含まれています。
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.
以下に注意してください。 キーワードが属性を特定するのに使用されるだけではなく、キーワード値が、以下で説明された属性構文の1つが「キーワード」であるので、いくつかの属性にあります。 したがって、これらの属性は1セットのキーワードである属性構文を持っていると定義されます。
4.1 Attribute Syntaxes
4.1 属性構文
This section defines the basic attribute syntax types that all clients and IPP objects MUST be able to accept in responses and accept in requests, respectively. Each attribute description in sections 3 and 4 includes the name of attribute syntax(es) in the heading (in parentheses). A conforming implementation of an attribute MUST include the semantics of the attribute syntax(es) so identified. Section 6.3 describes how the protocol can be extended with new attribute syntaxes.
このセクションはそれぞれ、すべてのクライアントとIPPオブジェクトが応答で受け入れて、要求で受け入れることができなければならない基本的な属性構文タイプを定義します。 セクション3と4のそれぞれの属性記述は見出し(括弧の)に属性構文(es)の名前を含んでいます。 属性の従う実装はそのように特定された属性構文(es)の意味論を含まなければなりません。 セクション6.3は新しい属性構文でどうプロトコルを広げることができるかを説明します。
The attribute syntaxes are specified in the following sub-sections, where the sub-section heading is the keyword name of the attribute syntax inside the single quotes. In operation requests and responses each attribute value MUST be represented as one of the attribute syntaxes specified in the sub-section heading for the attribute. In addition, the value of an attribute in a response (but not in a
属性構文は以下の小区分で指定されます、小区分見出しがシングル・クォーテション・マークにおける属性構文のキーワード名であるところで。 操作要求と応答では、属性構文の1つが小区分見出しで指定したように属性のために各属性値を表さなければなりません。 追加、応答における、属性の値、(aでない
Hastings, et al. Standards Track [Page 78] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[78ページ]: モデルと意味論2000年9月
request) MAY be one of the "out-of-band" values whose special encoding rules are defined in the "Encoding and Transport" document [RFC2910]. Standard "out-of-band" values are:
要求) 「バンドの外」という特別な符号化規則が「コード化と輸送」というドキュメント[RFC2910]で定義される値の1つはそうです。 「バンドの外」という標準の値は以下の通りです。
'unknown': The attribute is supported by the IPP object, but the
value is unknown to the IPP object for some reason.
'unsupported': The attribute is unsupported by the IPP object.
This value MUST be returned only as the value of an attribute
in the Unsupported Attributes Group.
'no-value': The attribute is supported by the Printer object, but
the administrator has not yet configured a value.
'未知': 属性はIPPオブジェクトによってサポートされますが、IPPオブジェクトにおいて、値はある理由で未知です。 'サポートされない': 属性はIPPオブジェクトでサポートされないです。 単にUnsupported Attributes Groupの属性の値としてこの値を返さなければなりません。 '値がありません': 属性はPrinterオブジェクトによってサポートされますが、管理者はまだ値を構成していません。
All attributes in a request MUST have one or more values as defined in Sections 4.2 to 4.4. Thus clients MUST NOT supply attributes with "out-of-band" values for operations defined in this document. All attributes in a response MUST have one or more values as defined in Sections 4.2 to 4.4 or a single "out-of-band" value.
要求におけるすべての属性に、1つ以上の値がセクション4.2〜4.4で定義されるようになければなりません。 したがって、クライアントは「バンドの外」がある属性値を本書では定義された操作に供給してはいけません。 応答におけるすべての属性に、セクション4.2〜4.4で定義される1つ以上の値か「バンドの外」というただ一つの値がなければなりません。
Most attributes are defined to have a single attribute syntax. However, a few attributes (e.g., "job-sheet", "media", "job-hold- until") are defined to have several attribute syntaxes, depending on the value. These multiple attribute syntaxes are separated by the "|" character in the sub-section heading to indicate the choice. Since each value MUST be tagged as to its attribute syntax in the protocol, a single-valued attribute instance may have any one of its attribute syntaxes and a multi-valued attribute instance may have a mixture of its defined attribute syntaxes.
ほとんどの属性が、ただ一つの属性構文を持つために定義されます。 しかしながら、いくつかが結果と考える、(例えば、「仕事シート」、「メディア」、「仕事保持、-、」、)、いくつかの属性構文を持つために、値によって、定義されます。 「これらの複数の属性構文が切り離される、」|「選択を示すのを向かう小区分におけるキャラクタ。」 プロトコルの属性構文に関して各値にタグ付けをしなければならないので、単一に評価された属性インスタンスには、属性構文のどれかがあるかもしれません、そして、マルチ評価された属性インスタンスには、定義された属性構文の混合物があるかもしれません。
4.1.1 'text'
4.1.1 'テキスト'
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.
テキスト属性は値がゼロの系列である属性であるか、より多くのキャラクタが最大1023年('MAX')に八重奏をコード化しました。 MAXはどんなテキスト属性の各値のための最大の長さです。 しかしながら、属性がいつも最大の長さがMAXよりはるかに少ない値を含むと、その属性の定義はその属性の値のために最大の長さを定義する資格を与える人を含むでしょう。 例えば: 「プリンタ位置」属性が指定される、「プリンタ位置、(テキスト(127))、」 この場合、「プリンタ位置」へのテキスト値は127の八重奏を超えてはいけません。 いくつかの外部のインタフェース(プロトコルを除いた)を通して、より長いテキスト文字列を供給するなら、実装はこのより短い長さに制限に自由に先端を切らせることができます。
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
本書では、すべてのテキスト属性が、'テキスト'構文を使用することで定義されます。 しかしながら、'テキスト'は簡潔さにだけ使用されます。 'テキスト'の正式な解釈は以下の通りです。 'textWithoutLanguage'| 'textWithLanguage'。 そしてすなわち、本書では'テキスト'属性構文を使用することで定義されたどんな属性のためにもすべてのIPPが反対する。
Hastings, et al. Standards Track [Page 79] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[79ページ]: モデルと意味論2000年9月
clients MUST support both the 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes. However, in actual usage and protocol execution, objects and clients accept and return only one of the two syntax per attribute. The syntax 'text' never appears "on- the-wire".
クライアントは、両方が'textWithoutLanguage'と'textWithLanguage'属性構文であるとサポートしなければなりません。 しかしながら、実際の用法とプロトコル実行では、オブジェクトとクライアントは、1属性あたりの2構文の1つだけを受け入れて、返します。 構文'テキスト'が決して現れない、「オンである、-配線してください、」
Both 'textWithoutLanguage' and 'textWithLanguage' are needed to support the real world needs of interoperability between sites and systems that use different natural languages as the basis for human communication. Generally, one natural language applies to all text attributes in a given request or response. The language is indicated by the "attributes-natural-language" operation attribute defined in section 3.1.4 or "attributes-natural-language" job attribute defined in section 4.3.20, and there is no need to identify the natural language for each text string on a value-by-value basis. In these cases, the attribute syntax 'textWithoutLanguage' is used for text attributes. In other cases, the client needs to supply or the Printer object needs to return a text value in a natural language that is different from the rest of the text values in the request or response. In these cases, the client or Printer object uses the attribute syntax 'textWithLanguage' for text attributes (this is the Natural Language Override mechanism described in section 3.1.4).
'textWithoutLanguage'と'textWithLanguage'の両方が、本当の世界が人間のコミュニケーションの基礎として異なった自然言語を使用するサイトとシステムの間の相互運用性の必要性であるとサポートするのに必要です。 一般に、1つの自然言語が与えられた要求か応答におけるすべてのテキスト属性に適用されます。 言語はセクション4.3.20で定義されたセクション3.1.4か「属性自然言語」仕事の属性で定義された「属性自然言語」操作属性によって示されます、そして、値ごとのベースの各テキスト文字列のために自然言語を特定する必要は全くありません。 これらの場合では、属性構文'textWithoutLanguage'はテキスト属性に使用されます。 他の場合では、クライアントは要求か応答における、テキスト値の残りと異なった自然言語のテキスト値を返すオブジェクトの必要性を供給かPrinterに必要とします。 これらの場合では、クライアントかPrinterオブジェクトがテキスト属性に属性構文'textWithLanguage'を使用します(これはセクション3.1.4で説明されたNatural Language Overrideメカニズムです)。
The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes are described in more detail in the following sections.
'textWithoutLanguage'と'textWithLanguage'属性構文はさらに詳細に以下のセクションで説明されます。
4.1.1.1 'textWithoutLanguage'
4.1.1.1 'textWithoutLanguage'
The 'textWithoutLanguage' syntax indicates a value that is sequence of zero or more characters encoded in a maximum of 1023 (MAX) octets. Text strings are encoded using the rules of some charset. The Printer object MUST support the UTF-8 charset [RFC2279] and MAY support additional charsets to represent 'text' values, provided that the charsets are registered with IANA [IANA-CS]. See Section 4.1.7 for the definition of the 'charset' attribute syntax, including restricted semantics and examples of charsets.
'textWithoutLanguage'構文はゼロの系列である値か最大1023(MAX)の八重奏でコード化されたより多くのキャラクタを示します。 テキスト文字列は、いくらかのcharsetの規則を使用することでコード化されます。 Printerオブジェクトは、UTF-8 charset[RFC2279]をサポートしなければならなくて、'テキスト'値を表すために追加charsetsをサポートするかもしれません、charsetsがIANA[IANA-CS]に登録されれば。 charsetsに関する制限された意味論と例を含む'charset'属性構文の定義に関してセクション4.1.7を見てください。
4.1.1.2 'textWithLanguage'
4.1.1.2 'textWithLanguage'
The 'textWithLanguage' attribute syntax is a compound attribute syntax consisting of two parts: a 'textWithoutLanguage' part encoded in a maximum of 1023 (MAX) octets plus an additional 'naturalLanguage' (see section 4.1.8) part that overrides the natural language in force. The 'naturalLanguage' part explicitly identifies the natural language that applies to the text part of that value and that value alone. For any give text attribute, the 'textWithoutLanguage' part is limited to the maximum length defined for that 'text' attribute, and the 'naturalLanguage' part is always
'textWithLanguage'属性構文は2つの部品から成る複合属性構文です: 'textWithoutLanguage'部分は最大1023年(MAX)に八重奏と大挙して自然言語をくつがえす追加'naturalLanguage'(セクション4.1.8を見る)部分をコード化しました。 'naturalLanguage'部分は明らかに単独でその値とその価値のテキスト一部分に適用される自然言語を特定します。 'textWithoutLanguage'部分はその'テキスト'属性のために定義された最大の長さに制限されます、そして、いずれに関しては、テキスト属性をお願いします、いつも'naturalLanguage'部分はテキスト属性です。
Hastings, et al. Standards Track [Page 80] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[80ページ]: モデルと意味論2000年9月
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.
63の(追加する)の八重奏に制限されています。 正常な'textWithoutLanguage'構文よりむしろ'textWithLanguage'属性構文を使用するのをいわゆるNatural Language Overrideメカニズムであり、すべてのIPPオブジェクトとクライアントはサポートしなければなりません。
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.
属性がマルチ評価されているなら(1setOfテキスト)、明らかに、自然言語がくつがえされる必要がある各属性値を指定するのに'textWithLanguage'属性構文を使用しなければなりません。 要求におけるマルチ評価された'テキスト'属性か操作属性の自然言語への応答復帰者の他の値。
In a create request, the Printer object MUST accept and store with the Job object any natural language in the "attributes-natural- language" operation attribute, whether the Printer object supports that natural language or not. Furthermore, the Printer object MUST accept and store any 'textWithLanguage' attribute value, whether the Printer object supports that natural language or not. These requirements are independent of the value of the "ipp-attribute- fidelity" operation attribute that the client MAY supply.
aでは、要求を作成してください、とPrinterオブジェクトは受け入れなければなりません、そして、Jobオブジェクトで「属性当然の言語」の操作属性におけるあらゆる自然言語を保存してください、Printerオブジェクトがその自然言語をサポートするか否かに関係なく。 その上、Printerオブジェクトは、どんな'textWithLanguage'属性値も受け入れて、保存しなければなりません、Printerオブジェクトがその自然言語をサポートするか否かに関係なく。 これらの要件はクライアントが供給するかもしれない「ipp信義を結果と考えている」操作属性の価値から独立しています。
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:
例: クライアントが「属性自然言語」操作を供給するなら、値で以下を結果と考えてください。 英語、しかし、「ジョブ名」属性の値を示す'アン'がフランス語であって、クライアントは以下の2つの値がある'textWithLanguage'属性構文を使用しなければなりません:
'fr': Natural Language Override indicating French
'Rapport Mensuel': the job name in French
'fr': フランスの'関係Mensuel'を示す自然なLanguage Override: フランス語のジョブ名
See the "Encoding and Transport" document [RFC2910] section 3.9 for the encoding of the two parts and Appendix A for a detailed example of the 'textWithLanguage' attribute syntax.
2つの部品とAppendix Aのコード化に関して'textWithLanguage'属性構文の詳細な例に関して「コード化と輸送」というドキュメント[RFC2910]部分3.9を見てください。
4.1.2 'name'
4.1.2 '名前'
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.
この構文タイプはPrinter名などの人間には、識別子より重要なユーザフレンドリーなストリングに使用されます。 名前は1つの自然言語から別の自然言語まで決して翻訳されません。 '名前'属性構文は'テキスト'と本質的には同じです、キャラクタの系列が限られている以外に、UTF-8のREQUIREDサポートを含んでいてコード化されたフォームは255(MAX)の八重奏を超えてはいけません。
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
'テキスト'のようにも、'名前'は本当に'nameWithoutLanguage'か'nameWithLanguage'のどちらかのための省略表記法です。 すなわちすべてのIPPオブジェクトとクライアントは、両方が'nameWithoutLanguage'と'nameWithLanguage'属性構文であるとサポートしなければなりません。 そしてしかしながら、実際の用法。
Hastings, et al. Standards Track [Page 81] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[81ページ]: モデルと意味論2000年9月
protocol execution, objects and clients accept and return only one of the two syntax per attribute. The syntax 'name' never appears "on- the-wire".
プロトコル実行、オブジェクト、およびクライアントは、1属性あたりの2構文の1つだけを受け入れて、返します。 構文'名前'が決して現れない、「オンである、-配線してください、」
Only the 'text' and 'name' attribute syntaxes permit the Natural Language Override mechanism.
'テキスト'と'名前'属性構文だけがNatural Language Overrideメカニズムを可能にします。
Some attributes are defined as 'type3 keyword | name'. These attributes support values that are either type3 keywords or names. This dual-syntax mechanism enables a site administrator to extend these attributes to legally include values that are locally defined by the site administrator. Such names are not registered with IANA.
いくつかの属性が'type3キーワード'と定義されます。| '命名します'。 これらの属性はtype3キーワードか名前のどちらかである値をサポートします。 この二元的な構文メカニズムは、サイトの管理者がサイトの管理者によって局所的に定義される値を法的に含むようにこれらの属性を広げるのを可能にします。 そのような名前はIANAに登録されません。
4.1.2.1 'nameWithoutLanguage'
4.1.2.1 'nameWithoutLanguage'
The 'nameWithoutLanguage' syntax indicates a value that is sequence of zero or more characters encoded in a maximum of 255 (MAX) octets.
'nameWithoutLanguage'構文はゼロの系列である値か最大255(MAX)の八重奏でコード化されたより多くのキャラクタを示します。
4.1.2.2 'nameWithLanguage'
4.1.2.2 'nameWithLanguage'
The 'nameWithLanguage' attribute syntax is a compound attribute syntax consisting of two parts: a 'nameWithoutLanguage' part encoded in a maximum of 1023 (MAX) octets plus an additional 'naturalLanguage' (see section 4.1.8) part that overrides the natural language in force. The 'naturalLanguage' part explicitly identifies the natural language that applies to that name value and that name value alone. For any give text attribute, the 'textWithoutLanguage' part is limited to the maximum length defined for that 'text' attribute, and the 'naturalLanguage' part is always limited to 63 (additional) octets. Using the 'textWithLanguage' attribute syntax rather than the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism and MUST be supported by all IPP objects and clients.
'nameWithLanguage'属性構文は2つの部品から成る複合属性構文です: 'nameWithoutLanguage'部分は最大1023年(MAX)に八重奏と大挙して自然言語をくつがえす追加'naturalLanguage'(セクション4.1.8を見る)部分をコード化しました。 'naturalLanguage'部分は明らかに単独でその名前値とその名前値に適用される自然言語を特定します。 'textWithoutLanguage'部分はその'テキスト'属性のために定義された最大の長さに制限されます、そして、いずれに関しては、テキスト属性をお願いします、'naturalLanguage'部分はいつも63の(追加する)の八重奏に制限されます。 正常な'textWithoutLanguage'構文よりむしろ'textWithLanguage'属性構文を使用するのをいわゆるNatural Language Overrideメカニズムであり、すべてのIPPオブジェクトとクライアントはサポートしなければなりません。
The 'nameWithLanguage' attribute syntax behaves the same as the 'textWithLanguage' syntax. Using the 'textWithLanguage' attribute syntax rather than the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism and MUST be supported by all IPP objects and clients. If a name is in a language that is different than the rest of the object or operation, then this 'nameWithLanguage' syntax is used rather than the generic 'nameWithoutLanguage' syntax.
'nameWithLanguage'属性構文は'textWithLanguage'構文として同じように振る舞います。 正常な'textWithoutLanguage'構文よりむしろ'textWithLanguage'属性構文を使用するのをいわゆるNatural Language Overrideメカニズムであり、すべてのIPPオブジェクトとクライアントはサポートしなければなりません。 オブジェクトか操作の残りと異なった言語に名前があるなら、この'nameWithLanguage'構文はジェネリック'nameWithoutLanguage'構文よりむしろ使用されます。
If the attribute is multi-valued (1setOf text), then the 'nameWithLanguage' attribute syntax MUST be used to explicitly specify each attribute value whose natural language needs to be overridden.
属性がマルチ評価されているなら(1setOfテキスト)、明らかに、自然言語がくつがえされる必要がある各属性値を指定するのに'nameWithLanguage'属性構文を使用しなければなりません。
Hastings, et al. Standards Track [Page 82] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[82ページ]: モデルと意味論2000年9月
Other values in a multi-valued 'name' attribute in a request or a response revert to the natural language of the operation attribute.
要求におけるマルチ評価された'名前'属性か操作属性の自然言語への応答復帰者の他の値。
In a create request, the Printer object MUST accept and store with the Job object any natural language in the "attributes-natural- language" operation attribute, whether the Printer object supports that natural language or not. Furthermore, the Printer object MUST accept and store any 'nameWithLanguage' attribute value, whether the Printer object supports that natural language or not. These requirements are independent of the value of the "ipp-attribute- fidelity" operation attribute that the client MAY supply.
aでは、要求を作成してください、とPrinterオブジェクトは受け入れなければなりません、そして、Jobオブジェクトで「属性当然の言語」の操作属性におけるあらゆる自然言語を保存してください、Printerオブジェクトがその自然言語をサポートするか否かに関係なく。 その上、Printerオブジェクトは、どんな'nameWithLanguage'属性値も受け入れて、保存しなければなりません、Printerオブジェクトがその自然言語をサポートするか否かに関係なく。 これらの要件はクライアントが供給するかもしれない「ipp信義を結果と考えている」操作属性の価値から独立しています。
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:
例: クライアントが「属性自然言語」操作を供給するなら、値で以下を結果と考えてください。 英語、しかし、「プリンタ名」属性を示す'アン'がドイツ語であって、クライアントは以下の'nameWithLanguage'属性構文を使用しなければなりません:
'de': Natural Language Override indicating German
'Farbdrucker': the Printer name in German
'de': ドイツの'Farbdrucker'を示す自然なLanguage Override: ドイツ語のPrinter名
See the "Encoding and Transport" document [RFC2910] section 3.9 for the encoding of the two parts and Appendix A for a detailed example of the 'nameWithLanguage' attribute syntax.
2つの部品とAppendix Aのコード化に関して'nameWithLanguage'属性構文の詳細な例に関して「コード化と輸送」というドキュメント[RFC2910]部分3.9を見てください。
4.1.2.3 Matching 'name' attribute values
4.1.2.3 合っている'名前'属性値
For purposes of matching two 'name' attribute values for equality, such as in job validation (where a client-supplied value for attribute "xxx" is checked to see if the value is among the values of the Printer object's corresponding "xxx-supported" attribute), the following match rules apply:
仕事の合法化などの平等(属性"xxx"のためのクライアント供給値がPrinterオブジェクトの対応する「xxxによってサポートしている」属性の値の中に値があるかを確認するためにチェックされるところ)のための合っている2'名前'属性値の目的のために、以下のマッチ規則は申し込まれます:
1. 'keyword' values never match 'name' values.
1. 'キーワード'値は'名前'値に決して合っていません。
2. 'name' (nameWithoutLanguage and nameWithLanguage) values match
if (1) the name parts match and (2) the Associated Natural-
Language parts (see section 3.1.4.1) match. The matching rules
are:
2. '名前'(nameWithoutLanguageとnameWithLanguage)値は(1) 名前一部が合うか、そして、(2) Associated Natural言語一部に合っています。(.1が)合っているセクション3.1.4を見てください。 合っている規則は以下の通りです。
a. the name parts match if the two names are identical
character by character, except it is RECOMMENDED that case
be ignored. For example: 'Ajax-letter-head-white' MUST
match 'Ajax-letter-head-white' and SHOULD match 'ajax-
letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'.
a. 名前一部が2つの名前がキャラクタであるごとに同じである合って、ケースが無視されるのは、RECOMMENDEDです。 例えば: 'アイアス手紙ヘッド白'は'アイアス手紙ヘッド白に合わなければなりません、そして、'SHOULDは''ajax手紙ヘッド白'とアイアス・LETTER-HEADホワイトに合います'。
Hastings, et al. Standards Track [Page 83] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[83ページ]: モデルと意味論2000年9月
b. the Associated Natural-Language parts match if the shorter
of the two meets the syntactic requirements of RFC 1766
[RFC1766] and matches byte for byte with the longer. For
example, 'en' matches 'en', 'en-us' and 'en-gb', but matches
neither 'fr' nor 'e'.
b. 二人のうち背が低い方がRFC1766[RFC1766]の構文の必要条件を満たして、バイトバイトをより長く合わせるなら、Associated Natural-言語一部が合っています。 例えば、'アンは''アンを合わせ''、アン、-、私たち、''アンでgbします'が、'fr'も'e'も合わせません。
4.1.3 'keyword'
4.1.3 'キーワード'
The 'keyword' attribute syntax is a sequence of characters, length: 1
to 255, containing only the US-ASCII [ASCII] encoded values for
lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot
("."), and underscore ("_"). The first character MUST be a lowercase
letter. Furthermore, keywords MUST be in U.S. English.
'キーワード'属性構文はキャラクタ、長さの系列です: 米国-ASCII[ASCII]だけを含んでいると、1〜255に、値は小文字(“a"--「z」)のためにコード化されました、ケタ、(「0インチ--、「9インチ)、(「-」)をハイフンで結んでください、ドット、(「」、)、そして、強調("_")、」 最初のキャラクタは小文字であるに違いありません。 その上、キーワードが米国のイギリス人にあるに違いありません。
This syntax type is used for enumerating semantic identifiers of entities in the abstract protocol, i.e., entities identified in this document. Keywords are used as attribute names or values of attributes. Unlike 'text' and 'name' attribute values, 'keyword' values MUST NOT use the Natural Language Override mechanism, since they MUST always be US-ASCII and U.S. English.
この構文タイプは、抽象的なプロトコル(すなわち、本書では特定された実体)の実体の意味識別子を列挙するのに使用されます。 キーワードは属性の属性名か値として使用されます。 'テキスト'と'名前'属性値と異なって、'キーワード'値はNatural Language Overrideメカニズムを使用してはいけません、いつも、彼らが米国-ASCIIと米国のイギリス人であるに違いないので。
Keywords are for use in the protocol. A user interface will likely provide a mapping between protocol keywords and displayable user- friendly words and phrases which are localized to the natural language of the user. While the keywords specified in this document MAY be displayed to users whose natural language is U.S. English, they MAY be mapped to other U.S. English words for U.S. English users, since the user interface is outside the scope of this document.
キーワードはプロトコルにおける使用のためのものです。 ユーザーインタフェースは、おそらくプロトコルキーワードの間にマッピングを提供して、ユーザの自然言語にローカライズされるユーザの好意的な字句を「ディスプレイ-可能」するでしょう。 自然言語が米国のイギリス人であるユーザに本書では指定されたキーワードを表示しているかもしれない間、米国のイギリス人のユーザのために他の米国英単語に彼らを写像するかもしれません、このドキュメントの範囲の外にユーザーインタフェースがあるので。
In the definition for each attribute of this syntax type, the full set of defined keyword values for that attribute are listed.
この構文の各属性のための定義では、タイプ、その属性のための定義されたキーワード値のフルセットは記載されています。
When a keyword is used to represent an attribute (its name), it MUST be unique within the full scope of all IPP objects and attributes. When a keyword is used to represent a value of an attribute, it MUST be unique just within the scope of that attribute. That is, the same keyword MUST NOT be used for two different values within the same attribute to mean two different semantic ideas. However, the same keyword MAY be used across two or more attributes, representing different semantic ideas for each attribute. Section 6.1 describes how the protocol can be extended with new keyword values. Examples of attribute name keywords:
キーワードが属性(名前)を表すのに使用されるとき、それはすべてのIPPオブジェクトと属性の完全な範囲の中でユニークであるに違いありません。 キーワードが属性の値を表すのに使用されるとき、それはその属性の範囲のすぐ中でユニークであるに違いありません。 同じ属性の中の2つの異価が2つの異なった意味考えを意味するのにすなわち、同じキーワードを使用してはいけません。 しかしながら、各属性のための異なった意味考えを表して、同じキーワードは2つ以上の属性の向こう側に使用されるかもしれません。 セクション6.1は新しいキーワード値でどうプロトコルを広げることができるかを説明します。 属性名前キーワードに関する例:
"job-name"
"attributes-charset"
「ジョブ名」「属性-charset」
Hastings, et al. Standards Track [Page 84] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[84ページ]: モデルと意味論2000年9月
Note: This document uses "type1", "type2", and "type3" prefixes to the "keyword" basic syntax to indicate different levels of review for extensions (see section 6.1).
以下に注意してください。 このドキュメントが使用する、「type1"、「type2"、「type3"は拡大のために異なったレベルのレビューを示すために「キーワード」へ基本的な構文を前に置セクション6.1を(見てください)」。
4.1.4 'enum'
4.1.4 'enum'
The 'enum' attribute syntax is an enumerated integer value that is in the range from 1 to 2**31 - 1 (MAX). Each value has an associated 'keyword' name. In the definition for each attribute of this syntax type, the full set of possible values for that attribute are listed. This syntax type is used for attributes for which there are enum values assigned by other standards, such as SNMP MIBs. A number of attribute enum values in this document are also used for corresponding attributes in other standards [RFC1759]. This syntax type is not used for attributes to which the administrator may assign values. Section 6.1 describes how the protocol can be extended with new enum values.
'enum'属性構文は範囲で1〜2**31--1(MAX)から来ている列挙された整数値です。 各値には、関連'キーワード'名があります。 この構文の各属性のための定義では、タイプ、その属性のための可能な値のフルセットは記載されています。 この構文タイプは他の規格によって割り当てられたenum値がある属性に使用されます、SNMP MIBsなどのように。 また、多くの属性enum値が他の規格[RFC1759]における対応する属性に本書では使用されます。 この構文タイプは管理者が値を割り当てるかもしれない属性に使用されません。 セクション6.1は新しいenum値でどうプロトコルを広げることができるかを説明します。
Enum values are for use in the protocol. A user interface will provide a mapping between protocol enum values and displayable user- friendly words and phrases which are localized to the natural language of the user. While the enum symbols specified in this document MAY be displayed to users whose natural language is U.S. English, they MAY be mapped to other U.S. English words for U.S. English users, since the user interface is outside the scope of this document.
Enum値はプロトコルにおける使用のためのものです。 ユーザーインタフェースは、プロトコルenum値の間にマッピングを提供して、ユーザの自然言語にローカライズされるユーザの好意的な字句を「ディスプレイ-可能」するでしょう。 自然言語が米国のイギリス人であるユーザに本書では指定されたenumシンボルを表示しているかもしれない間、米国のイギリス人のユーザのために他の米国英単語に彼らを写像するかもしれません、このドキュメントの範囲の外にユーザーインタフェースがあるので。
Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP "out-of-band" value 'unknown'. See the description of the "out-of- band" values at the beginning of Section 4.1. Therefore, attributes of type 'enum' start at '3'.
以下に注意してください。 SNMP MIBsは「バンドの外で」IPPに対応する'未知'値の'未知'に'2'を使用します。 記述を見る、「外、-、-」 セクション4.1の始めにおける値を括ってください。 したがって、タイプ'enum'の属性は'3'時に始まります。
Note: This document uses "type1", "type2", and "type3" prefixes to the "enum" basic syntax to indicate different levels of review for extensions (see section 6.1).
以下に注意してください。 このドキュメントが使用する、「type1"、「type2"、および「拡大(セクション6.1を見る)のために異なったレベルのレビューを示す基本的な「enumな」構文へのtype3"接頭語。」
4.1.5 'uri'
4.1.5 'uri'
The 'uri' attribute syntax is any valid Uniform Resource Identifier or URI [RFC2396]. Most often, URIs are simply Uniform Resource Locators or URLs. The maximum length of URIs used as values of IPP attributes is 1023 octets. Although most other IPP attribute syntax types allow for only lower-cased values, this attribute syntax type conforms to the case-sensitive and case-insensitive rules specified in [RFC2396]. See also [IPP-IIG] for a discussion of case in URIs.
'uri'属性構文は、あらゆる有効なUniform Resource IdentifierやURI[RFC2396]です。 URIは、たいてい、単にUniform Resource LocatorかURLです。 IPP属性の値として使用される最大の長さのURIは1023の八重奏です。 他のほとんどのIPP属性構文タイプが、より低くケースに入れられた値だけを考慮しますが、この属性構文タイプは[RFC2396]で指定された大文字と小文字を区別して大文字と小文字を区別しない規則に従います。 また、URIにおけるケースの議論に関して[IPP-IIG]を見てください。
Hastings, et al. Standards Track [Page 85] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[85ページ]: モデルと意味論2000年9月
4.1.6 'uriScheme'
4.1.6 'uriScheme'
The 'uriScheme' attribute syntax is a sequence of characters representing a URI scheme according to RFC 2396 [RFC2396]. Though RFC 2396 requires that the values be case-insensitive, IPP requires all lower case values in IPP attributes to simplify comparing by IPP clients and Printer objects.
'uriScheme'属性構文はRFC2396[RFC2396]に従ってURI体系を表すキャラクタの系列です。 RFC2396は、値が大文字と小文字を区別しないのを必要としますが、IPPは、IPP属性におけるすべての小文字値がIPPクライアントで比較して、Printerオブジェクトを簡素化するのを必要とします。
Standard values for this syntax type are the following keywords:
この構文タイプのための基準値は以下のキーワードです:
'ipp': for IPP schemed URIs (e.g., "ipp:...")
'http': for HTTP schemed URIs (e.g., "http:...")
'https': for use with HTTPS schemed URIs (e.g., "https:...") (not
on IETF standards track)
'ftp': for FTP schemed URIs (e.g., "ftp:...")
'mailto': for SMTP schemed URIs (e.g., "mailto:...")
'file': for file schemed URIs (e.g., "file:...")
'ipp': IPPがURI(「ipp:」 例えば、…)'http'を計画したので: HTTPの計画されたURI(「http:」 例えば、…)'https'のために: HTTPSとの使用がURI(「https:」 例えば、…)(IETF規格では、追跡しない)'ftp'を計画したので: FTPの計画されたURI(「ftp:」 例えば、…)'mailto'のために: SMTPに関しては、計画されたURI(「mailto:」 例えば、…)は'ファイルされます': ファイルの計画されたURIのために(例えば、「ファイルしてください」…)
A Printer object MAY support any URI 'scheme' that has been registered with IANA [IANA-MT]. The maximum length of URI 'scheme' values used to represent IPP attribute values is 63 octets.
PrinterオブジェクトはIANA[IANA-MT]に登録されたどんなURI'体系'もサポートするかもしれません。 IPP属性値を表すのに使用される最大の長さのURI'体系'値は63の八重奏です。
4.1.7 'charset'
4.1.7 'charset'
The 'charset' attribute syntax is a standard identifier for a charset. A charset is a coded character set and encoding scheme. Charsets are used for labeling certain document contents and 'text' and 'name' attribute values. The syntax and semantics of this attribute syntax are specified in RFC 2046 [RFC2046] and contained in the IANA character-set Registry [IANA-CS] according to the IANA procedures [RFC2278]. Though RFC 2046 requires that the values be case-insensitive US-ASCII [ASCII], IPP requires all lower case values in IPP attributes to simplify comparing by IPP clients and Printer objects. When a character-set in the IANA registry has more than one name (alias), the name labeled as "(preferred MIME name)", if present, MUST be used.
'charset'属性構文はcharsetのための標準の識別子です。 charsetはコード化文字集合と体系をコード化することです。 Charsetsは、あるドキュメントコンテンツと'テキスト'と'名前'属性値をラベルするのに使用されます。 IANA手順[RFC2278]によると、この属性構文の構文と意味論は、RFC2046[RFC2046]で指定されて、IANA文字集合Registry[IANA-CS]に含まれています。 RFC2046は、値が大文字と小文字を区別しない米国-ASCII[ASCII]であることを必要としますが、IPPは、IPP属性におけるすべての小文字値がIPPクライアントで比較して、Printerオブジェクトを簡素化するのを必要とします。 IANA登録の文字集合に1つ以上の名前(別名)があると、存在しているなら「(都合のよいMIME名)」としてラベルされた名前を使用しなければなりません。
The maximum length of 'charset' values used to represent IPP attribute values is 63 octets.
IPP属性値を表すのに使用される最大の長さの'charset'値は63の八重奏です。
Some examples are:
いくつかの例は以下の通りです。
'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set
(UCS) represented as the UTF-8 [RFC2279] transfer encoding
scheme in which US-ASCII is a subset charset.
'us-ascii': 7-bit American Standard Code for Information
Interchange (ASCII), ANSI X3.4-1986 [ASCII]. That standard
'utf-8': UTF-8[RFC2279]がどの米国-ASCIIに体系をコード化するかながら移すので表されたISO10646Universal Multiple-八重奏Coded文字コード(UCS)は部分集合charsetです。 '、私たち、-、ASCII、'、: 7ビットの情報交換用米国標準コード(ASCII)、ANSI X3.4-1986[ASCII]。 その規格
Hastings, et al. Standards Track [Page 86] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[86ページ]: モデルと意味論2000年9月
defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the
control characters from conformant usage in MIME and IPP.
'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet
Nr 1 [ISO8859-1]. That standard defines a coded character set
that is used by Latin languages in the Western Hemisphere and
Western Europe. US-ASCII is a subset charset.
[RFC2045]が制御文字をMIMEとIPPのconformant用法から最も排除する米国のASCIIにもかかわらず、RFC2045を定義します。 'iso-8859-1': 8ビットの1バイトのコード化文字集合、ローマ字Nr1[ISO8859-1]。 その規格は西半球と西欧でラテン語によって使用されるコード化文字集合を定義します。 米国-ASCIIは部分集合charsetです。
Some attribute descriptions MAY place additional requirements on charset values that may be used, such as REQUIRED values that MUST be supported or additional restrictions, such as requiring that the charset have US- ASCII as a subset charset.
いくつかの属性記述が使用されるかもしれないcharset値に追加要件を置くかもしれません、サポートしなければならないREQUIRED値や追加制限のように、charsetには部分集合charsetとして米国ASCIIがあるのが必要であるのなどように。
4.1.8 'naturalLanguage'
4.1.8 'naturalLanguage'
The 'naturalLanguage' attribute syntax is a standard identifier for a natural language and optionally a country. The values for this syntax type are defined by RFC 1766 [RFC1766]. Though RFC 1766 requires that the values be case-insensitive US-ASCII [ASCII], IPP requires all lower case to simplify comparing by IPP clients and Printer objects. Examples include:
'naturalLanguage'属性構文は任意に自然言語のための標準の識別子です。国。 この構文タイプのための値はRFC1766[RFC1766]によって定義されます。 RFC1766は、値が大文字と小文字を区別しない米国-ASCII[ASCII]であることを必要としますが、IPPは、すべての小文字がIPPクライアントで比較して、Printerオブジェクトを簡素化するのを必要とします。 例は:
'en': for English
'en-us': for US English
'fr': for French
'de': for German
'アン': 英語、'、アン、-、私たち、'、: 米国のイギリスの'fr'のために: フランスの'de'のために: ドイツ語のために
The maximum length of 'naturalLanguage' values used to represent IPP attribute values is 63 octets.
IPP属性値を表すのに使用される最大の長さの'naturalLanguage'値は63の八重奏です。
4.1.9 'mimeMediaType'
4.1.9 'mimeMediaType'
The 'mimeMediaType' attribute syntax is the Internet Media Type (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and registered according to the procedures of RFC 2048 [RFC2048] for identifying a document format. The value MAY include a charset, or other, parameter, depending on the specification of the Media Type in the IANA Registry [IANA-MT]. Although most other IPP syntax types allow for only lower-cased values, this syntax type allows for mixed-case values which are case-insensitive.
'mimeMediaType'属性構文はドキュメント・フォーマットを特定するためにRFC2046[RFC2046]によって定義されて、RFC2048[RFC2048]の手順によると、登録されるようにインターネットメディアType(時々MIMEの種類と呼ばれる)です。 値はcharsetを含むかもしれません、何らかの、パラメタ、IANA Registry[IANA-MT]でメディアTypeの仕様によって。 他のほとんどのIPP構文タイプが、より低くケースに入れられた値だけを考慮しますが、この構文タイプは大文字と小文字を区別しない複雑なケース値を考慮します。
Examples are:
'text/html': An HTML document
'text/plain': A plain text document in US-ASCII (RFC 2046
indicates that in the absence of the charset parameter MUST
mean US-ASCII rather than simply unspecified) [RFC2046].
'text/plain; charset=US-ASCII': A plain text document in US-ASCII
[52, 56].
例は以下の通りです。 'テキスト/html': 'テキスト/平野'というHTMLドキュメント: 米国-ASCII(RFC2046は、charsetパラメタがないときそれが単に不特定であるというよりもむしろ米国のASCIIであることを意味しなければならないのを示します)[RFC2046]におけるプレーンテキストドキュメント。 'テキスト/平野'。 'charsetは米国-ASCIIと等しいです': 米国-ASCII[52、56]におけるプレーンテキストドキュメント。
Hastings, et al. Standards Track [Page 87] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[87ページ]: モデルと意味論2000年9月
'text/plain; charset=ISO-8859-1': A plain text document in ISO
8859-1 (Latin 1) [ISO8859-1].
'text/plain; charset=utf-8': A plain text document in ISO 10646
represented as UTF-8 [RFC2279]
'application/postscript': A PostScript document [RFC2046]
'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset
escape sequence embedded in the document data)
'application/pdf': Portable Document Format - see IANA MIME Media
Type registry
'application/octet-stream': Auto-sense - see section 4.1.9.1
'テキスト/平野'。 'charset=ISO-8859-1': ISO8859-1(ラテン1)[ISO8859-1]のプレーンテキストドキュメント。 'テキスト/平野'。 'charset=utf-8': ISO10646のプレーンテキストドキュメントはUTF-8[RFC2279]として'アプリケーション/追伸'を表しました: ポストスクリプトは[RFC2046]'アプリケーション/vnd.hp-PCL'を記録します: 'アプリケーション/pdf'というPCLドキュメント[IANA-MT](ドキュメントデータに埋め込まれたcharsetエスケープシーケンス): Portable Document Format--IANA MIMEメディアType登録'八重奏アプリケーション/ストリーム'を見てください: 自動感覚--セクション4.1.9を見てください、.1
The maximum length of a 'mimeMediaType' value to represent IPP attribute values is 255 octets.
IPP属性値を表す最大の長さの'mimeMediaType'価値は255の八重奏です。
4.1.9.1 Application/octet-stream -- Auto-Sensing the document format
4.1.9.1 八重奏アプリケーション/ストリーム--自動Sensing、ドキュメント・フォーマット
One special type is 'application/octet-stream'. If the Printer object supports this value, the Printer object MUST be capable of auto-sensing the format of the document data using an implementation-dependent method that examines some number of octets of the document data, either as part of the create operation and/or at document processing time. During auto-sensing, a Printer may determine that the document-data has a format that the Printer doesn't recognize. If the Printer determines this problem before returning an operation response, it rejects the request and returns the 'client-error-document-format-not-supported' status code. If the Printer determines this problem after accepting the request and returning an operation response with one of the successful status codes, the Printer adds the 'unsupported-document-format' value to the job's "job-state-reasons" attribute.
1つの特別なタイプが'八重奏アプリケーション/ストリーム'です。 Printerオブジェクトがこの値をサポートするなら、Printerオブジェクトが自動感じることができなければならない、それがどちらか部分としてのドキュメントデータの何らかの数の八重奏を調べる実装依存するメソッドを使用するドキュメントデータの形式、操作ドキュメントで処理時間を作成してください。 自動感じの間、Printerは、ドキュメントデータにはPrinterが認識しない形式があることを決定するかもしれません。 操作応答を返す前にPrinterがこの問題を決定するなら、それは、要求を拒絶して、'形式が支えなかったクライアント誤りドキュメント'ステータスコードを返します。 うまくいっているステータスコードの1つと共に要請を受け入れて、操作応答を返した後にPrinterがこの問題を決定するなら、Printerは仕事の「仕事の州の理由」属性に'サポートされないドキュメント・フォーマット'価値を高めます。
If the Printer object's default value attribute "document-format- default" is set to 'application/octet-stream', the Printer object not only supports auto-sensing of the document format, but will depend on the result of applying its auto-sensing when the client does not supply the "document-format" attribute. If the client supplies a document format value, the Printer MUST rely on the supplied attribute, rather than trust its auto-sensing algorithm. To summarize:
「ドキュメントデフォルトをフォーマットすること」がPrinterオブジェクトのデフォルト値属性であるなら'八重奏アプリケーション/ストリーム'に設定されて、クライアントが「ドキュメント・フォーマット」属性を供給しないとき、Printerオブジェクトはドキュメント・フォーマットの自動感じをサポートするだけではなく、自動感じを適用するという結果に依存するでしょう。 クライアントがドキュメント・フォーマット値を供給するなら、Printerは自動感じアルゴリズムを信じるよりむしろ供給された属性を当てにしなければなりません。 まとめるために:
1. If the client does not supply a document format value, the
Printer MUST rely on its default value setting (which may be
'application/octet-stream' indicating an auto-sensing
mechanism).
2. If the client supplies a value other than 'application/octet-
stream', the client is supplying valid information about the
format of the document data and the Printer object MUST trust
the client supplied value more than the outcome of applying an
1. クライアントがドキュメント・フォーマット値を供給しないなら、Printerはデフォルト値設定(自動感受性機構を示す'八重奏アプリケーション/ストリーム'であるかもしれない)を当てにしなければなりません。 2. クライアントが'アプリケーション/八重奏ストリーム'を除いた値を供給するなら、クライアントがドキュメントデータの形式の有効な情報を提供していて、Printerオブジェクトは適用の結果よりクライアント供給値を信じなければなりません。
Hastings, et al. Standards Track [Page 88] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[88ページ]: モデルと意味論2000年9月
automatic format detection mechanism. For example, the client
may be requesting the printing of a PostScript file as a
'text/plain' document. The Printer object MUST print a text
representation of the PostScript commands rather than interpret
the stream of PostScript commands and print the result.
3. If the client supplies a value of 'application/octet-stream',
the client is indicating that the Printer object MUST use its
auto-sensing mechanism on the client supplied document data
whether auto-sensing is the Printer object's default or not.
自動形式検出メカニズム。 例えば、クライアントは'テキスト/明瞭な'ドキュメントとしてポストスクリプトファイルの印刷を要求しているかもしれません。 Printerオブジェクトは、ポストスクリプトコマンドのストリームを解釈するよりむしろポストスクリプトコマンドのテキスト表現を印刷して、結果を印刷しなければなりません。 3. クライアントが'八重奏アプリケーション/ストリーム'の値を供給するなら、クライアントは、Printerオブジェクトが自動感じがPrinterオブジェクトのデフォルトであるか否かに関係なく、クライアントの供給されたドキュメントデータで自動感受性機構を使用しなければならないのを示しています。
Note: Since the auto-sensing algorithm is probabilistic, if the
client requests both auto-sensing ("document-format" set to
'application/octet-stream') and true fidelity ("ipp-attribute-
fidelity" set to 'true'), the Printer object might not be able to
guarantee exactly what the end user intended (the auto-sensing
algorithm might mistake one document format for another), but it is
able to guarantee that its auto-sensing mechanism be used.
以下に注意してください。 自動感じアルゴリズムが確率的であるので、クライアントが自動感じ(「ドキュメント・フォーマット」は'八重奏アプリケーション/ストリーム'にセットした)と本当の信義('本当'への「ipp信義を結果と考えている」セット)の両方を要求するなら、Printerオブジェクトはまさにエンドユーザが意図したことを保証できないかもしれませんが(自動感じアルゴリズムは1つのドキュメント・フォーマットを別のものに間違えるかもしれません)、それは、自動感受性機構が使用されるのを保証できます。
When a Printer performs auto-sensing of a document in a submitted job, it is RECOMMENDED that the Printer indicate to the user that such auto-sensing has occurred and which document-format was auto- sensed by printing that information on the job's job-start-sheet.
Printerが提出された仕事における、ドキュメントの自動感じを実行して、Printerが、そのような自動感じが起こったのをユーザに示すのが、RECOMMENDEDであり、それのドキュメント・フォーマットは仕事の仕事のスタートシートの自動それを印刷することによって感じられた情報でした。
4.1.10 'octetString'
4.1.10 'octetString'
The 'octetString' attribute syntax is a sequence of octets encoded in a maximum of 1023 octets which is indicated in sub-section headers using the notation: octetString(MAX). This syntax type is used for opaque data.
'octetString'属性構文は最大1023の八重奏でコード化された八重奏の系列です(小区分ヘッダーで記法を使用することで示されます): octetString(最大限にします)。 この構文タイプは不明瞭なデータに使用されます。
4.1.11 'boolean'
4.1.11 '論理演算子'
The 'boolean' attribute syntax has only two values: 'true' and 'false'.
'論理演算子'属性構文には、2つの値しかありません: '本当に'と'虚偽'。
4.1.12 'integer'
4.1.12 '整数'
The 'integer' attribute syntax is an integer value that is in the range from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual attribute may specify the range constraint explicitly in sub-section headers if the range is different from the full range of possible integer values. For example: job-priority (integer(1:100)) for the "job-priority" attribute. However, the enforcement of that additional constraint is up to the IPP objects, not the protocol.
'整数'属性構文は2**31(MIN)から2**31--1(MAX)までの範囲にある整数値です。 範囲が最大限の範囲の可能な整数値と異なるなら、それぞれの個々の属性は小区分ヘッダーで明らかに範囲規制を指定するかもしれません。 例えば: 「ジョブ優先順位」属性のためのジョブ優先順位(整数(1:100))。 しかしながら、その追加規制の実施はプロトコルではなく、IPPオブジェクト次第です。
Hastings, et al. Standards Track [Page 89] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[89ページ]: モデルと意味論2000年9月
4.1.13 'rangeOfInteger'
4.1.13 'rangeOfInteger'
The 'rangeOfInteger' attribute syntax is an ordered pair of integers that defines an inclusive range of integer values. The first integer specifies the lower bound and the second specifies the upper bound. If a range constraint is specified in the header description for an attribute in this document whose attribute syntax is 'rangeOfInteger' (i.e., 'X:Y' indicating X as a minimum value and Y as a maximum value), then the constraint applies to both integers.
'rangeOfInteger'属性構文は包括的な範囲の整数値を定義する1順序対の整数です。 最初の整数は下界を指定します、そして、2番目は上限を指定します。 範囲規制が本書では属性構文が'rangeOfInteger'(最大値としてのすなわち、最小値としてXを示す'X: Y'とY)である属性のためのヘッダ記述で指定されるなら、規制は両方の整数に適用されます。
4.1.14 'dateTime'
4.1.14 'dateTime'
The 'dateTime' attribute syntax is a standard, fixed length, 11 octet representation of the "DateAndTime" syntax as defined in RFC 2579 [RFC2579]. RFC 2579 also identifies an 8 octet representation of a "DateAndTime" value, but IPP objects MUST use the 11 octet representation. A user interface will provide a mapping between protocol dateTime values and displayable user-friendly words or presentation values and phrases which are localized to the natural language and date format of the user, including time zone.
'dateTime'属性構文は標準の、そして、固定された長さ(RFC2579で定義される"DateAndTime"構文[RFC2579]の11八重奏表現)です。 また、RFC2579は"DateAndTime"価値の8八重奏表現を特定しますが、IPPオブジェクトは11八重奏表現を使用しなければなりません。 ユーザーインタフェースは、プロトコルdateTime値の間にマッピングを提供して、ユーザの自然言語と日付の形式にローカライズされるユーザフレンドリーな単語かプレゼンテーション値と句を「ディスプレイ-可能」するでしょう、時間帯を含んでいて。
4.1.15 'resolution'
4.1.15 '解決'
The 'resolution' attribute syntax specifies a two-dimensional resolution in the indicated units. It consists of 3 values: a cross feed direction resolution (positive integer value), a feed direction resolution (positive integer value), and a units value. The semantics of these three components are taken from the Printer MIB [RFC1759] suggested values. That is, the cross feed direction component resolution component is the same as the prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed direction component resolution component is the same as the prtMarkerAddressabilityFeedDir in the Printer MIB, and the units component is the same as the prtMarkerAddressabilityUnit object in the Printer MIB (namely, '3' indicates dots per inch and '4' indicates dots per centimeter). All three values MUST be present even if the first two values are the same. Example: '300', '600', '3' indicates a 300 dpi cross-feed direction resolution, a 600 dpi feed direction resolution, since a '3' indicates dots per inch (dpi).
'解決'属性構文は示されたユニットにおける二次元解決を指定します。 それは3つの値から成ります: 交差している給送方向解決(正の整数値)、給送方向解決(正の整数値)、およびユニット値。 Printer MIB[RFC1759]の提案された値からこれらの3つのコンポーネントの意味論を取ります。 prtMarkerAddressabilityUnitがPrinter MIBで反対するように(''すなわち、3は'1インチあたりのドットを示します、そして、4は'1センチメートルあたりのドットを示します)すなわち、交差している給送方向コンポーネント解決コンポーネントはPrinter MIBのprtMarkerAddressabilityXFeedDirオブジェクト、給送方向コンポーネント解決コンポーネントがPrinter MIBでprtMarkerAddressabilityFeedDirと同じであり、ユニットコンポーネントが同じであるのと同じです。 最初の2つの値が同じであっても、すべての3つの値が存在していなければなりません。 例: '300'、'600'、'3'は、300dpi交差している給送方向解決、'3'以来の600dpi給送方向決議がインチ(dpi)あたりのドットを示すのを示します。
4.1.16 '1setOf X'
4.1.16 '1setOf X'
The '1setOf X' attribute syntax is 1 or more values of attribute syntax type X. This syntax type is used for multi-valued attributes. The syntax type is called '1setOf' rather than just 'setOf' as a reminder that the set of values MUST NOT be empty (i.e., a set of
'1setOf X'属性構文は1であるか属性構文タイプX.This構文タイプの、より多くの値がマルチ評価された属性に使用されます。 構文タイプが値のセットが空であるはずがないということを思い出させるものとしてまさしく'setOf'よりむしろ'1setOf'と呼ばれる、(すなわち、セットされたa
Hastings, et al. Standards Track [Page 90] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[90ページ]: モデルと意味論2000年9月
size 0). Sets are normally unordered. However each attribute description of this type may specify that the values MUST be in a certain order for that attribute.
サイズ0)。 通常、セットは順不同のです。 しかしながら、このタイプのそれぞれの属性記述は、値がその属性のある注文にあるに違いないと指定するかもしれません。
4.2 Job Template Attributes
4.2 仕事のテンプレート属性
Job Template attributes describe job processing behavior. Support for Job Template attributes by a Printer object is OPTIONAL (see section 12.2.3 for a description of support for OPTIONAL attributes). Also, clients OPTIONALLY supply Job Template attributes in create requests.
仕事のTemplate属性はジョブ処理の振舞いについて説明します。 PrinterオブジェクトによるJob Template属性のサポートはOPTIONAL(OPTIONAL属性のサポートの記述に関してセクション12.2.3を見る)です。 また、OPTIONALLYが属性をJob Templateに供給するクライアントは要求を作成します。
Job Template attributes conform to the following rules. For each Job Template attribute called "xxx":
仕事のTemplate属性は以下の規則に従います。 各Job Templateに関しては、属性は、"xxx"と呼びました:
1. If the Printer object supports "xxx" then it MUST support both
a "xxx-default" attribute (unless there is a "No" in the table
below) and a "xxx-supported" attribute. If the Printer object
doesn't support "xxx", then it MUST support neither an "xxx-
default" attribute nor an "xxx-supported" attribute, and it
MUST treat an attribute "xxx" supplied by a client as
unsupported. An attribute "xxx" may be supported for some
document formats and not supported for other document formats.
For example, it is expected that a Printer object would only
support "orientation-requested" for some document formats (such
as 'text/plain' or 'text/html') but not others (such as
'application/postscript').
1. Printerオブジェクトが"xxx"をサポートするなら、それは、両方が「xxx-デフォルト」属性(「いいえ」が以下にテーブルにない場合)と「xxxによってサポートしている」属性であるとサポートしなければなりません。 Printerオブジェクトが"xxx"をサポートしないなら、「xxxデフォルト」属性も「xxxによってサポートしている」属性もサポートしてはいけません、そして、サポートされないとしてクライアントによって供給された属性"xxx"を扱わなければなりません。 属性"xxx"は、いくつかのドキュメント・フォーマットのためにサポートされて、他のドキュメント・フォーマットのためにサポートされないかもしれません。 例えば、Printerオブジェクトが他のもの('アプリケーション/追伸'などの)ではなく、何らかのドキュメントのために「オリエンテーションで要求された」形式('テキスト/平野'か'テキスト/html'などの)をサポートするだけであると予想されます。
2. "xxx" is OPTIONALLY supplied by the client in a create request.
If "xxx" is supplied, the client is indicating a desired job
processing behavior for this Job. When "xxx" is not supplied,
the client is indicating that the Printer object apply its
default job processing behavior at job processing time if the
document content does not contain an embedded instruction
indicating an xxx-related behavior.
2. "xxx"によるaでクライアントによって供給されたOPTIONALLYが要求を作成するということです。 "xxx"を供給するなら、クライアントはこのJobのために必要なジョブ処理の振舞いを示しています。 "xxx"が供給されないとき、クライアントは、ドキュメント内容がxxx関連の振舞いを示す埋め込まれた指示を含んでいないならPrinterオブジェクトがジョブ処理時にデフォルトジョブ処理の振舞いを適用するのを示しています。
Since an administrator MAY change the default value attribute
after a Job object has been submitted but before it has been
processed, the default value used by the Printer object at job
processing time may be different that the default value in
effect at job submission time.
以来、管理者はJobオブジェクトを提出しましたが、それが処理される前にジョブ処理時にPrinterオブジェクトによって使用されたデフォルト値が異なったかもしれない後に値が結果と考える事実上、デフォルトがジョブ依頼時に評価するデフォルトを変えるかもしれません。
3. The "xxx-supported" attribute is a Printer object attribute
that describes which job processing behaviors are supported by
that Printer object. A client can query the Printer object to
find out what xxx-related behaviors are supported by inspecting
the returned values of the "xxx-supported" attribute.
3. 「xxxによってサポートしている」属性はどのジョブ処理の振舞いがそのPrinterオブジェクトで後押しされているかを説明するPrinterオブジェクト属性です。 クライアントは、どんなxxx関連の振舞いが「xxxによってサポートしている」属性の戻り値を点検することによってサポートされるかを見つけるためにPrinterオブジェクトについて質問できます。
Hastings, et al. Standards Track [Page 91] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[91ページ]: モデルと意味論2000年9月
Note: The "xxx" in each "xxx-supported" attribute name is
singular, even though an "xxx-supported" attribute usually has
more than one value, such as "job-sheet-supported", unless the
"xxx" Job Template attribute is plural, such as "finishings" or
"sides". In such cases the "xxx-supported" attribute names
are: "finishings- supported" and "sides-supported".
以下に注意してください。 それぞれの「xxxによってサポートしている」属性名の"xxx"はまれです、「xxxによってサポートしている」属性に、1つ以上の値が通常ありますが、「支えられた仕事のシート」などのように、"xxx"Job Template属性が複数ならでない、「仕上げ」や「側」のように。 そのような場合「xxxによってサポートしている」属性名は以下の通りです。 「サポートされた仕上げ」で「側でサポートされる」。
4. The "xxx-default" default value attribute describes what will
be done at job processing time when no other job processing
information is supplied by the client (either explicitly as an
IPP attribute in the create request or implicitly as an
embedded instruction within the document data).
4. 「xxx-デフォルト」デフォルト値属性が、他のジョブ処理情報が全くクライアントによって提供されないジョブ処理時に何をするかを説明する、(どちらか、明らかである、中のIPP属性、埋め込まれた指示としてドキュメントデータの中でそれとなく要求を作成してください、)
If an application wishes to present an end user with a list of supported values from which to choose, the application SHOULD query the Printer object for its supported value attributes. The application SHOULD also query the default value attributes. If the application then limits selectable values to only those value that are supported, the application can guarantee that the values supplied by the client in the create request all fall within the set of supported values at the Printer. When querying the Printer, the client MAY enumerate each attribute by name in the Get-Printer- Attributes Request, or the client MAY just name the "job-template" group in order to get the complete set of supported attributes (both supported and default attributes).
アプリケーションが選ぶサポートしている値のリストをエンドユーザに与えたいなら、アプリケーションSHOULDはサポートしている値の属性のためにPrinterオブジェクトについて質問します。 また、アプリケーションSHOULDはデフォルト値属性について質問します。 それらだけへの選択可能な値が評価するサポートされる限界、アプリケーションがアプリケーションであるなら値がクライアントを中に供給したのを保証できる、秋中にサポートしている値のセットの中で要求をPrinterに作成してください。 Printerについて質問するとき、クライアントがGet-プリンタの名前で属性Requestを結果と考えてそれぞれを列挙するかもしれませんか、またはクライアントは、完全なセットのサポートしている属性(サポートされた両方と省略時の属性)を得るためにただ「仕事テンプレート」グループを命名するかもしれません。
The "finishings" attribute is an example of a Job Template attribute. It can take on a set of values such as 'staple', 'punch', and/or 'cover'. A client can query the Printer object for the "finishings- supported" attribute and the "finishings-default" attribute. The supported attribute contains a set of supported values. The default value attribute contains the finishing value(s) that will be used for a new Job if the client does not supply a "finishings" attribute in the create request and the document data does not contain any corresponding finishing instructions. If the client does supply the "finishings" attribute in the create request, the IPP object validates the value or values to make sure that they are a subset of the supported values identified in the Printer object's "finishings- supported" attribute. See section 3.1.7.
「仕上げ」属性はJob Template属性に関する例です。 それは1セットの'主要部分'、'パンチ'、そして/または、'カバー'などの値を呈することができます。 クライアントは「サポートされた仕上げ」属性と「仕上げデフォルト」属性のためにPrinterオブジェクトについて質問できます。 サポートしている属性は1セットのサポートしている値を含んでいます。 デフォルト値属性がクライアントが「仕上げ」属性を中に供給しないなら新しいJobに使用される仕上げの値を含んでいる、要求を作成してください。そうすれば、ドキュメントデータは少しの対応する仕上げの指示も含んでいません。 クライアントが「仕上げ」属性を中に供給する、要求を作成してください、そして、IPPオブジェクトは、それらがPrinterオブジェクトの「サポートされた仕上げ」属性で特定されたサポートしている値の部分集合であることを確実にするために値か値を有効にします。 セクション3.1.7を見てください。
The table below summarizes the names and relationships for all Job Template attributes. The first column of the table (labeled "Job Attribute") shows the name and syntax for each Job Template attribute in the Job object. These are the attributes that can optionally be supplied by the client in a create request. The last two columns (labeled "Printer: Default Value Attribute" and "Printer: Supported Values Attribute") show the name and syntax for each Job Template attribute in the Printer object (the default value attribute and the
以下のテーブルはすべてのJob Template属性のために名前と関係をまとめます。 テーブル(「仕事の属性」とラベルされる)の最初のコラムはJobオブジェクトのそれぞれのJob Template属性のために名前と構文を示しています。 これらによるクライアントがaで任意に供給できる属性が要求を作成するということです。 そして最後の2つのコラム(「プリンタ: デフォルト値属性」と「: サポートしている値が結果と考えるプリンタ」とラベルされる)がPrinterオブジェクトのそれぞれのJob Template属性のために名前と構文を示している、(デフォルト値属性。
Hastings, et al. Standards Track [Page 92] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[92ページ]: モデルと意味論2000年9月
supported values attribute). A "No" in the table means the Printer MUST NOT support the attribute (that is, the attribute is simply not applicable). For brevity in the table, the 'text' and 'name' entries do not show the maximum length for each attribute.
サポートしている値の属性) テーブルの「いいえ」は、Printerが属性をサポートしてはいけないことを(すなわち、属性は絶対に適切ではありません)意味します。 テーブルの簡潔さのために、エントリーという'テキスト'と'名前'は各属性のための最大の長さを示しません。
+===================+======================+======================+
| Job Attribute |Printer: Default Value| Printer: Supported |
| | Attribute | Values Attribute |
+===================+======================+======================+
| job-priority | job-priority-default |job-priority-supported|
| (integer 1:100) | (integer 1:100) |(integer 1:100) |
+-------------------+----------------------+----------------------+
| job-hold-until | job-hold-until- |job-hold-until- |
| (type3 keyword | | default | supported |
| name) | (type3 keyword | |(1setOf ( |
| | name) |type3 keyword | name))|
+-------------------+----------------------+----------------------+
| job-sheets | job-sheets-default |job-sheets-supported |
| (type3 keyword | | (type3 keyword | |(1setOf ( |
| name) | name) |type3 keyword | name))|
+-------------------+----------------------+----------------------+
|multiple-document- |multiple-document- |multiple-document- |
| handling | handling-default |handling-supported |
| (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|
+-------------------+----------------------+----------------------+
| copies | copies-default | copies-supported |
| (integer (1:MAX)) | (integer (1:MAX)) | (rangeOfInteger |
| | | (1:MAX)) |
+-------------------+----------------------+----------------------+
| finishings | finishings-default | finishings-supported |
|(1setOf type2 enum)|(1setOf type2 enum) |(1setOf type2 enum) |
+-------------------+----------------------+----------------------+
| page-ranges | No | page-ranges- |
| (1setOf | | supported (boolean) |
| rangeOfInteger | | |
| (1:MAX)) | | |
+-------------------+----------------------+----------------------+
| sides | sides-default | sides-supported |
| (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|
+-------------------+----------------------+----------------------+
| number-up | number-up-default | number-up-supported |
| (integer (1:MAX)) | (integer (1:MAX)) |(1setOf (integer |
| | | (1:MAX) | |
| | | rangeOfInteger |
| | | (1:MAX))) |
+===================+======================+======================+ | 仕事の属性|プリンタ: デフォルト値| プリンタ: サポートされます。| | | 属性| 属性を評価します。| +===================+======================+======================+ | ジョブ優先順位| 仕事の優先権デフォルト|優先権がサポートした仕事| | (整数1: 100) | (整数1: 100) |(整数1: 100) | +-------------------+----------------------+----------------------+ | 仕事の保持| 仕事保持、-、-|仕事保持、-、-| | (type3キーワード| | デフォルト| サポートされます|、|、名前) | (type3キーワード| | (1setOf(| | | 名前)| type3キーワード| 名前))| +-------------------+----------------------+----------------------+ | 仕事シート| 仕事のシートデフォルト|シートがサポートした仕事| | (type3キーワード| | (type3キーワード| | (1setOf(| | 名前)| 名前)| type3キーワード| 名前))| +-------------------+----------------------+----------------------+ |複数のドキュメント、-|複数のドキュメント、-|複数のドキュメント、-| | 取り扱い| 取り扱いデフォルト|取り扱いで、サポートされます。| | (type2キーワード) | (type2キーワード) |(1setOf type2キーワード)| +-------------------+----------------------+----------------------+ | コピー| コピーでデフォルトとしてください。| コピーで、サポートされます。| | (整数(1: 最大)) | (整数(1: 最大)) | (rangeOfInteger|、|、|、|、(1: 最大)) | +-------------------+----------------------+----------------------+ | 仕上げ| 仕上げデフォルト| 仕上げで、サポートされます。| |(1setOf type2 enum)|(1setOf type2 enum) |(1setOf type2 enum) | +-------------------+----------------------+----------------------+ | ページ範囲| いいえ| ページ範囲、-| | (1setOf| | (論理演算子)| | rangeOfIntegerであるとサポートされます|、|、|、|、(1: MAX)) | | | +-------------------+----------------------+----------------------+ | 側| 側でデフォルトとしてください。| 側で、サポートされます。| | (type2キーワード) | (type2キーワード) |(1setOf type2キーワード)| +-------------------+----------------------+----------------------+ | 上に数| デフォルトへの数| サポートされることへの数| | (整数(1: 最大)) | (整数(1: 最大)) |(1setOf、(整数| | | | (1: 最大)| | | | | rangeOfInteger|、|、|、|、(1: 最大)) |
Hastings, et al. Standards Track [Page 93] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[93ページ]: モデルと意味論2000年9月
+-------------------+----------------------+----------------------+
| orientation- |orientation-requested-|orientation-requested-|
| requested | default | supported |
| (type2 enum) | (type2 enum) | (1setOf type2 enum) |
+-------------------+----------------------+----------------------+
| media | media-default | media-supported |
| (type3 keyword | | (type3 keyword | |(1setOf ( |
| name) | name) |type3 keyword | name))|
| | | |
| | | media-ready |
| | |(1setOf ( |
| | |type3 keyword | name))|
+-------------------+----------------------+----------------------+
| printer-resolution| printer-resolution- | printer-resolution- |
| (resolution) | default | supported |
| | (resolution) |(1setOf resolution) |
+-------------------+----------------------+----------------------+
| print-quality | print-quality-default| print-quality- |
| (type2 enum) | (type2 enum) | supported |
| | |(1setOf type2 enum) |
+-------------------+----------------------+----------------------+
+-------------------+----------------------+----------------------+ | オリエンテーション|オリエンテーションで要求される、-|オリエンテーションで要求される、-| | 要求されています。| デフォルト| サポートされます。| | (type2 enum) | (type2 enum) | (1setOf type2 enum) | +-------------------+----------------------+----------------------+ | メディア| メディアデフォルト| メディアによってサポートされます。| | (type3キーワード| | (type3キーワード| | (1setOf(| | 名前)| 名前)| type3キーワード| 名前))| | | | | | | | メディア準備ができています。| | | |(1setOf(| | | | type3キーワード| 名前))| +-------------------+----------------------+----------------------+ | プリンタ解決| プリンタ解決、-| プリンタ解決、-| | (解決) | デフォルト| サポートされます。| | | (解決) |(1setOf解決) | +-------------------+----------------------+----------------------+ | 印刷品質| 上質のデフォルトを印刷してください。| 印刷品質、-| | (type2 enum) | (type2 enum) | サポートされます。| | | |(1setOf type2 enum) | +-------------------+----------------------+----------------------+
4.2.1 job-priority (integer(1:100))
4.2.1 ジョブ優先順位(整数(1:100))
This attribute specifies a priority for scheduling the Job. A higher value specifies a higher priority. The value 1 indicates the lowest possible priority. The value 100 indicates the highest possible priority. Among those jobs that are ready to print, a Printer MUST print all jobs with a priority value of n before printing those with a priority value of n-1 for all n.
この属性はJobの計画をするのに優先を指定します。 より高い値は、より高い優先度を指定します。 値1は可能な限り低い優先度を示します。 値100は可能な限り高い優先度を示します。 それらの印刷する準備ができている仕事の中では、すべてのnのためにn-1の優先順位の値があるそれらを印刷する前に、Printerはnの優先順位の値ですべての仕事を印刷しなければなりません。
If the Printer object supports this attribute, it MUST always support the full range from 1 to 100. No administrative restrictions are permitted. This way an end-user can always make full use of the entire range with any Printer object. If privileged jobs are implemented outside IPP/1.1, they MUST have priorities higher than 100, rather than restricting the range available to end-users.
Printerオブジェクトがこの属性をサポートするなら、それは、いつも最大限の範囲が1〜100であるとサポートしなければなりません。 管理上の制約は全く受入れられません。 このように、エンドユーザはどんなPrinterオブジェクトがある全体の範囲も完全にいつも利用できます。 特権がある仕事がIPP/1.1の外で実装されるなら、それらで、プライオリティはむしろ100よりエンドユーザにとって、利用可能な範囲を制限するより高くならなければなりません。
If the client does not supply this attribute and this attribute is supported by the Printer object, the Printer object MUST use the value of the Printer object's "job-priority-default" at job submission time (unlike most Job Template attributes that are used if necessary at job processing time).
クライアントがこの属性を供給しないで、この属性がPrinterオブジェクトによってサポートされるなら、Printerオブジェクトはジョブ依頼時(必要ならジョブ処理時に使用されるほとんどのJob Template属性と異なった)にPrinterオブジェクトの「仕事の優先権デフォルト」の値を使用しなければなりません。
The syntax for the "job-priority-supported" is also integer(1:100). This single integer value indicates the number of priority levels supported. The Printer object MUST take the value supplied by the client and map it to the closest integer in a sequence of n integers
また、「優先権がサポートした仕事」のための構文は整数(1:100)です。 このただ一つの整数値は、優先順位の数がサポートしたのを示します。 Printerオブジェクトは、クライアントによって供給された値を取って、次々にのn整数の最も近い整数にそれを写像しなければなりません。
Hastings, et al. Standards Track [Page 94] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[94ページ]: モデルと意味論2000年9月
values that are evenly distributed over the range from 1 to 100 using the formula:
1〜100までの範囲で均等に公式を使用することで分配される値:
roundToNearestInt((100x+50)/n)
roundToNearestInt(100x+50) /n)
where n is the value of "job-priority-supported" and x ranges from 0 through n-1.
nが「優先権がサポートした仕事」の値であり、xがn-1を通して0から変化するところ。
For example, if n=1 the sequence of values is 50; if n=2, the sequence of values is: 25 and 75; if n = 3, the sequence of values is: 17, 50 and 83; if n = 10, the sequence of values is: 5, 15, 25, 35, 45, 55, 65, 75, 85, and 95; if n = 100, the sequence of values is: 1, 2, 3, ... 100.
例えば、n=1であるなら、値の系列は50です。 n=2であるなら、値の系列は以下の通りです。 25と75。 n=3であるなら、値の系列は以下の通りです。 17、50、および83。 n=10であるなら、値の系列は以下の通りです。 5、15、25、35、45、55、65、75、85、および95。 n=100であるなら、値の系列は以下の通りです。 1, 2, 3, ... 100.
If the value of the Printer object's "job-priority-supported" is 10 and the client supplies values in the range 1 to 10, the Printer object maps them to 5, in the range 11 to 20, the Printer object maps them to 15, etc.
Printerオブジェクトの「優先権がサポートした仕事」の値が10であり、クライアントが範囲で1〜10に値を供給して、Printerオブジェクトが11〜20に範囲の5にそれらを写像して、Printerオブジェクトがそれらを15に写像するなら、などです。
4.2.2 job-hold-until (type3 keyword | name (MAX))
4.2.2、仕事の保持(type3キーワード| 名前(MAX))
This attribute specifies the named time period during which the Job MUST become a candidate for printing.
この属性はJobが印刷の候補にならなければならない命名された期間を指定します。
Standard keyword values for named time periods are:
命名された期間の標準のキーワード値は以下の通りです。
'no-hold': immediately, if there are not other reasons to hold the
job
'indefinite': - the job is held indefinitely, until a client
performs a Release-Job (section 3.3.6)
'day-time': during the day
'evening': evening
'night': night
'weekend': weekend
'second-shift': second-shift (after close of business)
'third-shift': third-shift (after midnight)
'成立しないでください': '無期'に仕事を持つ他の理由がすぐになければ: - クライアントがRelease-仕事(セクション3.3.6)の'昼間'を実行するまで、仕事は無期限に持たれています: 以下を'平等にする'1日の間 晩の'夜': 夜の'週末': 週末の'2番目のシフト': '3番目のシフト'を2番目に、移行させてください(業務の完了の後に): 3番目に移行してください。(0時過ぎ)
An administrator MUST associate allowable print times with a named time period (by means outside the scope of this IPP/1.1 document). An administrator is encouraged to pick names that suggest the type of time period. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation.
管理者は命名された期間(このIPP/1.1ドキュメントの範囲の外の手段による)に許容できる印刷時間を関連づけなければなりません。 管理者が期間のタイプを示す名前を選ぶよう奨励されます。 '名前'か'キーワード'属性構文を使用して、実装によって、管理者は加算値を定義するかもしれません。
If the value of this attribute specifies a time period that is in the future, the Printer SHOULD add the 'job-hold-until-specified' value to the job's "job-state-reasons" attribute, MUST move the job to the
この属性の値は将来Printer SHOULDが仕事の「仕事の州の理由」属性に'賃仕事の指定されるまでの保持'価値を高めるということであり、仕事を動かさなければならない期間を指定します。
Hastings, et al. Standards Track [Page 95] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[95ページ]: モデルと意味論2000年9月
'pending-held' state, and MUST NOT schedule the job for printing until the specified time-period arrives.
'未定に保持されること'は、指定された期間が来るまで印刷するための仕事を述べて、計画をしてはいけません。
When the specified time period arrives, the Printer MUST remove the 'job-hold-until-specified' value from the job's "job-state-reason" attribute, if present. If there are no other job state reasons that keep the job in the 'pending-held' state, the Printer MUST consider the job as a candidate for processing by moving the job to the 'pending' state.
指定された期間が来るとき、存在しているなら、Printerは仕事の「仕事の州の理由」属性から'指定されるまでの仕事の保持'値を取り除かなければなりません。 '未定に保持された'状態に仕事を保つ他の仕事の州の理由が全くなければ、Printerは、移行するのによる処理の候補としての仕事が仕事であると'未定'の状態と考えなければなりません。
If this job attribute value is the named value 'no-hold', or the specified time period has already started, the job MUST be a candidate for processing immediately.
この仕事の属性値が命名された値の'保持がありません'であるか指定された期間が既に始まったなら、すぐに、仕事は処理の候補であるに違いありません。
If the client does not supply this attribute and this attribute is supported by the Printer object, the Printer object MUST use the value of the Printer object's "job-hold-until-default" at job submission time (unlike most Job Template attributes that are used if necessary at job processing time).
クライアントがこの属性を供給しないで、この属性がPrinterオブジェクトによってサポートされるなら、Printerオブジェクトはジョブ依頼時(必要ならジョブ処理時に使用されるほとんどのJob Template属性と異なった)にPrinterオブジェクトの「デフォルトまでの仕事の保持」の値を使用しなければなりません。
4.2.3 job-sheets (type3 keyword | name(MAX))
4.2.3 仕事シート(type3キーワード| 名前(MAX))
This attribute determines which job start/end sheet(s), if any, MUST be printed with a job.
この属性は、仕事でもしあればどの仕事の始め/端壁板を印刷しなければならないかを決定します。
Standard keyword values are:
標準のキーワード値は以下の通りです。
'none': no job sheet is printed
'standard': one or more site specific standard job sheets are
printed, e.g. a single start sheet or both start and end sheet is
printed
'なにも': 仕事のシートは全く'標準'で印刷されません: 特定の標準のサイト仕事の1枚以上は印刷されます、そして、例えば、単一のスタートシートか両方が始動します、そして、端壁板は印刷されます。
An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation.
'名前'か'キーワード'属性構文を使用して、実装によって、管理者は加算値を定義するかもしれません。
The effect of this attribute on jobs with multiple documents MAY be affected by the "multiple-document-handling" job attribute (section 4.2.4), depending on the job sheet semantics.
「複数のドキュメント処理」仕事の属性(セクション4.2.4)で複数のドキュメントによる仕事へのこの属性の効果は影響を受けるかもしれません、仕事のシート意味論によって。
4.2.4 multiple-document-handling (type2 keyword)
4.2.4 複数のドキュメント処理(type2キーワード)
This attribute is relevant only if a job consists of two or more documents. This attribute MUST be supported with at least one value if the Printer supports multiple documents per job (see sections 3.2.4 and 3.3.1). The attribute controls finishing operations and the placement of one or more print-stream pages into impressions and onto media sheets. When the value of the "copies" attribute exceeds 1, it also controls the order in which the copies that result from
仕事が2通以上のドキュメントから成る場合にだけ、この属性は関連しています。 セクション3.2.4と3.3を見てください。Printerが複数の1仕事あたりのドキュメントを支えるなら少なくとも1つの値でこの属性をサポートしなければならない、(.1)。 1印刷ストリームページ以上の印象とメディアシートへの操作とプレースメントを終える属性コントロール。 いつ「コピー」属性の値が1を超えて、また、オーダーを制御するか、どれ、それが生じるコピー
Hastings, et al. Standards Track [Page 96] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[96ページ]: モデルと意味論2000年9月
processing the documents are produced. For the purposes of this explanations, if "a" represents an instance of document data, then the result of processing the data in document "a" is a sequence of media sheets represented by "a(*)".
処理して、ドキュメントは製作されます。 この説明の目的のために、“a"がドキュメントデータのインスタンスを表すなら、ドキュメント“a"のデータを処理するという結果は「(*)」によって表されたメディアシートの系列です。
Standard keyword values are:
標準のキーワード値は以下の通りです。
'single-document': If a Job object has multiple documents, say,
the document data is called a and b, then the result of
processing all the document data (a and then b) MUST be treated
as a single sequence of media sheets for finishing operations;
that is, finishing would be performed on the concatenation of
the sequences a(*),b(*). The Printer object MUST NOT force the
data in each document instance to be formatted onto a new
print-stream page, nor to start a new impression on a new media
sheet. If more than one copy is made, the ordering of the sets
of media sheets resulting from processing the document data
MUST be a(*), b(*), a(*), b(*), start on a new media sheet.
'separate-documents-uncollated-copies': If a Job object has
multiple documents, say, the document data is called a and b,
then the result of processing the data in each document
instance MUST be treated as a single sequence of media sheets
for finishing operations; that is, the sets a(*) and b(*) would
each be finished separately. The Printer object MUST force each
copy of the result of processing the data in a single document
to start on a new media sheet. If more than one copy is made,
the ordering of the sets of media sheets resulting from
processing the document data MUST be a(*), a(*), ..., b(*),
b(*) ... .
'separate-documents-collated-copies': If a Job object has multiple
documents, say, the document data is called a and b, then the
result of processing the data in each document instance MUST be
treated as a single sequence of media sheets for finishing
operations; that is, the sets a(*) and b(*) would each be
finished separately. The Printer object MUST force each copy of
the result of processing the data in a single document to start
on a new media sheet. If more than one copy is made, the
ordering of the sets of media sheets resulting from processing
the document data MUST be a(*), b(*), a(*), b(*), ... .
'single-document-new-sheet': Same as 'single-document', except
that the Printer object MUST ensure that the first impression
of each document instance in the job is placed on a new media
sheet. This value allows multiple documents to be stapled
together with a single staple where each document starts on a
new sheet.
'ただ一つのドキュメント': Jobオブジェクトに複数のドキュメントがあるなら、たとえば、ドキュメントデータはaとbと呼ばれます、次に、すべてのドキュメントデータ(aと次に、b)を処理するという結果を操作を終えるためのメディアシートのただ一つの系列として扱わなければなりません。 すなわち、仕上げは系列(*)、b(*)の連結に実行されるでしょう。 Printerオブジェクトは、それぞれのドキュメントインスタンスにおけるデータが新しい印刷ストリームページにフォーマットされて、新たな印象をニューメディアシートに始めるのを強制してはいけません。 ドキュメントデータを処理するのからのメディアシートのセットの注文が結果として生じて、コピー1部をする以上が(*)、bであるに違いない(*)なら、(*)、b(*)はニューメディアシートを始動します。 '別々のドキュメントはコピーを非照合しました': Jobオブジェクトに複数のドキュメントがあるなら、たとえば、ドキュメントデータはaとbと呼ばれます、次に、操作を終えるためのメディアシートのただ一つの系列としてそれぞれのドキュメントインスタンスにおけるデータを処理するという結果を扱わなければなりません。 すなわち、セット(*)とb(*)は別々にそれぞれ終わっているでしょう。 Printerオブジェクトによって、ただ一つのドキュメントのデータを処理するという結果の各コピーはやむを得ずニューメディアシートを始動しなければなりません。 ドキュメントデータを処理するのからのメディアシートのセットの注文が結果として生じて、コピー1部をする以上が(*)であるに違いないなら、(*)です。, b(*)、b(*)… . '別々のドキュメントはコピーを照合しました': Jobオブジェクトに複数のドキュメントがあるなら、たとえば、ドキュメントデータはaとbと呼ばれます、次に、操作を終えるためのメディアシートのただ一つの系列としてそれぞれのドキュメントインスタンスにおけるデータを処理するという結果を扱わなければなりません。 すなわち、セット(*)とb(*)は別々にそれぞれ終わっているでしょう。 Printerオブジェクトによって、ただ一つのドキュメントのデータを処理するという結果の各コピーはやむを得ずニューメディアシートを始動しなければなりません。 処理からのメディアシートのセットの注文が結果として生じて、コピー1部をする以上なら、ドキュメントデータは(*)であるに違いありません、b(*)、(*)、b(*)… . '単一のドキュメント新しいシート': 'ただ一つのドキュメント'と同じです、Printerオブジェクトが確実にしなければならないのを除いて、仕事における、それぞれのドキュメントインスタンスの第一印象がニューメディアシートに置かれるのを確実にしてください。 この値は、複数のドキュメントが各ドキュメントが新しいシートを始動する単一の主要部分と共にとめられるのを許容します。
Hastings, et al. Standards Track [Page 97] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[97ページ]: モデルと意味論2000年9月
The 'single-document' value is the same as 'separate-documents- collated-copies' with respect to ordering of print-stream pages, but not media sheet generation, since 'single-document' will put the first page of the next document on the back side of a sheet if an odd number of pages have been produced so far for the job, while 'separate-documents-collated- copies' always forces the next document or document copy on to a new sheet. In addition, if the "finishings" attribute specifies 'staple', then with 'single-document', documents a and b are stapled together as a single document with no regard to new sheets, with 'single-document-new-sheet', documents a and b are stapled together as a single document, but document b starts on a new sheet, but with 'separate-documents-uncollated-copies' and 'separate-documents-collated-copies', documents a and b are stapled separately.
'ただ一つのドキュメント'値は今までのところ仕事のために奇数ページを生産してあると'ただ一つのドキュメント'がシートの裏に次のドキュメントの最初のページを置くので'別々のドキュメントで照合されたコピー'である間メディアシート世代ではなく、印刷ストリームページを注文することに関する'別々のドキュメント照合されたコピー'がいつも次のドキュメントかドキュメントコピーを新しいシートに強制するのと同じです。 さらに、「仕上げ」属性が'主要部分'を指定するなら、新しいシートへの尊敬のないただ一つのドキュメント、'単一のドキュメント新しいシート'でドキュメントaとbがただ一つのドキュメントとして一緒にとめられますが、ドキュメントbが新しいシートを始動するとき、'ただ一つのドキュメント'でドキュメントaとbは一緒にとめられますが、'別々のドキュメントはコピーを非照合し'て'別々のドキュメントはコピーを照合したこと'で、ドキュメントaとbは別々にとめられます。
Note: None of these values provide means to produce uncollated sheets within a document, i.e., where multiple copies of sheet n are produced before sheet n+1 of the same document.
以下に注意してください。 これらの値のいずれもシートnの複本が同じドキュメントのシートn+1の前に生産されるところにすなわちドキュメントの中に非照合されたシートを製作する手段を提供しません。
The relationship of this attribute and the other attributes that control document processing is described in section 15.3.
文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
4.2.5 copies (integer(1:MAX))
4.2.5 コピー(整数(1: 最大))
This attribute specifies the number of copies to be printed.
この属性は、印刷されるためにコピーの数を指定します。
On many devices the supported number of collated copies will be limited by the number of physical output bins on the device, and may be different from the number of uncollated copies which can be supported.
多くのデバイスで、照合されたコピーのサポートしている数は、デバイスで物的生産量容器の数によって限られて、支えることができる非照合されたコピーの数と異なっているかもしれません。
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
以下に注意してください。 「複数のドキュメント処理」仕事の属性(セクション4.2.4)によって複数のドキュメントによる仕事へのこの属性の効果は制御されます、そして、文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
4.2.6 finishings (1setOf type2 enum)
4.2.6 仕上げ(1setOf type2 enum)
This attribute identifies the finishing operations that the Printer uses for each copy of each printed document in the Job. For Jobs with multiple documents, the "multiple-document-handling" attribute determines what constitutes a "copy" for purposes of finishing.
この属性はPrinterがJobのそれぞれの印刷された記録の各コピーに使用する仕上げの操作を特定します。 複数のドキュメントをもっているジョブスに関しては、「複数のドキュメント処理」属性は、何が仕上げの目的のために「コピー」を構成するかを決定します。
Hastings, et al. Standards Track [Page 98] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[98ページ]: モデルと意味論2000年9月
Standard enum values are:
標準のenum値は以下の通りです。
Value Symbolic Name and Description
英字名と記述を評価してください。
'3' 'none': Perform no finishing
'4' 'staple': Bind the document(s) with one or more staples. The
exact number and placement of the staples is site-
defined.
'5' 'punch': This value indicates that holes are required in the
finished document. The exact number and placement of the
holes is site-defined The punch specification MAY be
satisfied (in a site- and implementation-specific manner)
either by drilling/punching, or by substituting pre-
drilled media.
'6' 'cover': This value is specified when it is desired to select
a non-printed (or pre-printed) cover for the document.
This does not supplant the specification of a printed
cover (on cover stock medium) by the document itself.
'7' 'bind': This value indicates that a binding is to be applied
to the document; the type and placement of the binding is
site-defined.
'8' 'saddle-stitch': Bind the document(s) with one or more
staples (wire stitches) along the middle fold. The exact
number and placement of the staples and the middle fold
is implementation and/or site-defined.
'9' 'edge-stitch': Bind the document(s) with one or more staples
(wire stitches) along one edge. The exact number and
placement of the staples is implementation and/or site-
defined.
'10'-'19' reserved for future generic finishing enum values.
'3''なにも': どんな仕上げの'4''主要部分'も実行しないでください: 1個以上の主要部分でドキュメントを縛ってください。 主要部分のはっきりした数とプレースメントは定義されたサイトです。 '5''パンチしてください': この値は、穴が完成ドキュメントで必要であることを示します。 穴のはっきりした数とプレースメントは、仕様が穴をあけることによって満たされているか(サイトと実装特有の方法で)、またはパンチしているかもしれないパンチをサイトで定義するか、またはあらかじめ穴をあけられたメディアを代入することです。 '6''カバー': ドキュメントのために非印刷された(または、前印刷される)カバーを選択するのが必要であると、この値は指定されています。 これはドキュメント自体で印刷されたカバー(カバーストック媒体の)の仕様に取って代わりません。 '7''付いてください': この値は、結合がドキュメントに適用されることであることを示します。 結合のタイプとプレースメントはサイトで定義されています。 '8''サドルステッチ': 中くらいの折り目に沿って1個以上の主要部分(ワイヤステッチ)でドキュメントを縛ってください。 主要部分と中くらいの折り目のはっきりした数とプレースメントは、実装、そして/または、サイトで定義されています。 '9''縁ステッチ': 1つの縁に沿って1個以上の主要部分(ワイヤステッチ)がある状態で、ドキュメントを縛ってください。 主要部分のはっきりした数とプレースメントは、実装、そして/または、定義されたサイトです。 '10年'--19年、'将来のジェネリック仕上げのenum値のために、予約されます。
The following values are more specific; they indicate a corner or an edge as if the document were a portrait document (see below):
以下の値は、より特定です。 彼らはまるでドキュメントが肖像ドキュメントであるかのように角か縁を示します(以下を見てください):
'20' 'staple-top-left': Bind the document(s) with one or more
staples in the top left corner.
'21' 'staple-bottom-left': Bind the document(s) with one or more
staples in the bottom left corner.
'22' 'staple-top-right': Bind the document(s) with one or more
staples in the top right corner.
'23' 'staple-bottom-right': Bind the document(s) with one or more
staples in the bottom right corner.
'24' 'edge-stitch-left': Bind the document(s) with one or more
staples (wire stitches) along the left edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'20年''主要部分左上': 1個以上の主要部分が左上隅にある状態で、ドキュメントを縛ってください。 '21年''あと主要部分の下部': 1でドキュメントを縛ってください。さもないと、以上は下部で左隅をとめます。 '22年''主要部分右上': 1個以上の主要部分が先頭の右隅にある状態で、ドキュメントを縛ってください。 '23年''主要部分の下部権利': 1でドキュメントを縛ってください。さもないと、以上は下部で右隅をとめます。 '24年''あと縁のステッチ': 左の縁に沿って1個以上の主要部分(ワイヤステッチ)がある状態で、ドキュメントを縛ってください。 主要部分のはっきりした数とプレースメントは、実装、そして/または、サイトで定義されています。
Hastings, et al. Standards Track [Page 99] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[99ページ]: モデルと意味論2000年9月
'25' 'edge-stitch-top': Bind the document(s) with one or more
staples (wire stitches) along the top edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'26' 'edge-stitch-right': Bind the document(s) with one or more
staples (wire stitches) along the right edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'27' 'edge-stitch-bottom': Bind the document(s) with one or more
staples (wire stitches) along the bottom edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'28' 'staple-dual-left': Bind the document(s) with two staples
(wire stitches) along the left edge assuming a portrait
document (see above).
'29' 'staple-dual-top': Bind the document(s) with two staples
(wire stitches) along the top edge assuming a portrait
document (see above).
'30' 'staple-dual-right': Bind the document(s) with two staples
(wire stitches) along the right edge assuming a portrait
document (see above).
'31' 'staple-dual-bottom': Bind the document(s) with two staples
(wire stitches) along the bottom edge assuming a portrait
document (see above).
'25年''縁のステッチ先端': 先頭の縁に沿って1個以上の主要部分(ワイヤステッチ)がある状態で、ドキュメントを縛ってください。 主要部分のはっきりした数とプレースメントは、実装、そして/または、サイトで定義されています。 '26年''縁のステッチ権利': 正しい縁に沿って1個以上の主要部分(ワイヤステッチ)がある状態で、ドキュメントを縛ってください。 主要部分のはっきりした数とプレースメントは、実装、そして/または、サイトで定義されています。 '27年''縁のステッチ下部': ボトムエッジに沿って1個以上の主要部分(ワイヤステッチ)がある状態で、ドキュメントを縛ってください。 主要部分のはっきりした数とプレースメントは、実装、そして/または、サイトで定義されています。 '28年''主要部分の二元的な左': 肖像ドキュメントを仮定して、左の縁に沿って2個の主要部分(ワイヤステッチ)でドキュメントを縛ってください(上を見てください)。 '29年''主要部分の二元的な先端': 肖像ドキュメントを仮定して、先頭の縁に沿って2個の主要部分(ワイヤステッチ)でドキュメントを縛ってください(上を見てください)。 '30年''主要部分の二元的な権利': 肖像ドキュメントを仮定して、正しい縁に沿って2個の主要部分(ワイヤステッチ)でドキュメントを縛ってください(上を見てください)。 '31年''主要部分の二元的な下部': 肖像ドキュメントを仮定して、ボトムエッジに沿って2個の主要部分(ワイヤステッチ)でドキュメントを縛ってください(上を見てください)。
The 'staple-xxx' values are specified with respect to the document as if the document were a portrait document. If the document is actually a landscape or a reverse-landscape document, the client supplies the appropriate transformed value. For example, to position a staple in the upper left hand corner of a landscape document when held for reading, the client supplies the 'staple-bottom-left' value (since landscape is defined as a +90 degree rotation of the image with respect to the media from portrait, i.e., anti-clockwise). On the other hand, to position a staple in the upper left hand corner of a reverse-landscape document when held for reading, the client supplies the 'staple-top-right' value (since reverse-landscape is defined as a -90 degree rotation of the image with respect to the media from portrait, i.e., clockwise).
'主要部分-xxx'値はまるでドキュメントが肖像ドキュメントであるかのようにドキュメントに関して指定されます。 ドキュメントが実際に風景か逆風景ドキュメントであるなら、クライアントは適切な変成している値を供給します。 例えば、風景ドキュメントの左上の手の角に主要部分を置くために、読書するために保持されると、クライアントは'あと主要部分の下部'値を供給します(すなわち、風景がメディアに関して肖像からイメージの+90度合い回転と反時計回りに定義されるので)。 他方では、逆風景ドキュメントの左上の手の角に主要部分を置くために、読書するために保持されると、クライアントは'主要部分右上'値を供給します(すなわち、逆風景がメディアに関して肖像からイメージの-90度合い回転と時計回りで定義されるので)。
The angle (vertical, horizontal, angled) of each staple with respect to the document depends on the implementation which may in turn depend on the value of the attribute.
ドキュメントに関するそれぞれの主要部分の角度(垂直で、水平で、傾けられた)は順番に属性の値に依存するかもしれない実装に依存します。
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
以下に注意してください。 「複数のドキュメント処理」仕事の属性(セクション4.2.4)によって複数のドキュメントによる仕事へのこの属性の効果は制御されます、そして、文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
Hastings, et al. Standards Track [Page 100] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[100ページ]: モデルと意味論2000年9月
If the client supplies a value of 'none' along with any other combination of values, it is the same as if only that other combination of values had been supplied (that is the 'none' value has no effect).
クライアントが値のいかなる他の組み合わせに伴う'なにも'の値も供給するなら、まるで値のその他の組み合わせだけを供給したかのように(すなわち、'なにも'値は効き目がありません)同じです。
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX))
4.2.7 ページ範囲(1setOf rangeOfInteger(1: 最大))
This attribute identifies the range(s) of print-stream pages that the Printer object uses for each copy of each document which are to be printed. Nothing is printed for any pages identified that do not exist in the document(s). Ranges MUST be in ascending order, for example: 1-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling Printer object can process the job in a single pass. If the ranges are not ascending or are overlapping, the IPP object MUST reject the request and return the 'client-error-bad-request' status code. The attribute is associated with print-stream pages not application- numbered pages (for example, the page numbers found in the headers and or footers for certain word processing applications).
この属性は印刷されることであるそれぞれの各コピーへのPrinterオブジェクト用途が記録する印刷ストリームページの範囲を特定します。 何もドキュメントに存在しない特定されたどんなページのためにも印刷されません。 範囲は昇順に、そして、例えば以下の通りであるに違いありません。 1-3と、5-7と、15-19、NOTオーバラップ、a非スプールPrinterが単一のパスで仕事を処理できるのを反対させるそうはそうしなければなりません。 範囲が昇っていないか、または重なっているなら、IPPオブジェクトは、要求を拒絶して、'クライアントの誤りの悪い要求'ステータスコードを返さなければなりません。 または、そして、属性がアプリケーション番号付きページではなく、印刷ストリームページに関連している、(例えば、ページ番号がヘッダーで見つけた、ある文書処理アプリケーションのためのフッター)
For Jobs with multiple documents, the "multiple-document-handling" attribute determines what constitutes a "copy" for purposes of the specified page range(s). When "multiple-document-handling" is 'single-document', the Printer object MUST apply each supplied page range once to the concatenation of the print-stream pages. For example, if there are 8 documents of 10 pages each, the page-range '41:60' prints the pages in the 5th and 6th documents as a single document and none of the pages of the other documents are printed. When "multiple-document- handling" is 'separate-documents- uncollated-copies' or 'separate-documents-collated-copies', the Printer object MUST apply each supplied page range repeatedly to each document copy. For the same job, the page-range '1:3, 10:10' would print the first 3 pages and the 10th page of each of the 8 documents in the Job, as 8 separate documents.
複数のドキュメントをもっているジョブスに関しては、「複数のドキュメント処理」属性は、何が指定されたページの目的のための「コピー」範囲を構成するかを決定します。 「複数のドキュメント処理」が'ただ一つのドキュメント'であるときに、Printerオブジェクトは一度それぞれの供給されたページ範囲を印刷ストリームページの連結に適用しなければなりません。 '例えば、ページ範囲41年それぞれ10ページの8通のドキュメントがあれば: 60 '5番目と6番目のページがただ一つのドキュメントとして記録する印刷と他のドキュメントのページのいずれも印刷されません。 「複数のドキュメントの取り扱い」であることが、'別々のドキュメント非照合されたコピー'であるか'別々のドキュメントはコピーを照合した'とき、Printerオブジェクトが繰り返してそれぞれの供給されたページ範囲をそれぞれのドキュメントコピーに適用しなければなりません。 同じ仕事、'1:3、10:10'がそうするページ範囲に、Jobのそれぞれの8通のドキュメントの最初の3ページと第10ページを印刷してください、8がドキュメントを切り離すとき。
In most cases, the exact pages to be printed will be generated by a device driver and this attribute would not be required. However, when printing an archived document which has already been formatted, the end user may elect to print just a subset of the pages contained in the document. In this case, if page-range = n.m is specified, the first page to be printed will be page n. All subsequent pages of the document will be printed through and including page m.
多くの場合、印刷されるべき正確なページはデバイスドライバで生成されるでしょう、そして、この属性は必要でないでしょう。 しかしながら、既にフォーマットされた格納されたドキュメントを印刷するとき、エンドユーザは、まさしくドキュメントに含まれたページの部分集合を印刷するのを選ぶかもしれません。 この場合、ページ範囲=n.mが指定されるなら、印刷されるべき最初のページはnになページるでしょう。 ドキュメントのすべての次のページは、ページmをを通して印刷されて、含むでしょう。
"page-ranges-supported" is a boolean value indicating whether or not the printer is capable of supporting the printing of page ranges. This capability may differ from one PDL to another. There is no "page-ranges-default" attribute. If the "page-ranges" attribute is not supplied by the client, all pages of the document will be printed.
「範囲がサポートしたページ」はプリンタがページの印刷を支えることができるかどうかが及ぶのを示すブール値です。 この能力は1PDLから別のPDLまで異なるかもしれません。 「ページ範囲はデフォルトとする」という属性が全くありません。 「ページ範囲」属性がクライアントによって供給されないと、ドキュメントのすべてのページが印刷されるでしょう。
Hastings, et al. Standards Track [Page 101] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[101ページ]: モデルと意味論2000年9月
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
以下に注意してください。 「複数のドキュメント処理」仕事の属性(セクション4.2.4)によって複数のドキュメントによる仕事へのこの属性の効果は制御されます、そして、文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
4.2.8 sides (type2 keyword)
4.2.8 側(type2キーワード)
This attribute specifies how print-stream pages are to be imposed upon the sides of an instance of a selected medium, i.e., an impression.
この属性は選択された媒体(すなわち、印象)のインスタンスの側に課される印刷ストリームページがことである方法を指定します。
The standard keyword values are:
標準のキーワード値は以下の通りです。
'one-sided': imposes each consecutive print-stream page upon the
same side of consecutive media sheets.
'two-sided-long-edge': imposes each consecutive pair of print-
stream pages upon front and back sides of consecutive media
sheets, such that the orientation of each pair of print-stream
pages on the medium would be correct for the reader as if for
binding on the long edge. This imposition is sometimes called
'duplex' or 'head-to-head'.
'two-sided-short-edge': imposes each consecutive pair of print-
stream pages upon front and back sides of consecutive media
sheets, such that the orientation of each pair of print-stream
pages on the medium would be correct for the reader as if for
binding on the short edge. This imposition is sometimes called
'tumble' or 'head-to-toe'.
'two-sided-long-edge', 'two-sided-short-edge',
'tumble', and 'duplex' all work the same for portrait or
landscape. However
'head-to-toe' is
'tumble' in portrait but 'duplex' in landscape. 'head-to-head'
also switches between 'duplex' and 'tumble' when using portrait
and landscape modes.
'一方的': それぞれの連続した印刷ストリームページ単位で連続したメディアシートの同じ側面に課します。 '二面の長い縁': 読者にとって、媒体の上のそれぞれの組の印刷ストリームページのオリエンテーションが長い縁で付くように正しいように、連続したメディアシートの前の、そして、逆側面にそれぞれの連続した組の印刷ストリームページを課します。 この賦課は時々'デュプレックス'か'接戦'と呼ばれます。 '二面の短い縁': 読者にとって、媒体の上のそれぞれの組の印刷ストリームページのオリエンテーションが短い縁で付くように正しいように、連続したメディアシートの前の、そして、逆側面にそれぞれの連続した組の印刷ストリームページを課します。 この賦課は、時々'転倒'と呼ばれて、'全身です'。 '二面の長い縁'、'二面の短い縁'、'転倒'、および'デュプレックス'は同じように肖像か風景にすべて取り組みます。 しかしながら、'全身'であることは、肖像にもかかわらず、'デュプレックス'で風景の中の'転倒'です。 また、肖像と風景モードを使用するとき、'接戦'は'デュプレックス'と'転倒'を切り換えます。
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
以下に注意してください。 「複数のドキュメント処理」仕事の属性(セクション4.2.4)によって複数のドキュメントによる仕事へのこの属性の効果は制御されます、そして、文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
4.2.9 number-up (integer(1:MAX))
4.2.9 上に数(整数(1: 最大))
This attribute specifies the number of print-stream pages to impose upon a single side of an instance of a selected medium. For example, if the value is:
この属性は、選択された媒体のインスタンスただ一つ側にでしゃばるために印刷ストリームページの数を指定します。 値が例えばそうなら:
Hastings, et al. Standards Track [Page 102] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[102ページ]: モデルと意味論2000年9月
Value Description
値の記述
'1' the Printer MUST place one print-stream page on a single side
of an instance of the selected medium (MAY add some sort
of translation, scaling, or rotation).
'2' the Printer MUST place two print-stream pages on a single side
of an instance of the selected medium (MAY add some sort
of translation, scaling, or rotation).
'4' the Printer MUST place four print-stream pages on a single
side of an instance of the selected medium (MAY add some
sort of translation, scaling, or rotation).
'1'Printerは選択された媒体(ある種の翻訳、スケーリング、または回転を加えるかもしれない)のインスタンスただ一つ側に1印刷ストリームページを置かなければなりません。 '2'Printerは選択された媒体(ある種の翻訳、スケーリング、または回転を加えるかもしれない)のインスタンスただ一つ側に2印刷ストリームページを置かなければなりません。 '4'Printerは選択された媒体(ある種の翻訳、スケーリング、または回転を加えるかもしれない)のインスタンスただ一つ側に4印刷ストリームページを置かなければなりません。
This attribute primarily controls the translation, scaling and rotation of print-stream pages.
この属性は主として印刷ストリームページの翻訳、スケーリング、および回転を制御します。
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
以下に注意してください。 「複数のドキュメント処理」仕事の属性(セクション4.2.4)によって複数のドキュメントによる仕事へのこの属性の効果は制御されます、そして、文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
4.2.10 orientation-requested (type2 enum)
4.2.10 オリエンテーションで、要求されています。(type2 enum)
This attribute indicates the desired orientation for printed print- stream pages; it does not describe the orientation of the client- supplied print-stream pages.
この属性は印刷された印刷ストリームページのために必要なオリエンテーションを示します。 それはクライアント供給された印刷ストリームページのオリエンテーションを説明しません。
For some document formats (such as 'application/postscript'), the desired orientation of the print-stream pages is specified within the document data. This information is generated by a device driver prior to the submission of the print job. Other document formats (such as 'text/plain') do not include the notion of desired orientation within the document data. In the latter case it is possible for the Printer object to bind the desired orientation to the document data after it has been submitted. It is expected that a Printer object would only support "orientations-requested" for some document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript'). This is no different than any other Job Template attribute since section 4.2, item 1, points out that a Printer object may support or not support any Job Template attribute based on the document format supplied by the client. However, a special mention is made here since it is very likely that a Printer object will support "orientation-requested" for only a subset of the supported document formats.
いくつかのドキュメント・フォーマット('アプリケーション/追伸'などの)として、印刷ストリームページの必要なオリエンテーションはドキュメントデータの中で指定されます。 この情報は印刷仕事の提案の前にデバイスドライバによって生成されます。 他のドキュメント・フォーマット('テキスト/平野'などの)はドキュメントデータの中に必要なオリエンテーションの概念を含んでいません。 後者の場合では、それを提出した後にPrinterオブジェクトがドキュメントデータに必要なオリエンテーションを縛るのは、可能です。 Printerオブジェクトが、何らかのドキュメントのために「オリエンテーションで要求された」形式が他のもの(例えば、'アプリケーション/追伸')ではなく、(例えば、'テキスト/平野'か'テキスト/html')であるとサポートするだけであると予想されます。 これはドキュメント・フォーマットに基づいたどんなJob Template属性もクライアントから供給したセクション4.2(項目1)が、Printerが反対すると指摘するのでいかなる他のJob Template属性もサポートか否かに関係なく、そうするかもしれないより異なったサポートではありません。 しかしながら、Printerオブジェクトがサポートしているドキュメントの部分集合だけのために「オリエンテーションで要求された」形式を非常にサポートしそうであるので、ここで特記をします。
Hastings, et al. Standards Track [Page 103] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[103ページ]: モデルと意味論2000年9月
Standard enum values are:
標準のenum値は以下の通りです。
Value Symbolic Name and Description
英字名と記述を評価してください。
'3' 'portrait': The content will be imaged across the short edge
of the medium.
'4' 'landscape': The content will be imaged across the long edge
of the medium. Landscape is defined to be a rotation of
the print-stream page to be imaged by +90 degrees with
respect to the medium (i.e. anti-clockwise) from the
portrait orientation. Note: The +90 direction was
chosen because simple finishing on the long edge is the
same edge whether portrait or landscape
'5' 'reverse-landscape': The content will be imaged across the
long edge of the medium. Reverse-landscape is defined to
be a rotation of the print-stream page to be imaged by -
90 degrees with respect to the medium (i.e. clockwise)
from the portrait orientation. Note: The 'reverse-
landscape' value was added because some applications
rotate landscape -90 degrees from portrait, rather than
+90 degrees.
'6' 'reverse-portrait': The content will be imaged across the
short edge of the medium. Reverse-portrait is defined to
be a rotation of the print-stream page to be imaged by
180 degrees with respect to the medium from the portrait
orientation. Note: The 'reverse-portrait' value was
added for use with the "finishings" attribute in cases
where the opposite edge is desired for finishing a
portrait document on simple finishing devices that have
only one finishing position. Thus a 'text'/plain'
portrait document can be stapled "on the right" by a
simple finishing device as is common use with some middle
eastern languages such as Hebrew.
'3''肖像': 内容は媒体の短い縁の向こう側に像を描かれるでしょう。 '4''風景': 内容は媒体の長い縁の向こう側に像を描かれるでしょう。 風景は、+90の度合いによって縦方向からの媒体(すなわち、反時計回りの)に関して像を描かれるべき印刷ストリームページの回転になるように定義されます。 以下に注意してください。 長い縁における簡単な仕上げが肖像か風景'5''逆風景'であることにかかわらず同じ縁であるので、+90方向は選ばれました: 内容は媒体の長い縁の向こう側に像を描かれるでしょう。 逆風景は像を描かれる印刷ストリームページの回転になるように定義されます--縦方向からの媒体(すなわち、時計回りの)に関する90の度合い。 以下に注意してください。 アプリケーションが回転させる或るものが+90の度合いよりむしろ肖像からの-90の度合いを美化するので、'逆風景'価値は高められました。 '6''逆肖像': 内容は媒体の短い縁の向こう側に像を描かれるでしょう。 逆肖像は、180の度合いによって縦方向からの媒体に関して像を描かれるべき印刷ストリームページの回転になるように定義されます。 以下に注意してください。 '逆肖像'価値は使用のために反対の縁が1つしか持っていない簡単な仕上装置の上の肖像ドキュメントが位置を終え終えるために望まれている場合における「仕上げ」属性で高められました。 'その結果、簡単な仕上装置はヘブライ語などの中央東いくつかの言語による一般の使用のように「権利」で'テキスト'/明瞭な'肖像ドキュメントをとめることができます。
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
以下に注意してください。 「複数のドキュメント処理」仕事の属性(セクション4.2.4)によって複数のドキュメントによる仕事へのこの属性の効果は制御されます、そして、文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
4.2.11 media (type3 keyword | name(MAX))
4.2.11 メディア(type3キーワード| 名前(MAX))
This attribute identifies the medium that the Printer uses for all impressions of the Job.
この属性はPrinterがJobのすべての印象に使用する媒体を特定します。
The values for "media" include medium-names, medium-sizes, input- trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this
「メディア」のための値が中型の名前、中型、入力トレー、および電子申込書を含んでいるので、1つの属性がメディアを指定します。 Printerオブジェクトがこの値として中型の名前をサポートするなら
Hastings, et al. Standards Track [Page 104] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[104ページ]: モデルと意味論2000年9月
attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input- trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer MUST merge with the document data as its prints each page.
属性、そのような中型の名前はそれとなく指定された媒体を含む入力トレーを選択します。 Printerオブジェクトがこの属性の値として中くらいのサイズをサポートするなら、そのような中くらいのサイズはそれとなく順番にそれとなく指定されたサイズで媒体を含む入力トレーを選択する中型の名前を選択します。 この属性の値、そのような入力トレーがそれとなく媒体を選ぶときPrinterオブジェクトが入力トレーを支えるなら、時にそれはその入力トレーにおける仕事の印刷です。 本件は手動の給送の入力トレーを含んでいます。 Printerオブジェクトがこの属性の値として電子申込書をサポートするなら、そのような電子申込書はそれとなく順番にそれとなく電子申込書によって指定された媒体を含む入力トレーを選択する中型の名前を選択します。 また、電子申込書はそれとなく、Printerが各ページ単位で印刷としてドキュメントデータに合併しなければならないイメージを選択します。
Standard keyword values are taken from ISO DPA [ISO10175], the Printer MIB [RFC1759], and ASME-Y14.1M [ASME-Y14.1M] and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation.
標準のキーワード値は、ISO DPA[ISO10175]、Printer MIB[RFC1759]、およびASME-Y14.1M[ASME-Y14.1M]から取られて、セクション14で記載されています。 '名前'か'キーワード'属性構文を使用して、実装によって、管理者は加算値を定義するかもしれません。
There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready".
また、「メディアによってサポートされること」と正当な値がオペレータ介入は全く必要でなく印刷することの物理的にロードされて、準備ができる「メディアによってサポートしている」値の部分集合を含んでいるだけであるという点において異なる「メディア準備ができていた」状態で指定された追加Printer属性があります。 IPPオブジェクトが「メディアによってサポートされること」をサポートするなら、それは「メディア準備ができること」をサポートする必要はありません。
The relationship of this attribute and the other attributes that control document processing is described in section 15.3.
文書処理を制御するこの属性と他の属性の関係はセクション15.3で説明されます。
4.2.12 printer-resolution (resolution)
4.2.12 プリンタ解決(解決)
This attribute identifies the resolution that Printer uses for the Job.
この属性はPrinterがJobに使用する解決を特定します。
4.2.13 print-quality (type2 enum)
4.2.13 印刷品質(type2 enum)
This attribute specifies the print quality that the Printer uses for the Job.
この属性はPrinterがJobに使用する印刷品質を指定します。
The standard enum values are:
標準のenum値は以下の通りです。
Value Symbolic Name and Description
英字名と記述を評価してください。
'3' 'draft': lowest quality available on the printer '4' 'normal': normal or intermediate quality on the printer '5' 'high': highest quality available on the printer
'3''草稿': プリンタ'4''標準'で利用可能な最も低い品質: プリンタ'5''高値'の正常であるか中間的な品質: プリンタで利用可能な最も高い品質
Hastings, et al. Standards Track [Page 105] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[105ページ]: モデルと意味論2000年9月
4.3 Job Description Attributes
4.3 職務記述書属性
The attributes in this section form the attribute group called "job- description". The following table summarizes these attributes. The third column indicates whether the attribute is a REQUIRED attribute that MUST be supported by Printer objects. If it is not indicated as REQUIRED, then it is OPTIONAL. The maximum size in octets for 'text' and 'name' attributes is indicated in parenthesizes.
このセクションの属性は「仕事の記述」と呼ばれる属性グループを結成します。 以下のテーブルはこれらの属性をまとめます。 第3コラムは、属性がPrinterオブジェクトでサポートしなければならないREQUIRED属性であるかどうかを示します。 REQUIREDとして示されないなら、それはOPTIONALです。 'テキスト'と'名前'属性のための八重奏におけるサイズが示される最大はparenthesizesされます。
+----------------------------+----------------------+--------------+ | Attribute | Syntax | REQUIRED? | +----------------------------+----------------------+--------------+ | job-uri | uri | REQUIRED | +----------------------------+----------------------+--------------+ | job-id | integer(1:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-printer-uri | uri | REQUIRED | +----------------------------+----------------------+--------------+ | job-more-info | uri | | +----------------------------+----------------------+--------------+ | job-name | name (MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-originating-user-name | name (MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-state | type1 enum | REQUIRED | +----------------------------+----------------------+--------------+ | job-state-reasons | 1setOf type2 keyword | REQUIRED | +----------------------------+----------------------+--------------+ | job-state-message | text (MAX) | | +----------------------------+----------------------+--------------+ | job-detailed-status- | 1setOf text (MAX) | | | messages | | | +----------------------------+----------------------+--------------+ | job-document-access-errors | 1setOf text (MAX) | | +----------------------------+----------------------+--------------+ | number-of-documents | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | output-device-assigned | name (127) | | +----------------------------+----------------------+--------------+ | time-at-creation | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | time-at-processing | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | time-at-completed | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-printer-up-time | integer (1:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | date-time-at-creation | dateTime | |
+----------------------------+----------------------+--------------+ | 属性| 構文| 必要ですか? | +----------------------------+----------------------+--------------+ | 仕事-uri| uri| 必要です。| +----------------------------+----------------------+--------------+ | 仕事イド| 整数(1: 最大)| 必要です。| +----------------------------+----------------------+--------------+ | 仕事のプリンタuri| uri| 必要です。| +----------------------------+----------------------+--------------+ | 仕事詳しい情報| uri| | +----------------------------+----------------------+--------------+ | ジョブ名| 名前(MAX)| 必要です。| +----------------------------+----------------------+--------------+ | 仕事の起因するユーザ名| 名前(MAX)| 必要です。| +----------------------------+----------------------+--------------+ | 仕事状態| type1 enum| 必要です。| +----------------------------+----------------------+--------------+ | 仕事の州の理由| 1setOf type2キーワード| 必要です。| +----------------------------+----------------------+--------------+ | 仕事の州のメッセージ| テキスト(MAX)| | +----------------------------+----------------------+--------------+ | 仕事で詳細な状態、-| 1setOfテキスト(MAX)| | | メッセージ| | | +----------------------------+----------------------+--------------+ | 仕事のドキュメントアクセスエラー| 1setOfテキスト(MAX)| | +----------------------------+----------------------+--------------+ | ドキュメントの数| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | 割り当てられた出力デバイス| 名前(127)| | +----------------------------+----------------------+--------------+ | 作成における時間| 整数(MIN: MAX)| 必要です。| +----------------------------+----------------------+--------------+ | 処理における時間| 整数(MIN: MAX)| 必要です。| +----------------------------+----------------------+--------------+ | 完成されて、調節します。| 整数(MIN: MAX)| 必要です。| +----------------------------+----------------------+--------------+ | 仕事のプリンタ動作可能時間| 整数(1: MAX)| 必要です。| +----------------------------+----------------------+--------------+ | 作成における日付の時間| dateTime| |
Hastings, et al. Standards Track [Page 106] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[106ページ]: モデルと意味論2000年9月
+----------------------------+----------------------+--------------+ | date-time-at-processing | dateTime | | +----------------------------+----------------------+--------------+ | date-time-at-completed | dateTime | | +----------------------------+----------------------+--------------+ | number-of-intervening-jobs | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-message-from-operator | text (127) | | +----------------------------+----------------------+--------------+ | job-k-octets | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-impressions | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-media-sheets | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-k-octets-processed | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-impressions-completed | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-media-sheets-completed | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | attributes-charset | charset | REQUIRED | +----------------------------+----------------------+--------------+ | attributes-natural-language| naturalLanguage | REQUIRED | +----------------------------+----------------------+--------------+
+----------------------------+----------------------+--------------+ | 処理における日付の時間| dateTime| | +----------------------------+----------------------+--------------+ | 完成されて、時間の日付を入れます。| dateTime| | +----------------------------+----------------------+--------------+ | 介入している仕事の数| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | オペレータからの仕事のメッセージ| テキスト(127)| | +----------------------------+----------------------+--------------+ | 仕事のk八重奏| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | 仕事印象| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | 仕事のメディアシート| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | 仕事のk八重奏は処理されました。| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | 印象が完了した仕事| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | シートが完成した仕事のメディア| 整数(0: MAX)| | +----------------------------+----------------------+--------------+ | 属性-charset| charset| 必要です。| +----------------------------+----------------------+--------------+ | 属性自然言語| naturalLanguage| 必要です。| +----------------------------+----------------------+--------------+
4.3.1 job-uri (uri)
4.3.1 仕事-uri(uri)
This REQUIRED attribute contains the URI for the job. The Printer object, on receipt of a new job, generates a URI which identifies the new Job. The Printer object returns the value of the "job-uri" attribute as part of the response to a create request. The precise format of a Job URI is implementation dependent. If the Printer object supports more than one URI and there is some relationship between the newly formed Job URI and the Printer object's URI, the Printer object uses the Printer URI supplied by the client in the create request. For example, if the create request comes in over a secure channel, the new Job URI MUST use the same secure channel. This can be guaranteed because the Printer object is responsible for generating the Job URI and the Printer object is aware of its security configuration and policy as well as the Printer URI used in the create request.
このREQUIRED属性は仕事のためのURIを含んでいます。 新しい仕事を受け取り次第、Printerオブジェクトは新しいJobを特定するURIを生成します。 aへの応答の一部が要求を作成するとき、Printerオブジェクトは「仕事-uri」属性の値を返します。 Job URIの正確な形式は実装に依存しています。 Printerオブジェクトが1つ以上のURIをサポートして、新たに形成されたJob URIとPrinterオブジェクトのURIとの何らかの関係があれば、Printerオブジェクトがクライアントによって中に供給されたPrinter URIを使用する、要求を作成してください。 例えば、作成、要求は安全なチャンネルの上に入って、新しいJob URIは同じ安全なチャンネルを使用しなければなりません。 PrinterオブジェクトがJob URIを生成するのに原因となって、Printerオブジェクトがそのセキュリティ設定と方針を意識していて、Printer URIが使用されているのでこれを保証できる、要求を作成してください。
For a description of this attribute and its relationship to "job-id" and "job-printer-uri" attribute, see the discussion in section 2.4 on "Object Identity".
「仕事イド」と「仕事のプリンタuri」属性とのこの属性とその関係の記述に関しては、「オブジェクトのアイデンティティ」のセクション2.4の議論を見てください。
Hastings, et al. Standards Track [Page 107] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[107ページ]: モデルと意味論2000年9月
4.3.2 job-id (integer(1:MAX))
4.3.2 仕事イド(整数(1: 最大))
This REQUIRED attribute contains the ID of the job. The Printer, on receipt of a new job, generates an ID which identifies the new Job on that Printer. The Printer returns the value of the "job-id" attribute as part of the response to a create request. The 0 value is not included to allow for compatibility with SNMP index values which also cannot be 0.
このREQUIRED属性は仕事のIDを含んでいます。 新しい仕事を受け取り次第、PrinterはそのPrinterの上の新しいJobを特定するIDを生成します。 aへの応答の一部が要求を作成するとき、Printerは「仕事イド」属性の値を返します。 0値は、また、0であるはずがないSNMPインデックス値との互換性を考慮するために含まれていません。
For a description of this attribute and its relationship to "job-uri" and "job-printer-uri" attribute, see the discussion in section 2.4 on "Object Identity".
「仕事-uri」と「仕事のプリンタuri」属性とのこの属性とその関係の記述に関しては、「オブジェクトのアイデンティティ」のセクション2.4の議論を見てください。
4.3.3 job-printer-uri (uri)
4.3.3 仕事のプリンタuri(uri)
This REQUIRED attribute identifies the Printer object that created this Job object. When a Printer object creates a Job object, it populates this attribute with the Printer object URI that was used in the create request. This attribute permits a client to identify the Printer object that created this Job object when only the Job object's URI is available to the client. The client queries the creating Printer object to determine which languages, charsets, operations, are supported for this Job.
このREQUIRED属性はこのJobオブジェクトを作成したPrinterオブジェクトを特定します。 PrinterオブジェクトがJobオブジェクトを作成するとき、中のPrinterオブジェクトURIが使用されていた状態でこの属性に居住する、要求を作成してください。 この属性は、クライアントがクライアントにとって、JobオブジェクトのURIだけが利用可能であるときにこのJobオブジェクトを作成したPrinterオブジェクトを特定することを許可します。 クライアントは、どの言語(charsets、操作)がこのJobのためにサポートされるかを決定するために作成しているPrinterオブジェクトについて質問します。
For a description of this attribute and its relationship to "job-uri" and "job-id" attribute, see the discussion in section 2.4 on "Object Identity".
「仕事-uri」と「仕事イド」属性とのこの属性とその関係の記述に関しては、「オブジェクトのアイデンティティ」のセクション2.4の議論を見てください。
4.3.4 job-more-info (uri)
4.3.4 仕事詳しい情報(uri)
Similar to "printer-more-info", this attribute contains the URI referencing some resource with more information about this Job object, perhaps an HTML page containing information about the Job.
「プリンタ詳しい情報」と同様です、この属性はこのJobオブジェクトに関する詳しい情報で何らかのリソースに参照をつけるURI、Jobの情報を含む恐らく1HTML形式のページを含んでいます。
4.3.5 job-name (name(MAX))
4.3.5 ジョブ名(名前(最大))
This REQUIRED attribute is the name of the job. It is a name that is more user friendly than the "job-uri" attribute value. It does not need to be unique between Jobs. The Job's "job-name" attribute is set to the value supplied by the client in the "job-name" operation attribute in the create request (see Section 3.2.1.1). If, however, the "job-name" operation attribute is not supplied by the client in the create request, the Printer object, on creation of the Job, MUST generate a name. The printer SHOULD generate the value of the Job's "job-name" attribute from the first of the following sources that produces a value: 1) the "document-name" operation attribute of the
このREQUIRED属性は仕事の名前です。 それは「仕事-uri」属性値よりユーザフレンドリーな名前です。 それはジョブスの間で特有である必要はありません。 セクション3.2を見てください。Jobの「ジョブ名」属性が「ジョブ名」操作属性におけるクライアントによって中に供給された値へのセットである、要求を作成してください、(.1 .1)。 しかしながら、「ジョブ名」操作属性がクライアントによって中に供給されない、Jobの作成では、要求を作成してください、そして、Printerオブジェクトは名前を生成しなければなりません。 プリンタSHOULDは以下のソースの1番目からの値を生産するJobの「ジョブ名」属性の値を生成します: 1) 「ドキュメント名」操作属性
Hastings, et al. Standards Track [Page 108] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[108ページ]: モデルと意味論2000年9月
first (or only) document, 2) the "document-URI" attribute of the first (or only) document, or 3) any other piece of Job specific and/or Document Content information.
最初(単に)のドキュメント、最初(単に)のドキュメント、または3の2)「ドキュメントURI」属性) いかなる他のJob特有である、そして/または、Document Content情報。
4.3.6 job-originating-user-name (name(MAX))
4.3.6 仕事の起因するユーザ名(名前(最大))
This REQUIRED attribute contains the name of the end user that submitted the print job. The Printer object sets this attribute to the most authenticated printable name that it can obtain from the authentication service over which the IPP operation was received. Only if such is not available, does the Printer object use the value supplied by the client in the "requesting-user-name" operation attribute of the create operation (see Sections 4.4.2, 4.4.3, and 8).
このREQUIRED属性は印刷仕事を提出したエンドユーザの名前を含んでいます。 PrinterオブジェクトはIPP操作が受けられた認証サービスから得ることができる中で最も認証された印刷可能な名前にこの属性を設定します。 セクション4.4.2を見てください、4.4。そのようなものが単に利用可能でなく、オブジェクトが「要求しているユーザ名」操作属性におけるクライアントによって供給された値を使用するPrinterをする、操作を作成してください、(.3、および8)。
Note: The Printer object needs to keep an internal originating user id of some form, typically as a credential of a principal, with the Job object. Since such an internal attribute is implementation- dependent and not of interest to clients, it is not specified as a Job Description attribute. This originating user id is used for authorization checks (if any) on all subsequent operations.
以下に注意してください。 Printerオブジェクトは、何らかのフォームの内部の起因しているユーザイドを保つ必要があります、通常元本の資格証明書として、Jobオブジェクトで。 そのような内部の属性がクライアントには、依存して興味深くない実装であるので、それはJob記述属性として指定されません。 この起因しているユーザイドはすべてのその後の操作のときに(もしあれば)の許可検査に使用されます。
4.3.7 job-state (type1 enum)
4.3.7 仕事状態(type1 enum)
This REQUIRED attribute identifies the current state of the job. Even though the IPP protocol defines seven values for job states (plus the out-of-band 'unknown' value - see Section 4.1), implementations only need to support those states which are appropriate for the particular implementation. In other words, a Printer supports only those job states implemented by the output device and available to the Printer object implementation.
このREQUIRED属性は仕事の現状を特定します。 IPPプロトコルは7つの値を仕事の州と定義しますが(バンドで出ている'未知'の値--セクション4.1を見てください)、実装は、それらの特定の実装に、適切な州をサポートする必要があるだけです。 言い換えれば、Printerは出力装置によって実装されてPrinterオブジェクト実装に利用可能な状態でそれらの仕事の州だけをサポートします。
Standard enum values are:
標準のenum値は以下の通りです。
Values Symbolic Name and Description
英字名と記述を評価します。
'3' 'pending': The job is a candidate to start processing, but is
not yet processing.
'3''未定': 仕事は、処理し始める候補ですが、しかし、処理ではありません。
'4' 'pending-held': The job is not a candidate for processing for
any number of reasons but will return to the 'pending'
state as soon as the reasons are no longer present. The
job's "job-state-reason" attribute MUST indicate why the
job is no longer a candidate for processing.
'4''未定に保持される': 仕事は、いろいろな理由のための処理の候補ではありませんが、理由がもう存在していないとすぐに、'未定'の状態に戻るでしょう。 仕事の「仕事の州の理由」属性は、仕事がなぜもう処理の候補でないかを示さなければなりません。
Hastings, et al. Standards Track [Page 109] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[109ページ]: モデルと意味論2000年9月
'5' 'processing': One or more of:
'5''処理': 1つか、より多く:
1. the job is using, or is attempting to use, one or
more purely software processes that are analyzing,
creating, or interpreting a PDL, etc.,
2. the job is using, or is attempting to use, one or
more hardware devices that are interpreting a PDL, making
marks on a medium, and/or performing finishing, such as
stapling, etc.,
3. the Printer object has made the job ready for
printing, but the output device is not yet printing it,
either because the job hasn't reached the output device
or because the job is queued in the output device or some
other spooler, awaiting the output device to print it.
2 1. 仕事は、使用である、使用する試み、1または、より純粋に分析であるソフトウェア処理です、PDLなどを作成するか、または解釈して、仕事が、使用である、またはPrinterオブジェクトで媒体の上でマークを作って、PDLを解釈している1個以上のハードウェアデバイス、そして/または、公演がとめなどのように終わる3を使用するのを印刷の準備ができる仕事を試みていたことです; しかし、出力装置はまだそれを印刷していません、仕事が出力装置に達していないか、または仕事が出力装置かある他のスプーラで列に並ばせられるので、それを印刷するために出力装置を待って。
When the job is in the 'processing' state, the entire job
state includes the detailed status represented in the
Printer object's "printer-state", "printer-state-
reasons", and "printer-state-message" attributes.
仕事が'処理'状態にあるとき、仕事全体州はPrinterオブジェクトの「プリンタ状態」に表された詳細な状態、「プリンタ理由を述べる」、および「プリンタ州のメッセージ」属性を含めます。
Implementations MAY, though they NEED NOT, include
additional values in the job's "job-state-reasons"
attribute to indicate the progress of the job, such as
adding the 'job-printing' value to indicate when the
output device is actually making marks on paper and/or
the 'processing-to-stop-point' value to indicate that the
IPP object is in the process of canceling or aborting the
job. Most implementations won't bother with this nuance.
彼らはNOTを必要としますが、実装は仕事の進歩を示すために仕事の「仕事の州の理由」属性に加算値を含むかもしれません、出力装置がいつ仕事を中止するか、または中止することの途中にIPPオブジェクトがあるのを示すために実際に紙上のマーク、そして/または、'ポイントを止めるために処理する'値を作っているかを示すために'端物印刷'価値を高めるのなどように。 ほとんどの実装はこのニュアンスを苦にしないでしょう。
'6' 'processing-stopped': The job has stopped while processing
for any number of reasons and will return to the
'processing' state as soon as the reasons are no longer
present.
'6''処理で止まる': 仕事はいろいろな理由で処理している間、止まっています、そして、理由がもう存在していないとすぐに、'処理'状態に戻るでしょう。
The job's "job-state-reason" attribute MAY indicate why
the job has stopped processing. For example, if the
output device is stopped, the 'printer-stopped' value MAY
be included in the job's "job-state-reasons" attribute.
仕事の「仕事の州の理由」属性は、仕事が、なぜ処理するのを止めたかを示すかもしれません。 例えば、出力装置が止められるなら、'プリンタで止まっている'値は仕事の「仕事の州の理由」属性に含まれるかもしれません。
Note: When an output device is stopped, the device
usually indicates its condition in human readable form
locally at the device. A client can obtain more complete
device status remotely by querying the Printer object's
"printer-state", "printer-state-reasons" and "printer-
state-message" attributes.
以下に注意してください。 出力装置が止められるとき、通常、デバイスはデバイスで人間の読み込み可能なフォームで局所的に状態を示します。 クライアントは、Printerオブジェクトの「プリンタ状態」、「プリンタ州の理由」、および「プリンタ州メッセージ」属性について質問することによって、より完全なデバイス状態を離れて得ることができます。
'7' 'canceled': The job has been canceled by a Cancel-Job
operation and the Printer object has completed canceling
'7'は'取り消されました': 仕事はキャンセル仕事の操作で中止されました、そして、Printerオブジェクトは取り消すのを完了しました。
Hastings, et al. Standards Track [Page 110] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[110ページ]: モデルと意味論2000年9月
the job and all job status attributes have reached their
final values for the job. While the Printer object is
canceling the job, the job remains in its current state,
but the job's "job-state-reasons" attribute SHOULD
contain the 'processing-to-stop-point' value and one of
the 'canceled-by-user', 'canceled-by-operator', or
'canceled-at-device' value. When the job moves to the
'canceled' state, the 'processing-to-stop-point' value,
if present, MUST be removed, but the 'canceled-by-xxx',
if present, MUST remain.
仕事とすべての地位の属性が仕事のためのそれらの検査値に達しました。 Printerオブジェクトが仕事を中止している間、仕事は現状のときに残っていますが、仕事の「仕事の州の理由」属性SHOULDは'ポイントを止めるために処理する'値と'ユーザによって取り消されて'、'オペレータによって取り消される'か、または'デバイスでは、取り消され'て価値の1つを含んでいます。 仕事が'取り消された'状態に移行するとき、存在しているなら、'ポイントを止めるために処理する'値を取り除かなければなりませんが、存在しているなら、'xxxによって取り消しにされるの'は残らなければなりません。
'8' 'aborted': The job has been aborted by the system, usually
while the job was in the 'processing' or 'processing-
stopped' state and the Printer has completed aborting the
job and all job status attributes have reached their
final values for the job. While the Printer object is
aborting the job, the job remains in its current state,
but the job's "job-state-reasons" attribute SHOULD
contain the 'processing-to-stop-point' and 'aborted-by-
system' values. When the job moves to the 'aborted'
state, the 'processing-to-stop-point' value, if present,
MUST be removed, but the 'aborted-by-system' value, if
present, MUST remain.
'8'は'中止になりました': 仕事はシステムによって中止されました、'通常'処理'には仕事があったか、処理は'状態を止めて、Printerは、仕事を中止するのを完成して、またはすべての地位の属性が仕事のためのそれらの検査値に達しましたが。 Printerオブジェクトが仕事を中止している間、仕事は現状のときに残っていますが、仕事の「仕事の州の理由」属性SHOULDは'処理から停止ポイント'と'中止になっているシステム'の値を含んでいます。 仕事が'中止になっている'状態に移行するとき、存在しているなら、'ポイントを止めるために処理する'値を取り除かなければなりませんが、存在しているなら、'システムで中止されて'値は残らなければなりません。
'9' 'completed': The job has completed successfully or with
warnings or errors after processing and all of the job
media sheets have been successfully stacked in the
appropriate output bin(s) and all job status attributes
have reached their final values for the job. The job's
"job-state-reasons" attribute SHOULD contain one of:
'completed-successfully', 'completed-with-warnings', or
'completed-with-errors' values.
'9'は'完成しました': 仕事は仕事のために仕事のメディアシートの処理とすべてが適切な出力容器で首尾よく積み重ねられて、すべての地位の属性がそれらの検査値に達した後に首尾よいか警告か誤りで完成しました。 仕事の「仕事の州の理由」属性SHOULDは1つを含んでいます: 値を'-首尾よく、完成する'か、'警告で、完成する'か、または'誤りで、完成しました'。
The final value for this attribute MUST be one of: 'completed', 'canceled', or 'aborted' before the Printer removes the job altogether. The length of time that jobs remain in the 'canceled', 'aborted', and 'completed' states depends on implementation. See section 4.3.7.2.
この属性のための検査値が1でなければならない、: Printerが全体で仕事を取り除く前に、'完成される'か、'取り消される'か、または'中止されます'。 仕事が'取り消され'て、'中止になっ'て、'完成した'州に残る時間の長さは実装に依存します。 .2にセクション4.3.7を見てください。
The following figure shows the normal job state transitions.
以下の図は通常の仕事の状態遷移を示しています。
+----> canceled
/
+----> pending --------> processing ---------+------> completed
| ^ ^ \
--->+ | | +----> aborted
| v v /
+----> pending-held processing-stopped ---+
+---->は/+を取り消しました。----未定の>。-------->処理---------+------完成した>。| ^ ^ \ --->+| | +---->は中止になりました。| v/+に対して---->、未定に保持される、処理で止まられる。---+
Hastings, et al. Standards Track [Page 111] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[111ページ]: モデルと意味論2000年9月
Normally a job progresses from left to right. Other state transitions are unlikely, but are not forbidden. Not shown are the transitions to the 'canceled' state from the 'pending', 'pending- held', and 'processing-stopped' states.
通常、仕事は左から右まで進歩をします。 他の状態遷移は、ありそうもないのですが、禁じられません。 示されていないのは、'未定'の''未定の保持された'処理で止まる'州からの'取り消された'状態への変遷です。
Jobs reach one of the three terminal states: 'completed', 'canceled', or 'aborted', after the jobs have completed all activity, including stacking output media, after the jobs have completed all activity, and all job status attributes have reached their final values for the job.
仕事は3つの端末の州の1つに達します: 仕事がアウトプット・メディアを積み重ねるのを含むすべての活動を終了した後に、仕事がすべての活動を終了して、すべての地位の属性が仕事のためのそれらの検査値に達した後に、'完成される'か、'取り消される'か、または'中止されます'。
4.3.7.1 Forwarding Servers
4.3.7.1 推進サーバ
As with all other IPP attributes, if the implementation cannot determine the correct value for this attribute, it SHOULD respond with the out-of-band value 'unknown' (see section 4.1) rather than try to guess at some possibly incorrect value and give the end user the wrong impression about the state of the Job object. For example, if the implementation is just a gateway into some printing system from which it can normally get status, but temporarily is unable, then the implementation should return the 'unknown' value. However, if the implementation is a gateway to a printing system that never provides detailed status about the print job, the implementation MAY set the IPP Job object's state to 'completed', provided that it also sets the 'queued-in-device' value in the job's "job-state-reasons" attribute (see section 4.3.8).
実装がそうすることができないなら、この属性のために他のすべてのIPP属性のように正しい値を決定してください、それ。SHOULDは何らかのことによると不正確な値を推測して、間違った印象をエンドユーザに与えようとするよりバンドで出かけている値の'未知'(セクション4.1を見る)でJobオブジェクトの状態に関してむしろ応じます。 例えば、ただ通常、それが状態を得ることができる何らかの印刷システムへのゲートウェイですが、一時実装であることができないなら、実装は'未知'の値を返すべきです。 しかしながら、実装が印刷仕事に関する詳細な状態を決して提供しない印刷システムへのゲートウェイであるなら、実装は'完成してい'て、また、仕事のものにおける'デバイスで列に並ばせられた'値を設定すれば「仕事の状態は推論する」という属性にIPP Jobオブジェクトの状態を設定するかもしれません(セクション4.3.8を見てください)。
4.3.7.2 Partitioning of Job States
4.3.7.2 仕事の州の仕切り
This section partitions the 7 job states into phases: Job Not Completed, Job Retention, Job History, and Job Removal. This section also explains the 'job-restartable' value of the "job-state-reasons" Job Description attribute for use with the Restart-Job operation.
このセクションは7つの仕事の州をフェーズに仕切ります: 完了しない仕事、仕事の保有、仕事の歴史、および仕事の取り外し。 また、このセクションは使用のためにRestart-仕事の操作で「仕事の州の理由」Job記述属性の'仕事-再開可能'値について説明します。
Job Not Completed: When a job is in the 'pending', 'pending-held', 'processing', or 'processing-stopped' states, the job is not completed.
仕事は完成しませんでした: 仕事が'未定'の、そして、'未定に保持された''処理'、または'処理で止まっている'州にあるとき、仕事は完了していません。
Job Retention: When a job enters one of the three terminal job states: 'completed', 'canceled', or 'aborted', the IPP Printer object MAY "retain" the job in a restartable condition for an implementation-defined time period. This time period MAY be zero seconds and MAY depend on the terminal job state. This phase is called Job Retention. While in the Job Retention phase, the job's document data is retained and a client may restart the job using the Restart-Job operation. If the IPP object supports the Restart-Job
仕事の保有: 仕事に入るとき、3端末ジョブのひとりは以下を述べます。 '完成する'、'取り消される'、または'中止になります'、IPP Printerオブジェクトは実装で定義された期間、再開可能状態における仕事を「保有するかもしれません」。 この期間は、秒でないかもしれなく、端末ジョブ状態に依存するかもしれません。 このフェーズはJob Retentionと呼ばれます。 Job Retentionフェーズでは、仕事のドキュメントデータは保有されます、そして、クライアントはRestart-仕事の操作を使用することで仕事を再開するかもしれませんが。 IPPオブジェクトがRestart-仕事をサポートするなら
Hastings, et al. Standards Track [Page 112] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[112ページ]: モデルと意味論2000年9月
operation, then it SHOULD indicate that the job is restartable by adding the 'job-restartable' value to the job's "job-state-reasons" attribute (see Section 4.3.8) during the Job Retention phase.
次に、操作、それ、SHOULDは、仕事がJob Retention段階の間、仕事の「仕事の州の理由」属性(セクション4.3.8を見る)に'仕事-再開可能'価値を高めることによって再開可能であることを示します。
Job History: After the Job Retention phase expires for a job, the Printer object deletes the document data for the job and the job becomes part of the Job History. The Printer object MAY also delete any number of the job attributes. Since the job is no longer restartable, the Printer object MUST remove the 'job-restartable' value from the job's "job-state-reasons" attribute, if present.
仕事の歴史: Job Retentionフェーズが仕事のために期限が切れた後に、Printerオブジェクトは仕事のためのドキュメントデータを削除します、そして、仕事はJob歴史の一部になります。 また、Printerオブジェクトはいろいろな仕事の属性を削除するかもしれません。 仕事がもう再開可能でないので、Printerオブジェクトは仕事の「仕事の州の理由」属性から'仕事-再開可能'値を取り除かなければなりません、存在しているなら。
Job Removal: After the job has remained in the Job History for an implementation-defined time, such as when the number of jobs exceeds a fixed number or after a fixed time period (which MAY be zero seconds), the IPP Printer removes the job from the system.
仕事の取り外し: 仕事が仕事の数が定数を超えている時などの実装で定義された時間か固定期間(秒でないかもしれない)の後にJob歴史に残った後に、IPP Printerはシステムから仕事を取り除きます。
Using the Get-Jobs operation and supplying the 'not-completed' value for the "which-jobs" operation attribute, a client is requesting jobs in the Job Not Completed phase. Using the Get-Jobs operation and supplying the 'completed' value for the "which-jobs" operation attribute, a client is requesting jobs in the Job Retention and Job History phases. Using the Get-Job-Attributes operation, a client is requesting a job in any phase except Job Removal. After Job Removal, the Get-Job-Attributes and Get-Jobs operations no longer are capable of returning any information about a job.
Get-ジョブス操作を使用して、'完成していない'値を供給する、「どれ、-、仕事、」 操作属性、クライアントはJob Not Completedフェーズにおける仕事を要求しているか。 Get-ジョブス操作を使用して、'完成した'値を供給する、「どれ、-、仕事、」 操作属性、クライアントはJob RetentionとJob歴史フェーズにおける仕事を要求しているか。 Get仕事の属性操作を使用して、クライアントはJob Removal以外のどんなフェーズでも仕事を要求しています。 Job Removal、Get仕事の属性、およびGet-仕事のときに操作がもう仕事の少しの情報も返すことができない後。
4.3.8 job-state-reasons (1setOf type2 keyword)
4.3.8 仕事の州の理由(1setOf type2キーワード)
This REQUIRED attribute provides additional information about the job's current state, i.e., information that augments the value of the job's "job-state" attribute.
このREQUIRED属性は仕事の現状(すなわち、仕事の「仕事状態」属性の値を増大させる情報)に関する追加情報を提供します。
These values MAY be used with any job state or states for which the reason makes sense. Some of these value definitions indicate conformance requirements; the rest are OPTIONAL. Furthermore, when implemented, the Printer MUST return these values when the reason applies and MUST NOT return them when the reason no longer applies whether the value of the Job's "job-state" attribute changed or not. When the Job does not have any reasons for being in its current state, the value of the Job's "job-state-reasons" attribute MUST be 'none'.
これらの値は理由が理解できるどんな仕事の州や州と共にも使用されるかもしれません。 これらの値の定義のいくつかが順応要件を示します。 残りはOPTIONALです。 その上、実装されると、Jobの「仕事状態」属性の値が変化したか否かに関係なく、Printerは理由が適用されるとき、これらの値を返さなければならなくて、理由がもう適用されないとき、それらは返してはいけません。 Jobに現状のときに、ある少しの理由もないとき、Jobの「仕事の州の理由」属性の値は'なにも'でなければなりません。
Note: While values cannot be added to the 'job-state' attribute without impacting deployed clients that take actions upon receiving "job-state" values, it is the intent that additional "job-state- reasons" values can be defined and registered without impacting such deployed clients. In other words, the "job-state-reasons" attribute is intended to be extensible.
以下に注意してください。 受信「仕事状態」値で行動を取る配布しているクライアントに影響を与えないで、'仕事状態'属性に値を加えることができませんが、それは意図ですクライアントであると配布されたそのようなものに影響を与えながら追加「仕事の理由を述べている」値を定義して、示すことができる。 言い換えれば、「仕事の州の理由」属性が広げることができることを意図します。
Hastings, et al. Standards Track [Page 113] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[113ページ]: モデルと意味論2000年9月
The following standard keyword values are defined. For ease of understanding, the values are presented in the order in which the reasons are likely to occur (if implemented), starting with the 'job-incoming' value:
以下の標準のキーワード値は定義されます。 理解の容易さにおいて、値は理由が起こりそうであるオーダーに示されます(実装されるなら)、'仕事の入って来る'値から始まって:
'none': There are no reasons for the job's current state. This
state reason is semantically equivalent to "job-state-reasons"
without any value and MUST be used when there is no other
value, since the 1setOf attribute syntax requires at least one
value.
'job-incoming': Either (1) the Printer has accepted the Create-
Job operation and is expecting additional Send-Document and/or
Send-URI operations, or (2) the Printer is retrieving/accepting
document data as a result of a Print-Job, Print-URI, Send-
Document or Send-URI operation.
'job-data-insufficient': The Create-Job operation has been
accepted by the Printer, but the Printer is expecting
additional document data before it can move the job into the
'processing' state. If a Printer starts processing before it
has received all data, the Printer removes the 'job-data-
insufficient' reason, but the 'job-incoming' remains. If a
Printer starts processing after it has received all data, the
Printer removes the 'job-data-insufficient' reason and the
'job-incoming' at the same time.
'document-access-error': After accepting a Print-URI or Send-URI
request, the Printer could not access one or more documents
passed by reference. This reason is intended to cover any file
access problem, including file does not exist and access denied
because of an access control problem. The Printer MAY also
indicate the document access error using the "job-document-
access-errors" Job Description attribute (see section 4.3.11).
Whether the Printer aborts the job and moves the job to the
'aborted' job state or prints all documents that are accessible
and moves the job to the 'completed' job state and adds the
'completed-with-errors' value in the job's "job-state-reasons"
attribute depends on implementation and/or site policy. This
value SHOULD be supported if the Print-URI or Send-URI
operations are supported.
'submission-interrupted': The job was not completely submitted
for some unforeseen reason, such as: (1) the Printer has
crashed before the job was closed by the client, (2) the
Printer or the document transfer method has crashed in some
non-recoverable way before the document data was entirely
transferred to the Printer, (3) the client crashed or failed to
close the job before the time-out period. See section 4.4.31.
'job-outgoing': The Printer is transmitting the job to the output
device.
'なにも': 仕事の現状の理由が全くありません。 この州の理由を少しも値なしで「仕事の州の理由」に意味的に同等であり、他の値が全くないとき、使用しなければなりません、1setOf属性構文が少なくとも1つの値を必要とするので。 '仕事入来': PrinterはPrint-仕事、Print-URI、SendドキュメントまたはSend-URI操作の結果、ドキュメントデータを(1) PrinterがCreate仕事の操作を受け入れて、追加Send-ドキュメント、そして/または、Send-URI操作を予想しているか、検索するか、または(2) 受け入れています。 '、仕事のデータ不十分である、'、: Create-仕事の操作はPrinterによって受け入れられましたが、仕事を'処理'状態に動かすことができる前にPrinterは追加ドキュメントデータを予想しています。 すべてのデータを受け取る前にPrinterが処理し始めるなら、Printerは'仕事データ不十分な'理由を取り除きますが、'仕事入来'は残っています。 すべてのデータを受け取った後にPrinterが処理し始めるなら、Printerが取り外す、'、仕事のデータ不十分である、'同時にの'理由と'仕事入来。 'ドキュメントアクセスエラー': Print-URIかSend-URI要求を受け入れた後に、Printerは参照で渡された1通以上のドキュメントにアクセスできませんでした。 アクセス制御の問題によるどんなファイルアクセス問題もカバーすることを意図して、ファイルを含んでいるのが存在していないこの理由とアクセス拒否。 また、「仕事ドキュメントアクセスエラー」Job記述属性を使用して、Printerはドキュメントアクセスエラーを示すかもしれません(セクション4.3.11を見てください)。 Printerが仕事の「仕事の州の理由」属性で仕事を中止して、仕事を'中止になっている'仕事の状態に動かすか、すべてのアクセス可能なドキュメントを印刷して、仕事を'完成した'仕事の状態に動かして、または'誤りで完成した'価値を高めるかが実装、そして/または、サイト方針によります。 これはSHOULDを評価します。Print-URIかSend-URI操作がサポートされるなら、サポートされてください。 '服従で中断される': 以下などの何らかの予期しない理由で完全に仕事を提出したというわけではありません。 (1) (2) 仕事がクライアントによって終えられる前にPrinterはダウンして、Printerかドキュメント転写法が(3) ドキュメントデータをPrinterに完全に移す前に、クライアントがダウンしたか、またはタイムアウトの期間の前に仕事を終えなかった何らかの非回復可能な方法でダウンしました。 セクション4.4.31を見てください。 '仕事の送信する': Printerは仕事を出力装置に伝えています。
Hastings, et al. Standards Track [Page 114] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[114ページ]: モデルと意味論2000年9月
'job-hold-until-specified': The value of the job's "job-hold-
until" attribute was specified with a time period that is still
in the future. The job MUST NOT be a candidate for processing
until this reason is removed and there are no other reasons to
hold the job. This value SHOULD be supported if the "job-
hold-until" Job Template attribute is supported.
'resources-are-not-ready': At least one of the resources needed
by the job, such as media, fonts, resource objects, etc., is
not ready on any of the physical printer's for which the job is
a candidate. This condition MAY be detected when the job is
accepted, or subsequently while the job is pending or
processing, depending on implementation. The job may remain in
its current state or be moved to the 'pending-held' state,
depending on implementation and/or job scheduling policy.
'printer-stopped-partly': The value of the Printer's "printer-
state-reasons" attribute contains the value 'stopped-partly'.
'printer-stopped': The value of the Printer's "printer-state"
attribute is 'stopped'.
'job-interpreting': Job is in the 'processing' state, but more
specifically, the Printer is interpreting the document data.
'job-queued': Job is in the 'processing' state, but more
specifically, the Printer has queued the document data.
'job-transforming': Job is in the 'processing' state, but more
specifically, the Printer is interpreting document data and
producing another electronic representation.
'job-queued-for-marker': Job is in any of the 'pending-held',
'pending', or 'processing' states, but more specifically, the
Printer has completed enough processing of the document to be
able to start marking and the job is waiting for the marker.
Systems that require human intervention to release jobs using
the Release-Job operation, put the job into the 'pending-held'
job state. Systems that automatically select a job to use the
marker put the job into the 'pending' job state or keep the
job in the 'processing' job state while waiting for the marker,
depending on implementation. All implementations put the job
into (or back into) the 'processing' state when marking does
begin.
'job-printing': The output device is marking media. This value is
useful for Printers which spend a great deal of time processing
(1) when no marking is happening and then want to show that
marking is now happening or (2) when the job is in the process
of being canceled or aborted while the job remains in the
'processing' state, but the marking has not yet stopped so that
impression or sheet counts are still increasing for the job.
'指定されるまでの仕事の保持': 仕事して成立してください。仕事のものの値、「-まだ未来に、」 属性が期間で指定されるまで、それはいます。 この理由が取り除かれて、仕事を持つ他の理由が全くないまで、仕事は処理の候補であるはずがありません。 この値のSHOULD、サポートされてください、「仕事、保持、-、」 Job Template属性はサポートされます。 'リソースは準備ができていません': 少なくとも仕事で必要であるメディア、フォント、リソースオブジェクトなどのリソースの1つは仕事が候補である物理的なプリンタのもののいずれでも準備ができていません。 この状態は、仕事が未定である間、次に仕事を受け入れると検出していて、処理されているかもしれません、実装によって。 仕事は、現状のときに残っているか、または'未定に保持された'状態に動かされるかもしれません、実装、そして/または、ジョブスケジューリング方針によって。 'プリンタは一部止まりました': Printerの「プリンタ州理由」属性の値は'-一部止められた'値を含んでいます。 'プリンタで止まる': Printerの「プリンタ状態」属性の値は'止められます'。 '仕事を解釈しています': 仕事が'処理'状態にありますが、より明確に、Printerはドキュメントデータを解釈しています。 '仕事で列に並ばせられる': 仕事が'処理'状態にありますが、より明確に、Printerはドキュメントデータを列に並ばせました。 '仕事を変えます': 仕事が'処理'状態にありますが、Printerは、より明確に、ドキュメントデータを解釈して、別の電子表現を作成しています。 '仕事はマーカーのために列を作りました': '仕事が'未定に保持にされるの'のどれかにあって、'しかし、州、以上明確に、Printerが完成した'処理'であることまでマークと仕事を始めることができるためにはドキュメントの十分な処理はマーカーを待つことです。 Release-仕事の操作を使用することで仕事をリリースするために人間の介入を必要として、'未定に保持された'仕事の状態に仕事を入れるシステム。 マーカーを使用するために自動的に仕事を選択するシステムが、'未定'の仕事の状態に仕事を入れるか、またはマーカーを待っている間、'処理'仕事の状態に仕事を保ちます、実装によって。 すべての実装が仕事を入れる、(逆)、マークするとき、'処理'状態は始まります。 '端物印刷': 出力装置はメディアにマークしています。 仕事が'処理'州に残っている間、取り消されるか、または中止されることの途中に仕事があるとき、この値が(1)を処理するマークでないのがナウい多くの時間を過ごして、次にマークが現在ナウいのを示したがっているPrintersか(2)の役に立ちますが、マークがまだ止まっていないので、印象かシートカウントが仕事のためにまだ大きくなっています。
Hastings, et al. Standards Track [Page 115] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[115ページ]: モデルと意味論2000年9月
'job-canceled-by-user': The job was canceled by the owner of the
job using the Cancel-Job request, i.e., by a user whose
authenticated identity is the same as the value of the
originating user that created the Job object, or by some other
authorized end-user, such as a member of the job owner's
security group. This value SHOULD be supported.
'job-canceled-by-operator': The job was canceled by the operator
using the Cancel-Job request, i.e., by a user who has been
authenticated as having operator privileges (whether local or
remote). If the security policy is to allow anyone to cancel
anyone's job, then this value may be used when the job is
canceled by other than the owner of the job. For such a
security policy, in effect, everyone is an operator as far as
canceling jobs with IPP is concerned. This value SHOULD be
supported if the implementation permits canceling by other than
the owner of the job.
'job-canceled-at-device': The job was canceled by an unidentified
local user, i.e., a user at a console at the device. This
value SHOULD be supported if the implementation supports
canceling jobs at the console.
'aborted-by-system': The job (1) is in the process of being
aborted, (2) has been aborted by the system and placed in the
'aborted' state, or (3) has been aborted by the system and
placed in the 'pending-held' state, so that a user or operator
can manually try the job again. This value SHOULD be
supported.
'unsupported-compression': The job was aborted by the system
because the Printer determined while attempting to decompress
the document-data's that the compression is actually not among
those supported by the Printer. This value MUST be supported,
since "compressions is a REQUIRED operation attribute.
'compression-error': The job was aborted by the system because the
Printer encountered an error in the document-data while
decompressing it. If the Printer posts this reason, the
document-data has already passed any tests that would have led
to the 'unsupported-compression' job-state-reason.
'unsupported-document-format': The job was aborted by the system
because the document-data's document-format is not among those
supported by the Printer. If the client specifies the
document-format as 'application/octet-stream', the printer MAY
abort the job and post this reason even though the format is a
member of the "document-format-supported" printer attribute,
but not among the auto-sensed document-formats. This value
MUST be supported, since "document-format" is a REQUIRED
operation attribute.
'仕事はユーザに中止しました': 仕事はすなわち、認証されたアイデンティティがJobオブジェクトを作成した起因しているユーザの値と同じであるユーザ、またはある他の認可されたエンドユーザによるキャンセル仕事の要求を使用することで仕事の所有者によって中止されました、仕事の所有者のセキュリティグループのメンバーのように。 これはSHOULDを評価します。サポートされます。 '仕事はオペレータに中止しました': 仕事はキャンセル仕事の要求を使用することでオペレータによって中止されました、すなわち、オペレータ特権を持っていると認証されたユーザで(地方である、またはリモートであることにかかわらず)。 仕事の所有者を除いて、仕事で取り消されるとき、安全保障政策がだれでも仕事を中止するのを許容することであるなら、この値は使用されるかもしれません。 事実上、そのような安全保障政策のために、IPPとの仕事を中止するのに関する限り、皆はオペレータです。 これはSHOULDを評価します。実装が、仕事の所有者を除いて、取り消すことを許可するなら、サポートされます。 '仕事はデバイスで中止しました': 仕事はすなわち、未確認の地元のユーザ、デバイスのコンソールのユーザによって中止されました。 これはSHOULDを評価します。実装が、コンソールで取り消しが仕事であるとサポートするなら、サポートされてください。 'システムで、中止されます': 中止されることの途中に仕事(1)があって、(2)がシステムによって中止されて、'中止になっている'状態に置かれたか、(3)はシステムで中止されて、'未定に保持された'状態に置かれました、ユーザかオペレータが再び手動で仕事を試みることができるように。 これはSHOULDを評価します。サポートされます。 'サポートされない圧縮': Printerが、減圧するのを試みている間実際にそれらの中ではなく圧縮をあるドキュメントデータがPrinterによってサポートされていることを決定したので、仕事はシステムによって中止されました。 「圧縮はREQUIRED操作属性です」ゆえこの値をサポートしなければなりません。 '圧縮誤り': Printerがそれを減圧している間、ドキュメントデータにおける誤りに遭遇したので、仕事はシステムによって中止されました。 Printerポストであるなら、これは推論して、ドキュメントデータは既に'サポートされない圧縮'仕事の州の理由につながったどんなテストにも合格しました。 'サポートされないドキュメント・フォーマット': ドキュメントデータのドキュメント・フォーマットがPrinterによってサポートされたものにないので、仕事はシステムによって中止されました。 クライアントが'八重奏アプリケーション/ストリーム'としてドキュメント・フォーマットを指定するなら、プリンタは、仕事を中止して、形式が「形式が支えたドキュメント」プリンタ属性のメンバーですが、この理由を掲示するかもしれませんが、自動感じられたドキュメント・フォーマットの中に掲示するというわけではありません。 「ドキュメント・フォーマット」がREQUIRED操作属性であるので、この値をサポートしなければなりません。
Hastings, et al. Standards Track [Page 116] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[116ページ]: モデルと意味論2000年9月
'document-format-error': The job was aborted by the system because
the Printer encountered an error in the document-data while
processing it. If the Printer posts this reason, the
document-data has already passed any tests that would have led
to the 'unsupported-document-format' job-state-reason.
'processing-to-stop-point': The requester has issued a Cancel-Job
operation or the Printer object has aborted the job, but is
still performing some actions on the job until a specified stop
point occurs or job termination/cleanup is completed.
'ドキュメント形式誤り': Printerがそれを処理している間、ドキュメントデータにおける誤りに遭遇したので、仕事はシステムによって中止されました。 Printerポストであるなら、これは推論して、ドキュメントデータは既に'サポートされないドキュメント・フォーマット'仕事の州の理由につながったどんなテストにも合格しました。 '止まるために処理して、指してください': リクエスタがキャンセル仕事の操作を発行したか、Printerオブジェクトは、仕事を中止しましたが、指定された停止ポイントが起こるか、または仕事の終了/クリーンアップが完成するまで、まだ仕事へのいくつかの動作を実行しています。
If the implementation requires some measurable time to cancel
the job in the 'processing' or 'processing-stopped' job states,
the IPP object MUST use this value to indicate that the Printer
object is still performing some actions on the job while the
job remains in the 'processing' or 'processing-stopped' state.
After all the job's job description attributes have stopped
incrementing, the Printer object moves the job from the
'processing' state to the 'canceled' or
'aborted' job states.
実装が'処理'か'処理で止まっている'仕事の州で仕事を中止するいくらかの測定できる時間を必要とするなら、IPPオブジェクトは、仕事が'処理'か'処理で止まっている'州に残っている間Printerオブジェクトがまだ仕事へのいくつかの動作を実行しているのを示すのにこの値を使用しなければなりません。 結局、仕事の職務記述書属性は、増加するのを止めて、Printerオブジェクトは'処理'状態から'取り消された'か'中止になっている'仕事の州までの仕事を動かします。
'service-off-line': The Printer is off-line and accepting no
jobs. All 'pending' jobs are put into the 'pending-held'
state. This situation could be true if the service's or
document transform's input is impaired or broken.
'job-completed-successfully': The job completed successfully.
This value SHOULD be supported.
'job-completed-with-warnings': The job completed with warnings.
This value SHOULD be supported if the implementation detects
warnings.
'job-completed-with-errors': The job completed with errors (and
possibly warnings too). This value SHOULD be supported if the
implementation detects errors.
'job-restartable' - This job is retained (see section 4.3.7.2) and
is currently able to be restarted using the Restart-Job
operation (see section 3.3.7). If 'job-restartable' is a value
of the job's 'job-state-reasons' attribute, then the IPP object
MUST accept a Restart-Job operation for that job. This value
SHOULD be supported if the Restart-Job operation is supported.
'queued-in-device': The job has been forwarded to a device or
print system that is unable to send back status. The Printer
sets the job's "job-state " attribute to 'completed' and adds
the 'queued-in-device' value to the job's "job-state-reasons"
attribute to indicate that the Printer has no additional
information about the job and never will have any better
information. See section 4.3.7.1.
'オフラインサービス': Printerはオフラインであり、仕事を全く受け入れていません。 '未定に保持された'状態にすべての'未定'の仕事を入れます。 サービスかドキュメント変換の入力が損なわれるか、または知らせられるなら、この状況は本当であるかもしれません。 '首尾よく完了する仕事': 首尾よく完了する仕事。 これはSHOULDを評価します。サポートされます。 '警告で完了する仕事': 警告で完了する仕事。 これはSHOULDを評価します。実装が警告を検出するなら、サポートされます。 '誤りで完了する仕事': 誤り(そして、ことによると警告も)で完了する仕事。 これはSHOULDを評価します。実装が誤りを検出するなら、サポートされます。 '仕事-再開可能'--、この仕事が保有される、(.2が、)4.3に.7を区分するのを見る、現在、Restart-仕事の操作(セクション3.3.7を見る)を使用することで再開できます。 '仕事-再開可能'が仕事の'仕事の州の理由'属性の値であるなら、IPPオブジェクトはその仕事のためのRestart-仕事の操作を受け入れなければなりません。 これはSHOULDを評価します。Restart-仕事の操作がサポートされるなら、サポートされます。 'デバイスで列に並ばせられる': 状態を返送できないデバイスか印刷システムに仕事を送りました。 Printerは仕事の「仕事状態」属性を'完成'に設定して、Printerには仕事に関する追加情報が全くないのを示すために仕事の「仕事の州の理由」属性に'デバイスで列に並ばせられた'価値を高めて、どんなより良い情報も決して持たないでしょう。 .1にセクション4.3.7を見てください。
Hastings, et al. Standards Track [Page 117] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[117ページ]: モデルと意味論2000年9月
4.3.9 job-state-message (text(MAX))
4.3.9 仕事の州のメッセージ(テキスト(最大))
This attribute specifies information about the "job-state" and "job- state-reasons" attributes in human readable text. If the Printer object supports this attribute, the Printer object MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 3.1.4.1).
この属性は人間の読み込み可能なテキストの「仕事状態」と「仕事の州理由」属性の情報を指定します。 Printerオブジェクトがこの属性をサポートするなら、PrinterオブジェクトはPrinterの「サポートされた発生している自然な言語」属性によって特定された自然言語のどれかのこのメッセージを生成することができなければなりません(操作属性がセクション3.1.4で指定した「属性自然言語」.1を見てください)。
The value SHOULD NOT contain additional information not contained in the values of the "job-state" and "job-states-reasons" attributes, such as interpreter error information. Otherwise, application programs might attempt to parse the (localized text). For such additional information such as interpreter errors for application program consumption or specific document access errors, new attributes with keyword values, needs to be developed and registered.
値のSHOULD NOTは「仕事状態」と「仕事は理由を述べる」という属性の値に含まれなかった追加情報を含んでいます、インタプリタエラー情報などのように。 さもなければ、アプリケーション・プログラムが、分析するのを試みるかもしれない、(テキストであるとローカライズされます。) そのような追加情報のために、アプリケーション・プログラム消費か特定のドキュメントのためのインタプリタ誤りが誤りにアクセスするようなもの(キーワード値がある新しい属性)は、開発されて、登録される必要があります。
4.3.10 job-detailed-status-messages (1setOf text(MAX))
4.3.10 仕事はステータスメッセージを詳しく述べました。(1setOfテキスト(最大))
This attribute specifies additional detailed and technical information about the job. The Printer NEED NOT localize the message(s), since they are intended for use by the system administrator or other experienced technical persons. Localization might obscure the technical meaning of such messages. Clients MUST NOT attempt to parse the value of this attribute. See "job- document-access-errors" (section 4.3.11) for additional errors that a program can process.
この属性は仕事の追加詳細で技術的な情報を指定します。 Printerは、メッセージが(s)であるとローカライズする必要はありません、それらが使用のためにシステム管理者か他の経験豊富な技術人々によって意図されるので。 ローカライズはそのようなメッセージの技術的な意味をあいまいにするかもしれません。 クライアントは、この属性の値を分析するのを試みてはいけません。 プログラムが処理できる追加誤りのための「仕事のドキュメントアクセスエラー」(セクション4.3.11)を見てください。
4.3.11 job-document-access-errors (1setOf text(MAX))
4.3.11 仕事のドキュメントアクセスエラー(1setOfテキスト(最大))
This attribute provides additional information about each document access error for this job encountered by the Printer after it returned a response to the Print-URI or Send-URI operation and subsequently attempted to access document(s) supplied in the Print- URI or Send-URI operation. For errors in the protocol that is identified by the URI scheme in the "document-uri" operation attribute, such as 'http:' or 'ftp:', the error code is returned in parentheses, followed by the URI. For example:
この属性はPrint-URIかSend-URI操作への応答を返して、次にPrint URIかSend-URI操作で提供されたドキュメントにアクセスするのを試みた後にPrinterによって遭遇されたこの仕事のためのそれぞれのドキュメントアクセスエラーに関する追加情報を提供します。 「ドキュメント-uri」操作属性におけるURI体系によって特定されるプロトコルにおける、'http: ''ftpなどの誤りのために: 'エラーコードはURIがあとに続いた括弧で返されます。 例えば:
(404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf
(404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf
Most Internet protocols use decimal error codes (unlike IPP), so the ASCII error code representation is in decimal.
ほとんどのインターネットプロトコルが10進エラーコード(IPPと異なった)を使用するので、小数にはASCIIエラーコード表現があります。
Hastings, et al. Standards Track [Page 118] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[118ページ]: モデルと意味論2000年9月
4.3.12 number-of-documents (integer(0:MAX))
4.3.12 ドキュメントの数(整数(0: 最大))
This attribute indicates the number of documents in the job, i.e., the number of Send-Document, Send-URI, Print-Job, or Print-URI operations that the Printer has accepted for this job, regardless of whether the document data has reached the Printer object or not.
この属性は仕事における、ドキュメントの数を示します、すなわち、Printerがこの仕事のために受け入れたSend-ドキュメント、Send-URI、Print-仕事、またはPrint-URI操作の数、ドキュメントデータがPrinterオブジェクトに達したかどうかにかかわらず。
Implementations supporting the OPTIONAL Create-Job/Send- Document/Send-URI operations SHOULD support this attribute so that clients can query the number of documents in each job.
OPTIONAL Create-仕事が/であるとサポートする実装は、クライアントが各仕事における、ドキュメントの数について質問できるように、URIをドキュメント/発信させている操作SHOULDサポートにこの属性を送ります。
4.3.13 output-device-assigned (name(127))
4.3.13 割り当てられた出力デバイス((127))を命名してください。
This attribute identifies the output device to which the Printer object has assigned this job. If an output device implements an embedded Printer object, the Printer object NEED NOT set this attribute. If a print server implements a Printer object, the value MAY be empty (zero- length string) or not returned until the Printer object assigns an output device to the job. This attribute is particularly useful when a single Printer object supports multiple devices (so called "fan-out" - see section 2.1).
この属性はPrinterオブジェクトがこの仕事を割り当てた出力装置を特定します。 出力装置が埋め込まれたPrinterオブジェクトを実装するなら、Printerオブジェクトはこの属性を設定する必要はありません。 プリント・サーバがPrinterオブジェクトを実装するなら、Printerオブジェクトが出力装置を仕事に割り当てるまで、値は、空(無の長さのストリング)か返されないかもしれません。 単一のPrinterオブジェクトが複数のデバイス(したがって、「四方八方に広がってください」--セクション2.1を見ると呼ばれる)を支えるとき、この属性は特に役に立ちます。
4.3.14 Event Time Job Description Attributes
4.3.14 イベント時間職務記述書属性
This section defines the Job Description attributes that indicate the time at which certain events occur for a job. If the job event has not yet occurred, then the IPP object MUST return the 'no-value' out-of-band value (see the beginning of Section 4.1). The "time-at- xxx(integer)" attributes represent time as an 'integer' representing the number of seconds since the device was powered up (informally called "time ticks"). The "date-time-at-xxx(dateTime)" attributes represent time as 'dateTime' representing date and time (including an offset from UTC).
このセクションはあるイベントが仕事のために起こる時を示すJob記述属性を定義します。 仕事のイベントがまだ起こっていないなら、IPPオブジェクトは'値がありません'バンドで出ている値を返さなければなりません(セクション4.1の始まりを見てください)。 デバイス以来の秒数を表す「-xxx(整数)では、」 属性が'整数として時間を表す時'は(非公式に呼ばれた「タイム・チック」)に動かされました。 「xxxの日付の時間(dateTime)」属性は、日時(UTCからのオフセットを含んでいる)を表しながら、'dateTime'として時間を表します。
In order to populate these attributes, the Printer object copies the value(s) of the following Printer Description attributes at the time the event occurs:
これらの属性に居住するために、イベントが起こるとき、Printerオブジェクトは以下のPrinter記述属性の値をコピーします:
1. the value in the Printer's "printer-up-time" attribute for the
"time-at-xxx(integer)" attributes
1. 「xxxの時間(整数)」属性のためのPrinterの「プリンタ動作可能時間」属性における値
2. the value in the Printer's "printer-current-time" attribute for
the "date-time-at-xxx(dateTime)" attributes.
2. 「xxxの日付の時間(dateTime)」属性のためのPrinterの「プリンタ電流時間」属性における値。
If the Printer resets its "printer-up-time" attribute to 1 on power- up (see section 4.4.29) and has persistent jobs, then it MUST change all of jobs' "time-at-xxx(integer)" (time tick) job attributes whose events have occurred either to:
Printerがパワーに「プリンタ動作可能時間」属性を上がった状態で(セクション4.4.29を見ます)1にリセットして、永続的な仕事を持っているなら、それは以下のことのためにイベントが起こった仕事の「xxxの時間(整数)」(タイム・チック)仕事の属性のすべてを変えなければなりません。
Hastings, et al. Standards Track [Page 119] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[119ページ]: モデルと意味論2000年9月
1. 0 to indicate that the event happened before the most recent
power up OR
1. 0 イベントが最新のパワーの前にORに起こったのを示すために
2. the negative of the number of seconds before the most recent
power-up that the event took place, though the negative number
NEED NOT reflect the exact number of seconds.
2. イベントが取った最新のパワーアップすることの前の秒数の否定的は入賞します、負数が秒のはっきりした数を反映する必要はありませんが。
If a client queries a "time-at-xxx(integer)" time tick Job attribute and finds the value to be 0 or negative, the client MUST assume that the event occurred in some life other than the Printer's current life.
クライアントが「xxxの時間(整数)」タイム・チックについて質問するなら、Jobが、値が0であることが結果と考えて、わかるか、または否定的であることで、クライアントは、イベントがPrinterの現在の寿命以外の何らかの寿命で起こったと仮定しなければなりません。
Note: A Printer does not change the values of any "date-time-at- xxx(dateTime)" job attributes on power-up.
以下に注意してください。 Printerがいずれの値を変えない、「日付-時間、-、xxx、(dateTime) 」 パワーアップするところの仕事の属性。
4.3.14.1 time-at-creation (integer(MIN:MAX))
4.3.14.1作成における時間(整数(分(最大)))
This REQUIRED attribute indicates the time at which the Job object was created.
このREQUIRED属性はJobオブジェクトが作成された時を示します。
4.3.14.2 time-at-processing (integer(MIN:MAX))
4.3.14.2処理における時間(整数(分(最大)))
This REQUIRED attribute indicates the time at which the Job object first began processing after the create operation or the most recent Restart-Job operation. The out-of-band 'no-value' value is returned if the job has not yet been in the 'processing' state (see the beginning of Section 4.1).
このREQUIRED属性がJobオブジェクトが最初に処理し始めた時を示す、操作か最新のRestart-仕事の操作を作成してください。 仕事が'処理'状態にまだないなら(セクション4.1の始まりを見てください)、バンドで出ている'値がありません'値を返します。
4.3.14.3 time-at-completed (integer(MIN:MAX))
4.3.14.3、完成されて、調節します。(整数(分(最大)))
This REQUIRED attribute indicates the time at which the Job object completed (or was canceled or aborted). The out-of-band 'no-value' value is returned if the job has not yet completed, been canceled, or aborted (see the beginning of Section 4.1).
このREQUIRED属性はJobが完成していた状態で(または、取り消されたか、または中止されました)反対する時を示します。 仕事をまだ完了していないか、中止するか、または中止したなら(セクション4.1の始まりを見てください)、バンドで出ている'値がありません'値を返します。
4.3.14.4 job-printer-up-time (integer(1:MAX))
4.3.14.4 仕事のプリンタ動作可能時間(整数(1: 最大))
This REQUIRED Job Description attribute indicates the amount of time (in seconds) that the Printer implementation has been up and running. This attribute is an alias for the "printer-up-time" Printer Description attribute (see Section 4.4.29).
このREQUIRED Job記述属性はPrinter実装が活動していることの時間(秒の)を示します。 この属性は「プリンタ動作可能時間」Printer記述属性のための別名(セクション4.4.29を見る)です。
A client MAY request this attribute in a Get-Job-Attributes or Get- Jobs request and use the value returned in combination with other requested Event Time Job Description Attributes in order to display time attributes to a user. The difference between this attribute and the 'integer' value of a "time-at-xxx" attribute is the number of
クライアントは、Get仕事の属性かGet仕事の要求でこの属性を要求して、他の要求されたEvent Time Job記述Attributesと組み合わせて時間属性を表示するために返された値をユーザに使用するかもしれません。 この属性と「xxxの時間」属性の'整数'値の違いは数です。
Hastings, et al. Standards Track [Page 120] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[120ページ]: モデルと意味論2000年9月
seconds ago that the "time-at-xxx" event occurred. A client can compute the wall-clock time at which the "time-at-xxx" event occurred by subtracting this difference from the client's wall-clock time.
何秒も前、その「xxxの時間」イベントは起こりました。 クライアントは「xxxの時間」イベントがクライアントの柱時計時間からこの違いを引き算することによって起こった柱時計時を計算できます。
4.3.14.5 date-time-at-creation (dateTime)
4.3.14.5作成における日付の時間(dateTime)
This attribute indicates the date and time at which the Job object was created.
この属性はJobオブジェクトが作成された日時を示します。
4.3.14.6 date-time-at-processing (dateTime)
4.3.14.6処理における日付の時間(dateTime)
This attribute indicates the date and time at which the Job object first began processing after the create operation or the most recent Restart-Job operation.
この属性がJobオブジェクトが最初に処理し始めた日時を示す、操作か最新のRestart-仕事の操作を作成してください。
4.3.14.7 date-time-at-completed (dateTime)
4.3.14.7、完成されて、時間の日付を入れます。(dateTime)
This attribute indicates the date and time at which the Job object completed (or was canceled or aborted).
この属性はJobが完成していた状態で(または、取り消されたか、または中止されました)反対する日時を示します。
4.3.15 number-of-intervening-jobs (integer(0:MAX))
4.3.15 介入している仕事の数(整数(0: 最大))
This attribute indicates the number of jobs that are "ahead" of this job in the relative chronological order of expected time to complete (i.e., the current scheduled order). For efficiency, it is only necessary to calculate this value when an operation is performed that requests this attribute.
この属性は完成する予想された時間の相対的な年代順に「前方に」あるこの仕事の仕事の数を示します(すなわち、電流はオーダーの計画をしました)。 単に効率に、操作が実行されるとき、この値について計算するために、それがこの属性を要求するのが必要です。
4.3.16 job-message-from-operator (text(127))
4.3.16 オペレータからの仕事のメッセージ(テキスト(127))
This attribute provides a message from an operator, system administrator or "intelligent" process to indicate to the end user the reasons for modification or other management action taken on a job.
この属性は、変更か仕事に取られた他の管理活動の理由をエンドユーザに示すためにオペレータ、システム管理者または「知的な」プロセスからメッセージを提供します。
4.3.17 Job Size Attributes
4.3.17 仕事のサイズ属性
This sub-section defines job attributes that describe the size of the job. These attributes are not intended to be counters; they are intended to be useful routing and scheduling information if known. For these attributes, the Printer object may try to compute the value if it is not supplied in the create request. Even if the client does supply a value for these three attributes in the create request, the Printer object MAY choose to change the value if the Printer object is able to compute a value which is more accurate than the client supplied value. The Printer object may be able to determine the correct value for these attributes either right at job submission time or at any later point in time.
この小区分は仕事のサイズについて説明する仕事の属性を定義します。 これらの属性はカウンタであることを意図しません。 知られているなら、彼らは役に立つルーティングと情報の計画をすることを意図します。 それが中に供給されないならこれらの属性のために、Printer目的が値を計算しようとするかもしれない、要求を作成してください。 クライアントが中でこれらの3つの属性に値を供給する、要求を作成してください、そして、Printerオブジェクトがクライアントが値を供給したより正確なa値を計算できるなら、Printerオブジェクトは、値を変えるのを選んでもよいです。 Printerオブジェクトは時間内に、ちょうどジョブ依頼時、または、任意な後の点のこれらの属性のために正しい値を決定できるかもしれません。
Hastings, et al. Standards Track [Page 121] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[121ページ]: モデルと意味論2000年9月
4.3.17.1 job-k-octets (integer(0:MAX))
4.3.17.1 仕事のk八重奏(整数(0: 最大))
This attribute specifies the total size of the document(s) in K octets, i.e., in units of 1024 octets requested to be processed in the job. The value MUST be rounded up, so that a job between 1 and 1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2, etc.
この属性はK八重奏における、ドキュメントの総サイズを指定します、すなわち、仕事で処理されるよう要求された1024の八重奏のユニットで。 値を切り上げなければならないので、1、1025年から2048であるとして1と1024の八重奏の間の仕事を示さなければならないのは、2であるに違いありませんなど。
This value MUST NOT include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the value is independent of the implementation and indicates the size of the document(s) measured in K octets independent of the number of copies.
デバイスが仕事かドキュメントデータの上で複数のパスを作らないで複本を処理できるかどうかの如何にかかわらず出力が照合されるかどうかの如何にかかわらずこの値は「コピー」属性によって指定されたコピーの数によって寄付された倍数因子を含んではいけません。 したがって、値は、実装から独立していて、コピーの数の如何にかかわらずK八重奏で測定されたドキュメントのサイズを示します。
This value MUST also not include the multiplicative factor due to a copies instruction embedded in the document data. If the document data actually includes replications of the document data, this value will include such replication. In other words, this value is always the size of the source document data, rather than a measure of the hardcopy output to be produced.
また、この値は指示がドキュメントデータに埋め込んだコピーのため倍数因子を含んではいけません。 ドキュメントデータが実際にドキュメントデータの模写を含んでいると、この値はそのような模写を含むでしょう。 言い換えれば、いつもこの値はハードコピー出力が起こされる測定よりむしろソースドキュメントデータのサイズです。
4.3.17.2 job-impressions (integer(0:MAX))
4.3.17.2 仕事印象(整数(0: 最大))
This attribute specifies the total size in number of impressions of the document(s) being submitted (see the definition of impression in section 12.2.5).
この属性は提出されるドキュメントの印象の数における総サイズを指定します(セクション12.2.5における印象の定義を見てください)。
As with "job-k-octets", this value MUST NOT include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the value is independent of the implementation and reflects the size of the document(s) measured in impressions independent of the number of copies.
「仕事のk八重奏」なら、デバイスが仕事かドキュメントデータの上で複数のパスを作らないで複本を処理できるかどうかの如何にかかわらず出力が照合されるかどうかの如何にかかわらずこの値は「コピー」属性によって指定されたコピーの数によって寄付された倍数因子を含んではいけません。 したがって、値は、実装から独立していて、コピーの数の如何にかかわらず印象で測定されたドキュメントのサイズを反映します。
As with "job-k-octets", this value MUST also not include the multiplicative factor due to a copies instruction embedded in the document data. If the document data actually includes replications of the document data, this value will include such replication. In other words, this value is always the number of impressions in the source document data, rather than a measure of the number of impressions to be produced by the job.
「仕事のk八重奏」なら、また、この値は指示がドキュメントデータに埋め込んだコピーのため倍数因子を含んではいけません。 ドキュメントデータが実際にドキュメントデータの模写を含んでいると、この値はそのような模写を含むでしょう。 言い換えれば、いつもこの値は印象の数が仕事で生産される測定よりむしろソースドキュメントデータにおける印象の数です。
Hastings, et al. Standards Track [Page 122] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[122ページ]: モデルと意味論2000年9月
4.3.17.3 job-media-sheets (integer(0:MAX))
4.3.17.3 仕事のメディアシート(整数(0: 最大))
This attribute specifies the total number of media sheets to be produced for this job.
この属性は、この仕事のために生産されるためにメディアシートの総数を指定します。
Unlike the "job-k-octets" and the "job-impressions" attributes, this value MUST include the multiplicative factors contributed by the number of copies specified by the "copies" attribute and a 'number of copies' instruction embedded in the document data, if any. This difference allows the system administrator to control the lower and upper bounds of both (1) the size of the document(s) with "job-k- octets-supported" and "job-impressions-supported" and (2) the size of the job with "job-media-sheets-supported".
「仕事のk八重奏」と属性、この値が乗法的を含まなければならないという「仕事印象」と異なって、「コピー」属性によって指定されたコピーの数と指示がドキュメントデータに埋め込んだ'コピーの数'に従って、要素はもしあれば貢献しました。 この違いは「シートがサポートした仕事のメディア」で、より低く監督するシステム管理者と(1) 「仕事k八重奏でサポートされること」があるドキュメントのサイズと「印象がサポートした仕事」と(2)の両方の上限に仕事のサイズを許容します。
4.3.18 Job Progress Attributes
4.3.18 仕事の進歩属性
This sub-section defines job attributes that describe the progress of the job. These attributes are intended to be counters. That is, the value for a job that has not started processing MUST be 0. When the job's "job-state" is 'processing' or 'processing-stopped', this value is intended to contain the amount of the job that has been processed to the time at which the attributes are requested. When the job enters the 'completed', 'canceled', or 'aborted' states, these values are the final values for the job.
この小区分は仕事の進歩について説明する仕事の属性を定義します。 これらの属性はカウンタであることを意図します。 すなわち、処理し始めていない仕事のための値は0でなければなりません。 仕事の「仕事状態」が'処理する'か'処理で止まります'、この値が属性が要求される時まで処理された仕事の量を含むことを意図するということであるときに。 仕事が'完成した'か、'取り消された'か、'中止になっている'州に入るとき、これらの値は仕事のための検査値です。
4.3.18.1 job-k-octets-processed (integer(0:MAX))
4.3.18.1 仕事のk八重奏は処理されました。(整数(0: 最大))
This attribute specifies the total number of octets processed in K octets, i.e., in units of 1024 octets so far. The value MUST be rounded up, so that a job between 1 and 1024 octets inclusive MUST be indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc.
この属性は今までのところすなわち、K八重奏、1024の八重奏のユニットで処理されている八重奏の総数を指定します。 値を切り上げなければならないので、存在として1、1025年から2048に包括的に1と1024の八重奏の間で包括的な仕事を示さなければならないのは、2であるに違いありませんなど。
For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value MUST be equal to the value of the "job-k-octets" attribute. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value MUST be a multiple of the value of the "job-k-octets" attribute.
実装において、複本が単一のパスだけでインタプリタによってデータの上に生産されるところで検査値は「仕事のk八重奏」属性の値と等しいに違いありません。 実装のために、検査値は複本が各コピーのためのデータを処理することによってインタプリタによって生産されるところの「仕事のk八重奏」属性の価値の倍数でなければなりません。
4.3.18.2 job-impressions-completed (integer(0:MAX))
4.3.18.2 印象が完了した仕事(整数(0: 最大))
This job attribute specifies the number of impressions completed for the job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output.
この仕事の属性は今までのところ仕事のために終了している印象の数を指定します。 印刷デバイスに関しては、終了する印象は、出力を解釈して、マークして、積み重ねるのを含んでいます。
Hastings, et al. Standards Track [Page 123] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[123ページ]: モデルと意味論2000年9月
4.3.18.3 job-media-sheets-completed (integer(0:MAX))
4.3.18.3 シートが完成した仕事のメディア(整数(0: 最大))
This job attribute specifies the media-sheets completed marking and stacking for the entire job so far whether those sheets have been processed on one side or on both.
それらのシートが半面の上、または、両方の上で処理されたか否かに関係なく、この仕事の属性は今までのところ、仕事全体のための完成したメディアシートマークと積み重ねを指定します。
4.3.19 attributes-charset (charset)
4.3.19 属性-charset(charset)
This REQUIRED attribute is populated using the value in the client supplied "attributes-charset" attribute in the create request. It identifies the charset (coded character set and encoding method) used by any Job attributes with attribute syntax 'text' and 'name' that were supplied by the client in the create request. See Section 3.1.4 for a complete description of the "attributes-charset" operation attribute.
このREQUIRED属性がクライアントの値が「属性-charset」属性を供給した居住された使用である、要求を作成してください。 中の属性構文'テキスト'と'名前'がクライアントによって供給されていた状態でどんなJob属性によっても使用されるcharset(コード化文字集合とメソッドをコード化する)を特定する、要求を作成してください。 「属性-charset」操作属性の完全な記述に関してセクション3.1.4を見てください。
This attribute does not indicate the charset in which the 'text' and 'name' values are stored internally in the Job object. The internal charset is implementation-defined. The IPP object MUST convert from whatever the internal charset is to that being requested in an operation as specified in Section 3.1.4.
この属性は値という'テキスト'と'名前'がJobオブジェクトに内部的に保存されるcharsetを示しません。 内部のcharsetは実装で定義されています。 セクション3.1.4における指定されるとしての操作で要求されていて、IPPオブジェクトは内部のcharsetがことなら何でもであるか、そして、それまで変換されなければなりません。
4.3.20 attributes-natural-language (naturalLanguage)
4.3.20 属性自然言語(naturalLanguage)
This REQUIRED attribute is populated using the value in the client supplied "attributes-natural-language" attribute in the create request. It identifies the natural language used for any Job attributes with attribute syntax 'text' and 'name' that were supplied by the client in the create request. See Section 3.1.4 for a complete description of the "attributes-natural-language" operation attribute. See Sections 4.1.1.2 and 4.1.2.2 for how a Natural Language Override may be supplied explicitly for each 'text' and 'name' attribute value that differs from the value identified by the "attributes-natural-language" attribute.
このREQUIRED属性がクライアントの値が「属性自然言語」属性を供給した居住された使用である、要求を作成してください。 中の属性構文'テキスト'と'名前'がクライアントによって供給されていた状態でどんなJob属性にも使用される自然言語を特定する、要求を作成してください。 「属性自然言語」操作属性の完全な記述に関してセクション3.1.4を見てください。 そして、セクション4.1.1を見てください、.2、4.1 .2 どう明らかに各'テキスト'と'名前'にNatural Language Overrideを供給できるように.2は「属性自然言語」属性によって特定された値と異なっている値を結果と考えるか。
4.4 Printer Description Attributes
4.4 プリンタ記述属性
These attributes form the attribute group called "printer- description". The following table summarizes these attributes, their syntax, and whether or not they are REQUIRED for a Printer object to support. If they are not indicated as REQUIRED, they are OPTIONAL. The maximum size in octets for 'text' and 'name' attributes is indicated in parenthesizes.
これらの属性は「プリンタ記述」と呼ばれる属性グループを結成します。 以下のテーブルはこれらの属性、それらの構文をまとめます。そして、それらは支えるPrinterオブジェクトのためのREQUIREDであるかどうか REQUIREDとして示されないなら、それらはOPTIONALです。 'テキスト'と'名前'属性のための八重奏におけるサイズが示される最大はparenthesizesされます。
Note: How these attributes are set by an Administrator is outside the scope of this IPP/1.1 document.
以下に注意してください。 このIPP/1.1ドキュメントの範囲の外にこれらの属性がAdministratorによってどう設定されるかがあります。
Hastings, et al. Standards Track [Page 124] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[124ページ]: モデルと意味論2000年9月
+----------------------------+---------------------------+-----------+ | Attribute | Syntax | REQUIRED? | +----------------------------+---------------------------+-----------+ | printer-uri-supported | 1setOf uri | REQUIRED | +----------------------------+---------------------------+-----------+ | uri-security-supported | 1setOf type2 keyword | REQUIRED | +----------------------------+---------------------------+-----------+ | uri-authentication- | 1setOf type2 keyword | REQUIRED | | supported | | | +----------------------------+---------------------------+-----------+ | printer-name | name (127) | REQUIRED | +----------------------------+---------------------------+-----------+ | printer-location | text (127) | | +----------------------------+---------------------------+-----------+ | printer-info | text (127) | | +----------------------------+---------------------------+-----------+ | printer-more-info | uri | | +----------------------------+---------------------------+-----------+ | printer-driver-installer | uri | | +----------------------------+---------------------------+-----------+ | printer-make-and-model | text (127) | | +----------------------------+---------------------------+-----------+ | printer-more-info- | uri | | | manufacturer | | | +----------------------------+---------------------------+-----------+ | printer-state | type1 enum | REQUIRED | +----------------------------+---------------------------+-----------+ | printer-state-reasons | 1setOf type2 keyword | REQUIRED | +----------------------------+---------------------------+-----------+ | printer-state-message | text (MAX) | | +----------------------------+---------------------------+-----------+ | ipp-versions-supported | 1setOf type2 keyword | REQUIRED | +----------------------------+---------------------------+-----------+ | operations-supported | 1setOf type2 enum | REQUIRED | +----------------------------+---------------------------+-----------+ | multiple-document-jobs- | boolean | | | supported | | | +----------------------------+---------------------------+-----------+ | charset-configured | charset | REQUIRED | +----------------------------+---------------------------+-----------+ | charset-supported | 1setOf charset | REQUIRED | +----------------------------+---------------------------+-----------+ | natural-language-configured| naturalLanguage | REQUIRED | +----------------------------+---------------------------+-----------+ | generated-natural-language-| 1setOf naturalLanguage | REQUIRED | | supported | | | +----------------------------+---------------------------+-----------+ | document-format-default | mimeMediaType | REQUIRED |
+----------------------------+---------------------------+-----------+ | 属性| 構文| 必要ですか? | +----------------------------+---------------------------+-----------+ | uriが支えたプリンタ| 1setOf uri| 必要です。| +----------------------------+---------------------------+-----------+ | セキュリティがサポートしたuri| 1setOf type2キーワード| 必要です。| +----------------------------+---------------------------+-----------+ | uri-認証、-| 1setOf type2キーワード| 必要です。| | サポートされます。| | | +----------------------------+---------------------------+-----------+ | プリンタ名| 名前(127)| 必要です。| +----------------------------+---------------------------+-----------+ | プリンタ位置| テキスト(127)| | +----------------------------+---------------------------+-----------+ | プリンタインフォメーション| テキスト(127)| | +----------------------------+---------------------------+-----------+ | プリンタ詳しい情報| uri| | +----------------------------+---------------------------+-----------+ | プリンタドライバーインストーラ| uri| | +----------------------------+---------------------------+-----------+ | プリンタメーカーとモデル| テキスト(127)| | +----------------------------+---------------------------+-----------+ | よりプリンタ多くのインフォメーション、-| uri| | | メーカー| | | +----------------------------+---------------------------+-----------+ | プリンタ状態| type1 enum| 必要です。| +----------------------------+---------------------------+-----------+ | プリンタ州の理由| 1setOf type2キーワード| 必要です。| +----------------------------+---------------------------+-----------+ | プリンタ州のメッセージ| テキスト(MAX)| | +----------------------------+---------------------------+-----------+ | バージョンがサポートしたipp| 1setOf type2キーワード| 必要です。| +----------------------------+---------------------------+-----------+ | 操作で、サポートされます。| 1setOf type2 enum| 必要です。| +----------------------------+---------------------------+-----------+ | 複数のドキュメント仕事、-| 論理演算子| | | サポートされます。| | | +----------------------------+---------------------------+-----------+ | charsetによって構成されています。| charset| 必要です。| +----------------------------+---------------------------+-----------+ | charsetによってサポートされます。| 1setOf charset| 必要です。| +----------------------------+---------------------------+-----------+ | 構成された自然な言語| naturalLanguage| 必要です。| +----------------------------+---------------------------+-----------+ | 発生して当然の言語、-| 1setOf naturalLanguage| 必要です。| | サポートされます。| | | +----------------------------+---------------------------+-----------+ | ドキュメント形式デフォルト| mimeMediaType| 必要です。|
Hastings, et al. Standards Track [Page 125] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[125ページ]: モデルと意味論2000年9月
+----------------------------+---------------------------+-----------+ | document-format-supported | 1setOf mimeMediaType | REQUIRED | +----------------------------+---------------------------+-----------+ | printer-is-accepting-jobs | boolean | REQUIRED | +----------------------------+---------------------------+-----------+ | queued-job-count | integer (0:MAX) | REQUIRED | +----------------------------+---------------------------+-----------+ | printer-message-from- | text (127) | | | operator | | | +----------------------------+---------------------------+-----------+ | color-supported | boolean | | +----------------------------+---------------------------+-----------+ | reference-uri-schemes- | 1setOf uriScheme | | | supported | | | +----------------------------+---------------------------+-----------+ | pdl-override-supported | type2 keyword | REQUIRED | +----------------------------+---------------------------+-----------+ | printer-up-time | integer (1:MAX) | REQUIRED | +----------------------------+---------------------------+-----------+ | printer-current-time | dateTime | | +----------------------------+---------------------------+-----------+ | multiple-operation-time-out| integer (1:MAX) | | +----------------------------+---------------------------+-----------+ | compression-supported | 1setOf type3 keyword | REQUIRED | +----------------------------+---------------------------+-----------+ | job-k-octets-supported | rangeOfInteger (0:MAX) | | +----------------------------+---------------------------+-----------+ | job-impressions-supported | rangeOfInteger (0:MAX) | | +----------------------------+---------------------------+-----------+ | job-media-sheets-supported | rangeOfInteger (0:MAX) | | +----------------------------+---------------------------+-----------+ | pages-per-minute | integer(0:MAX) | | +----------------------------+---------------------------+-----------+ | pages-per-minute-color | integer(0:MAX) | | +----------------------------+---------------------------+-----------+
+----------------------------+---------------------------+-----------+ | 形式が支えたドキュメント| 1setOf mimeMediaType| 必要です。| +----------------------------+---------------------------+-----------+ | プリンタは仕事を受け入れています。| 論理演算子| 必要です。| +----------------------------+---------------------------+-----------+ | 列に並ばせられた仕事のカウント| 整数(0: MAX)| 必要です。| +----------------------------+---------------------------+-----------+ | プリンタメッセージ、-、-| テキスト(127)| | | オペレータ| | | +----------------------------+---------------------------+-----------+ | 色で、サポートされます。| 論理演算子| | +----------------------------+---------------------------+-----------+ | 参照-uri体系、-| 1setOf uriScheme| | | サポートされます。| | | +----------------------------+---------------------------+-----------+ | オーバーライドがサポートしたpdl| type2キーワード| 必要です。| +----------------------------+---------------------------+-----------+ | プリンタ動作可能時間| 整数(1: MAX)| 必要です。| +----------------------------+---------------------------+-----------+ | プリンタ電流時間| dateTime| | +----------------------------+---------------------------+-----------+ | 複数の操作タイムアウト| 整数(1: MAX)| | +----------------------------+---------------------------+-----------+ | 圧縮で、サポートされます。| 1setOf type3キーワード| 必要です。| +----------------------------+---------------------------+-----------+ | 八重奏がサポートした仕事k| rangeOfInteger(0: 最大)| | +----------------------------+---------------------------+-----------+ | 印象がサポートした仕事| rangeOfInteger(0: 最大)| | +----------------------------+---------------------------+-----------+ | シートがサポートした仕事のメディア| rangeOfInteger(0: 最大)| | +----------------------------+---------------------------+-----------+ | 1分あたりのページ| 整数(0: 最大)| | +----------------------------+---------------------------+-----------+ | 微小な色あたりのページ| 整数(0: 最大)| | +----------------------------+---------------------------+-----------+
4.4.1 printer-uri-supported (1setOf uri)
4.4.1 uriが支えたプリンタ(1setOf uri)
This REQUIRED Printer attribute contains at least one URI for the Printer object. It OPTIONALLY contains more than one URI for the Printer object. An administrator determines a Printer object's URI(s) and configures this attribute to contain those URIs by some means outside the scope of this IPP/1.1 document. The precise format of this URI is implementation dependent and depends on the protocol. See the next two sections for a description of the "uri-security- supported" and "uri-authentication-supported" attributes, both of
このREQUIRED Printer属性はPrinterオブジェクトのための少なくとも1つのURIを含んでいます。 それ、OPTIONALLYはPrinterオブジェクトのための1つ以上のURIを含んでいます。 管理者は、どうでもこのIPP/1.1ドキュメントの範囲の外にそれらのURIを保管するためにPrinterオブジェクトのURIを決定して、この属性を構成します。 このURIの正確な形式は、実装に依存していて、プロトコルに依存します。 「uriにセキュリティでサポートされること」と「認証がサポートしたuri」属性の記述に関して次の2つのセクションを見てください、両方
Hastings, et al. Standards Track [Page 126] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[126ページ]: モデルと意味論2000年9月
which are the REQUIRED companion attributes to this "printer-uri- supported" attribute. See section 2.4 on Printer object identity and section 8.2 on security and URIs for more information.
この「プリンタ-uriによってサポートしている」属性へのREQUIRED仲間属性です。 詳しい情報に関してPrinterオブジェクトのアイデンティティのセクション2.4とセキュリティとURIのセクション8.2を見てください。
4.4.2 uri-authentication-supported (1setOf type2 keyword)
4.4.2 認証がサポートしたuri(1setOf type2キーワード)
This REQUIRED Printer attribute MUST have the same cardinality (contain the same number of values) as the "printer-uri-supported" attribute. This attribute identifies the Client Authentication mechanism associated with each URI listed in the "printer-uri- supported" attribute. The Printer object uses the specified mechanism to identify the authenticated user (see section 8.3). The "i th" value in "uri-authentication-supported" corresponds to the "i th" value in "printer-uri-supported" and it describes the authentication mechanisms used by the Printer when accessed via that URI. See [RFC2910] for more details on Client Authentication.
このREQUIRED Printer属性に、「uriが支えたプリンタ」属性として同じ基数がなければなりません(同じ数の値を含んでいます)。 この属性は「プリンタ-uriによってサポートしている」属性で記載されている各URIに関連しているClient Authenticationメカニズムを特定します。 Printerオブジェクトは、認証されたユーザを特定するのに指定されたメカニズムを使用します(セクション8.3を見てください)。 「i、」 「認証がサポートしたuri」の値が第対応している、「i、」 「uriが支えたプリンタ」とそれの値はそのURIでアクセスされるとPrinterによって使用された認証機構について第説明します。 Client Authenticationに関するその他の詳細に関して[RFC2910]を見てください。
The following standard keyword values are defined:
以下の標準のキーワード値は定義されます:
'none': There is no authentication mechanism associated with the
URI. The Printer object assumes that the authenticated user is
"anonymous".
'requesting-user-name': When a client performs an operation whose
target is the associated URI, the Printer object assumes that
the authenticated user is specified by the "requesting-user-
name" Operation attribute (see section 8.3). If the
"requesting-user-name" attribute is absent in a request, the
Printer object assumes that the authenticated user is
"anonymous".
'basic': When a client performs an operation whose target is the
associated URI, the Printer object challenges the client with
HTTP basic authentication [RFC2617]. The Printer object assumes
that the authenticated user is the name received via the basic
authentication mechanism.
'digest': When a client performs an operation whose target is the
associated URI, the Printer object challenges the client with
HTTP digest authentication [RFC2617]. The Printer object
assumes that the authenticated user is the name received via
the digest authentication mechanism.
'certificate': When a client performs an operation whose target is
the associated URI, the Printer object expects the client to
provide a certificate. The Printer object assumes that the
authenticated user is the textual name contained within the
certificate.
'none': There is no authentication mechanism associated with the URI. The Printer object assumes that the authenticated user is "anonymous". 'requesting-user-name': When a client performs an operation whose target is the associated URI, the Printer object assumes that the authenticated user is specified by the "requesting-user- name" Operation attribute (see section 8.3). If the "requesting-user-name" attribute is absent in a request, the Printer object assumes that the authenticated user is "anonymous". 'basic': When a client performs an operation whose target is the associated URI, the Printer object challenges the client with HTTP basic authentication [RFC2617]. The Printer object assumes that the authenticated user is the name received via the basic authentication mechanism. 'digest': When a client performs an operation whose target is the associated URI, the Printer object challenges the client with HTTP digest authentication [RFC2617]. The Printer object assumes that the authenticated user is the name received via the digest authentication mechanism. 'certificate': When a client performs an operation whose target is the associated URI, the Printer object expects the client to provide a certificate. The Printer object assumes that the authenticated user is the textual name contained within the certificate.
Hastings, et al. Standards Track [Page 127] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 127] RFC 2911 IPP/1.1: Model and Semantics September 2000
4.4.3 uri-security-supported (1setOf type2 keyword)
4.4.3 uri-security-supported (1setOf type2 keyword)
This REQUIRED Printer attribute MUST have the same cardinality (contain the same number of values) as the "printer-uri-supported" attribute. This attribute identifies the security mechanisms used for each URI listed in the "printer-uri-supported" attribute. The "i th" value in "uri-security-supported" corresponds to the "i th" value in "printer-uri-supported" and it describes the security mechanisms used for accessing the Printer object via that URI. See [RFC2910] for more details on security mechanisms.
This REQUIRED Printer attribute MUST have the same cardinality (contain the same number of values) as the "printer-uri-supported" attribute. This attribute identifies the security mechanisms used for each URI listed in the "printer-uri-supported" attribute. The "i th" value in "uri-security-supported" corresponds to the "i th" value in "printer-uri-supported" and it describes the security mechanisms used for accessing the Printer object via that URI. See [RFC2910] for more details on security mechanisms.
The following standard keyword values are defined:
The following standard keyword values are defined:
'none': There are no secure communication channel protocols in use
for the given URI.
'ssl3': SSL3 [SSL] is the secure communications channel protocol
in use for the given URI.
'tls': TLS [RFC2246] is the secure communications channel
protocol in use for the given URI.
'none': There are no secure communication channel protocols in use for the given URI. 'ssl3': SSL3 [SSL] is the secure communications channel protocol in use for the given URI. 'tls': TLS [RFC2246] is the secure communications channel protocol in use for the given URI.
This attribute is orthogonal to the definition of a Client Authentication mechanism. Specifically, 'none' does not exclude Client Authentication. See section 4.4.2.
This attribute is orthogonal to the definition of a Client Authentication mechanism. Specifically, 'none' does not exclude Client Authentication. See section 4.4.2.
Consider the following example. For a single Printer object, an administrator configures the "printer-uri-supported", "uri- authentication-supported" and "uri-security-supported" attributes as follows:
Consider the following example. For a single Printer object, an administrator configures the "printer-uri-supported", "uri- authentication-supported" and "uri-security-supported" attributes as follows:
"printer-uri-supported": 'xxx://acme.com/open-use-printer',
'xxx://acme.com/restricted-use-printer',
'xxx://acme.com/private-printer'
"uri-authentication-supported": 'none', 'digest', 'basic'
"uri-security-supported": 'none', 'none', 'tls'
"printer-uri-supported": 'xxx://acme.com/open-use-printer', 'xxx://acme.com/restricted-use-printer', 'xxx://acme.com/private-printer' "uri-authentication-supported": 'none', 'digest', 'basic' "uri-security-supported": 'none', 'none', 'tls'
Note: 'xxx' is not a valid scheme. See the IPP/1.1 "Transport and Encoding" document [RFC2910] for the actual URI schemes to be used in object target attributes.
Note: 'xxx' is not a valid scheme. See the IPP/1.1 "Transport and Encoding" document [RFC2910] for the actual URI schemes to be used in object target attributes.
In this case, one Printer object has three URIs.
In this case, one Printer object has three URIs.
- For the first URI, 'xxx://acme.com/open-use-printer', the value
'none' in "uri-security-supported" indicates that there is no
secure channel protocol configured to run under HTTP. The value
of 'none' in "uri-authentication-supported" indicates that all
users are 'anonymous'. There will be no challenge and the
Printer will ignore "requesting-user-name".
- For the first URI, 'xxx://acme.com/open-use-printer', the value 'none' in "uri-security-supported" indicates that there is no secure channel protocol configured to run under HTTP. The value of 'none' in "uri-authentication-supported" indicates that all users are 'anonymous'. There will be no challenge and the Printer will ignore "requesting-user-name".
Hastings, et al. Standards Track [Page 128] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 128] RFC 2911 IPP/1.1: Model and Semantics September 2000
- For the second URI, 'xxx://acme.com/restricted-use-printer', the
value 'none' in "uri-security-supported" indicates that there is
no secure channel protocol configured to run under HTTP. The
value of 'digest' in "uri-authentication-supported" indicates
that the Printer will issue a challenge and that the Printer
will use the name supplied by the digest mechanism to determine
the authenticated user (see section 8.3).
- For the third URI, 'xxx://acme.com/private-printer', the value
'tls' in "uri-security-supported" indicates that TLS is being
used to secure the channel. The client SHOULD be prepared to
use TLS framing to negotiate an acceptable ciphersuite to use
while communicating with the Printer object. In this case, the
name implies the use of a secure communications channel, but the
fact is made explicit by the presence of the 'tls' value in
"uri-security-supported". The client does not need to resort to
understanding which security it must use by following naming
conventions or by parsing the URI to determine which security
mechanisms are implied. The value of 'basic' in "uri-
authentication-supported" indicates that the Printer will issue
a challenge and that the Printer will use the name supplied by
the digest mechanism to determine the authenticated user (see
section 8.3). Because this challenge occurs in a tls session,
the channel is secure.
- For the second URI, 'xxx://acme.com/restricted-use-printer', the value 'none' in "uri-security-supported" indicates that there is no secure channel protocol configured to run under HTTP. The value of 'digest' in "uri-authentication-supported" indicates that the Printer will issue a challenge and that the Printer will use the name supplied by the digest mechanism to determine the authenticated user (see section 8.3). - For the third URI, 'xxx://acme.com/private-printer', the value 'tls' in "uri-security-supported" indicates that TLS is being used to secure the channel. The client SHOULD be prepared to use TLS framing to negotiate an acceptable ciphersuite to use while communicating with the Printer object. In this case, the name implies the use of a secure communications channel, but the fact is made explicit by the presence of the 'tls' value in "uri-security-supported". The client does not need to resort to understanding which security it must use by following naming conventions or by parsing the URI to determine which security mechanisms are implied. The value of 'basic' in "uri- authentication-supported" indicates that the Printer will issue a challenge and that the Printer will use the name supplied by the digest mechanism to determine the authenticated user (see section 8.3). Because this challenge occurs in a tls session, the channel is secure.
It is expected that many IPP Printer objects will be configured to support only one channel (either configured to use TLS access or not) and only one authentication mechanism. Such Printer objects only have one URI listed in the "printer-uri-supported" attribute. No matter the configuration of the Printer object (whether it has only one URI or more than one URI), a client MUST supply only one URI in the target "printer-uri" operation attribute.
It is expected that many IPP Printer objects will be configured to support only one channel (either configured to use TLS access or not) and only one authentication mechanism. Such Printer objects only have one URI listed in the "printer-uri-supported" attribute. No matter the configuration of the Printer object (whether it has only one URI or more than one URI), a client MUST supply only one URI in the target "printer-uri" operation attribute.
4.4.4 printer-name (name(127))
4.4.4 printer-name (name(127))
This REQUIRED Printer attribute contains the name of the Printer object. It is a name that is more end-user friendly than a URI. An administrator determines a printer's name and sets this attribute to that name. This name may be the last part of the printer's URI or it may be unrelated. In non-US-English locales, a name may contain characters that are not allowed in a URI.
This REQUIRED Printer attribute contains the name of the Printer object. It is a name that is more end-user friendly than a URI. An administrator determines a printer's name and sets this attribute to that name. This name may be the last part of the printer's URI or it may be unrelated. In non-US-English locales, a name may contain characters that are not allowed in a URI.
4.4.5 printer-location (text(127))
4.4.5 printer-location (text(127))
This Printer attribute identifies the location of the device. This could include things like: "in Room 123A, second floor of building XYZ".
This Printer attribute identifies the location of the device. This could include things like: "in Room 123A, second floor of building XYZ".
Hastings, et al. Standards Track [Page 129] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 129] RFC 2911 IPP/1.1: Model and Semantics September 2000
4.4.6 printer-info (text(127))
4.4.6 printer-info (text(127))
This Printer attribute identifies the descriptive information about this Printer object. This could include things like: "This printer can be used for printing color transparencies for HR presentations", or "Out of courtesy for others, please print only small (1-5 page) jobs at this printer", or even "This printer is going away on July 1, 1997, please find a new printer".
This Printer attribute identifies the descriptive information about this Printer object. This could include things like: "This printer can be used for printing color transparencies for HR presentations", or "Out of courtesy for others, please print only small (1-5 page) jobs at this printer", or even "This printer is going away on July 1, 1997, please find a new printer".
4.4.7 printer-more-info (uri)
4.4.7 printer-more-info (uri)
This Printer attribute contains a URI used to obtain more information about this specific Printer object. For example, this could be an HTTP type URI referencing an HTML page accessible to a Web Browser. The information obtained from this URI is intended for end user consumption. Features outside the scope of IPP can be accessed from this URI. The information is intended to be specific to this printer instance and site specific services (e.g. job pricing, services offered, end user assistance). The device manufacturer may initially populate this attribute.
This Printer attribute contains a URI used to obtain more information about this specific Printer object. For example, this could be an HTTP type URI referencing an HTML page accessible to a Web Browser. The information obtained from this URI is intended for end user consumption. Features outside the scope of IPP can be accessed from this URI. The information is intended to be specific to this printer instance and site specific services (e.g. job pricing, services offered, end user assistance). The device manufacturer may initially populate this attribute.
4.4.8 printer-driver-installer (uri)
4.4.8 printer-driver-installer (uri)
This Printer attribute contains a URI to use to locate the driver installer for this Printer object. This attribute is intended for consumption by automata. The mechanics of print driver installation is outside the scope of this IPP/1.1 document. The device manufacturer may initially populate this attribute.
This Printer attribute contains a URI to use to locate the driver installer for this Printer object. This attribute is intended for consumption by automata. The mechanics of print driver installation is outside the scope of this IPP/1.1 document. The device manufacturer may initially populate this attribute.
4.4.9 printer-make-and-model (text(127))
4.4.9 printer-make-and-model (text(127))
This Printer attribute identifies the make and model of the device. The device manufacturer may initially populate this attribute.
This Printer attribute identifies the make and model of the device. The device manufacturer may initially populate this attribute.
4.4.10 printer-more-info-manufacturer (uri)
4.4.10 printer-more-info-manufacturer (uri)
This Printer attribute contains a URI used to obtain more information about this type of device. The information obtained from this URI is intended for end user consumption. Features outside the scope of IPP can be accessed from this URI (e.g., latest firmware, upgrades, print drivers, optional features available, details on color support). The information is intended to be germane to this printer without regard to site specific modifications or services. The device manufacturer may initially populate this attribute.
This Printer attribute contains a URI used to obtain more information about this type of device. The information obtained from this URI is intended for end user consumption. Features outside the scope of IPP can be accessed from this URI (e.g., latest firmware, upgrades, print drivers, optional features available, details on color support). The information is intended to be germane to this printer without regard to site specific modifications or services. The device manufacturer may initially populate this attribute.
Hastings, et al. Standards Track [Page 130] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 130] RFC 2911 IPP/1.1: Model and Semantics September 2000
4.4.11 printer-state (type1 enum)
4.4.11 printer-state (type1 enum)
This REQUIRED Printer attribute identifies the current state of the device. The "printer-state reasons" attribute augments the "printer-state" attribute to give more detailed information about the Printer in the given printer state.
This REQUIRED Printer attribute identifies the current state of the device. The "printer-state reasons" attribute augments the "printer-state" attribute to give more detailed information about the Printer in the given printer state.
A Printer object need only update this attribute before responding to an operation which requests the attribute; the Printer object NEED NOT update this attribute continually, since asynchronous event notification is not part of IPP/1.1. A Printer NEED NOT implement all values if they are not applicable to a given implementation.
A Printer object need only update this attribute before responding to an operation which requests the attribute; the Printer object NEED NOT update this attribute continually, since asynchronous event notification is not part of IPP/1.1. A Printer NEED NOT implement all values if they are not applicable to a given implementation.
The following standard enum values are defined:
The following standard enum values are defined:
Value Symbolic Name and Description
Value Symbolic Name and Description
'3' 'idle': Indicates that new jobs can start processing without
waiting.
'4' 'processing': Indicates that jobs are processing; new jobs
will wait before processing.
'5' 'stopped': Indicates that no jobs can be processed and
intervention is required.
'3' 'idle': Indicates that new jobs can start processing without waiting. '4' 'processing': Indicates that jobs are processing; new jobs will wait before processing. '5' 'stopped': Indicates that no jobs can be processed and intervention is required.
Values of "printer-state-reasons", such as 'spool-area-full' and 'stopped-partly', MAY be used to provide further information.
Values of "printer-state-reasons", such as 'spool-area-full' and 'stopped-partly', MAY be used to provide further information.
4.4.12 printer-state-reasons (1setOf type2 keyword)
4.4.12 printer-state-reasons (1setOf type2 keyword)
This REQUIRED Printer attribute supplies additional detail about the device's state. Some of the these value definitions indicate conformance requirements; the rest are OPTIONAL.
This REQUIRED Printer attribute supplies additional detail about the device's state. Some of the these value definitions indicate conformance requirements; the rest are OPTIONAL.
Each keyword value MAY have a suffix to indicate its level of severity. The three levels are: report (least severe), warning, and error (most severe).
Each keyword value MAY have a suffix to indicate its level of severity. The three levels are: report (least severe), warning, and error (most severe).
- '-report': This suffix indicates that the reason is a "report".
An implementation may choose to omit some or all reports. Some
reports specify finer granularity about the printer state;
others serve as a precursor to a warning. A report MUST contain
nothing that could affect the printed output.
- '-warning': This suffix indicates that the reason is a
"warning". An implementation may choose to omit some or all
warnings. Warnings serve as a precursor to an error. A warning
MUST contain nothing that prevents a job from completing, though
in some cases the output may be of lower quality.
- '-report': This suffix indicates that the reason is a "report". An implementation may choose to omit some or all reports. Some reports specify finer granularity about the printer state; others serve as a precursor to a warning. A report MUST contain nothing that could affect the printed output. - '-warning': This suffix indicates that the reason is a "warning". An implementation may choose to omit some or all warnings. Warnings serve as a precursor to an error. A warning MUST contain nothing that prevents a job from completing, though in some cases the output may be of lower quality.
Hastings, et al. Standards Track [Page 131] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 131] RFC 2911 IPP/1.1: Model and Semantics September 2000
- '-error': This suffix indicates that the reason is an "error".
An implementation MUST include all errors. If this attribute
contains one or more errors, printer MUST be in the stopped
state.
- '-error': This suffix indicates that the reason is an "error". An implementation MUST include all errors. If this attribute contains one or more errors, printer MUST be in the stopped state.
If the implementation does not add any one of the three suffixes, all parties MUST assume that the reason is an "error".
If the implementation does not add any one of the three suffixes, all parties MUST assume that the reason is an "error".
If a Printer object controls more than one output device, each value of this attribute MAY apply to one or more of the output devices. An error on one output device that does not stop the Printer object as a whole MAY appear as a warning in the Printer's "printer-state-reasons attribute". If the "printer-state" for such a Printer has a value of 'stopped', then there MUST be an error reason among the values in the "printer-state-reasons" attribute.
If a Printer object controls more than one output device, each value of this attribute MAY apply to one or more of the output devices. An error on one output device that does not stop the Printer object as a whole MAY appear as a warning in the Printer's "printer-state-reasons attribute". If the "printer-state" for such a Printer has a value of 'stopped', then there MUST be an error reason among the values in the "printer-state-reasons" attribute.
The following standard keyword values are defined:
The following standard keyword values are defined:
'other': The device has detected an error other than one listed in
this document.
'none': There are not reasons. This state reason is semantically
equivalent to "printer-state-reasons" without any value and
MUST be used, since the 1setOf attribute syntax requires at
least one value.
'media-needed': A tray has run out of media.
'media-jam': The device has a media jam.
'moving-to-paused': Someone has paused the Printer object using
the Pause-Printer operation (see section 3.2.7) or other means,
but the device(s) are taking an appreciable time to stop.
Later, when all output has stopped, the "printer-state" becomes
'stopped', and the 'paused' value replaces the 'moving-to-
paused' value in the "printer-state-reasons" attribute. This
value MUST be supported, if the Pause-Printer operation is
supported and the implementation takes significant time to
pause a device in certain circumstances.
'paused': Someone has paused the Printer object using the Pause-
Printer operation (see section 3.2.7) or other means and the
Printer object's "printer-state" is 'stopped'. In this state,
a Printer MUST NOT produce printed output, but it MUST perform
other operations requested by a client. If a Printer had been
printing a job when the Printer was paused, the Printer MUST
resume printing that job when the Printer is no longer paused
and leave no evidence in the printed output of such a pause.
This value MUST be supported, if the Pause-Printer operation is
supported.
'shutdown': Someone has removed a Printer object from service, and
the device may be powered down or physically removed. In this
state, a Printer object MUST NOT produce printed output, and
'other': The device has detected an error other than one listed in this document. 'none': There are not reasons. This state reason is semantically equivalent to "printer-state-reasons" without any value and MUST be used, since the 1setOf attribute syntax requires at least one value. 'media-needed': A tray has run out of media. 'media-jam': The device has a media jam. 'moving-to-paused': Someone has paused the Printer object using the Pause-Printer operation (see section 3.2.7) or other means, but the device(s) are taking an appreciable time to stop. Later, when all output has stopped, the "printer-state" becomes 'stopped', and the 'paused' value replaces the 'moving-to- paused' value in the "printer-state-reasons" attribute. This value MUST be supported, if the Pause-Printer operation is supported and the implementation takes significant time to pause a device in certain circumstances. 'paused': Someone has paused the Printer object using the Pause- Printer operation (see section 3.2.7) or other means and the Printer object's "printer-state" is 'stopped'. In this state, a Printer MUST NOT produce printed output, but it MUST perform other operations requested by a client. If a Printer had been printing a job when the Printer was paused, the Printer MUST resume printing that job when the Printer is no longer paused and leave no evidence in the printed output of such a pause. This value MUST be supported, if the Pause-Printer operation is supported. 'shutdown': Someone has removed a Printer object from service, and the device may be powered down or physically removed. In this state, a Printer object MUST NOT produce printed output, and
Hastings, et al. Standards Track [Page 132] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 132] RFC 2911 IPP/1.1: Model and Semantics September 2000
unless the Printer object is realized by a print server that is
still active, the Printer object MUST perform no other
operations requested by a client, including returning this
value. If a Printer object had been printing a job when it was
shutdown, the Printer NEED NOT resume printing that job when
the Printer is no longer shutdown. If the Printer resumes
printing such a job, it may leave evidence in the printed
output of such a shutdown, e.g. the part printed before the
shutdown may be printed a second time after the shutdown.
'connecting-to-device': The Printer object has scheduled a job on
the output device and is in the process of connecting to a
shared network output device (and might not be able to actually
start printing the job for an arbitrarily long time depending
on the usage of the output device by other servers on the
network).
'timed-out': The server was able to connect to the output device
(or is always connected), but was unable to get a response from
the output device.
'stopping': The Printer object is in the process of stopping the
device and will be stopped in a while. When the device is
stopped, the Printer object will change the Printer object's
state to 'stopped'. The 'stopping-warning' reason is never an
error, even for a Printer with a single output device. When an
output-device ceases accepting jobs, the Printer will have this
reason while the output device completes printing.
'stopped-partly': When a Printer object controls more than one
output device, this reason indicates that one or more output
devices are stopped. If the reason is a report, fewer than
half of the output devices are stopped. If the reason is a
warning, fewer than all of the output devices are stopped.
'toner-low': The device is low on toner.
'toner-empty': The device is out of toner.
'spool-area-full': The limit of persistent storage allocated for
spooling has been reached. The Printer is temporarily unable
to accept more jobs. The Printer will remove this value when
it is able to accept more jobs. This value SHOULD be used by a
non-spooling Printer that only accepts one or a small number
jobs at a time or a spooling Printer that has filled the spool
space.
'cover-open': One or more covers on the device are open.
'interlock-open': One or more interlock devices on the printer are
unlocked.
'door-open': One or more doors on the device are open.
'input-tray-missing': One or more input trays are not in the
device.
'media-low': At least one input tray is low on media.
'media-empty': At least one input tray is empty.
unless the Printer object is realized by a print server that is still active, the Printer object MUST perform no other operations requested by a client, including returning this value. If a Printer object had been printing a job when it was shutdown, the Printer NEED NOT resume printing that job when the Printer is no longer shutdown. If the Printer resumes printing such a job, it may leave evidence in the printed output of such a shutdown, e.g. the part printed before the shutdown may be printed a second time after the shutdown. 'connecting-to-device': The Printer object has scheduled a job on the output device and is in the process of connecting to a shared network output device (and might not be able to actually start printing the job for an arbitrarily long time depending on the usage of the output device by other servers on the network). 'timed-out': The server was able to connect to the output device (or is always connected), but was unable to get a response from the output device. 'stopping': The Printer object is in the process of stopping the device and will be stopped in a while. When the device is stopped, the Printer object will change the Printer object's state to 'stopped'. The 'stopping-warning' reason is never an error, even for a Printer with a single output device. When an output-device ceases accepting jobs, the Printer will have this reason while the output device completes printing. 'stopped-partly': When a Printer object controls more than one output device, this reason indicates that one or more output devices are stopped. If the reason is a report, fewer than half of the output devices are stopped. If the reason is a warning, fewer than all of the output devices are stopped. 'toner-low': The device is low on toner. 'toner-empty': The device is out of toner. 'spool-area-full': The limit of persistent storage allocated for spooling has been reached. The Printer is temporarily unable to accept more jobs. The Printer will remove this value when it is able to accept more jobs. This value SHOULD be used by a non-spooling Printer that only accepts one or a small number jobs at a time or a spooling Printer that has filled the spool space. 'cover-open': One or more covers on the device are open. 'interlock-open': One or more interlock devices on the printer are unlocked. 'door-open': One or more doors on the device are open. 'input-tray-missing': One or more input trays are not in the device. 'media-low': At least one input tray is low on media. 'media-empty': At least one input tray is empty.
Hastings, et al. Standards Track [Page 133] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 133] RFC 2911 IPP/1.1: Model and Semantics September 2000
'output-tray-missing': One or more output trays are not in the
device
'output-area-almost-full': One or more output area is almost full
(e.g. tray, stacker, collator).
'output-area-full': One or more output area is full. (e.g. tray,
stacker, collator)
'marker-supply-low': The device is low on at least one marker
supply. (e.g. toner, ink, ribbon)
'marker-supply-empty: The device is out of at least one marker
supply. (e.g. toner, ink, ribbon)
'marker-waste-almost-full': The device marker supply waste
receptacle is almost full.
'marker-waste-full': The device marker supply waste receptacle is
full.
'fuser-over-temp': The fuser temperature is above normal.
'fuser-under-temp': The fuser temperature is below normal.
'opc-near-eol': The optical photo conductor is near end of life.
'opc-life-over': The optical photo conductor is no longer
functioning.
'developer-low': The device is low on developer.
'developer-empty: The device is out of developer.
'interpreter-resource-unavailable': An interpreter resource is
unavailable (i.e. font, form)
'output-tray-missing': One or more output trays are not in the device 'output-area-almost-full': One or more output area is almost full (e.g. tray, stacker, collator). 'output-area-full': One or more output area is full. (e.g. tray, stacker, collator) 'marker-supply-low': The device is low on at least one marker supply. (e.g. toner, ink, ribbon) 'marker-supply-empty: The device is out of at least one marker supply. (e.g. toner, ink, ribbon) 'marker-waste-almost-full': The device marker supply waste receptacle is almost full. 'marker-waste-full': The device marker supply waste receptacle is full. 'fuser-over-temp': The fuser temperature is above normal. 'fuser-under-temp': The fuser temperature is below normal. 'opc-near-eol': The optical photo conductor is near end of life. 'opc-life-over': The optical photo conductor is no longer functioning. 'developer-low': The device is low on developer. 'developer-empty: The device is out of developer. 'interpreter-resource-unavailable': An interpreter resource is unavailable (i.e. font, form)
4.4.13 printer-state-message (text(MAX))
4.4.13 printer-state-message (text(MAX))
This Printer attribute specifies information about the "printer- state" and "printer-state-reasons" attributes in human readable text. If the Printer object supports this attribute, the Printer object MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 3.1.4.1).
This Printer attribute specifies information about the "printer- state" and "printer-state-reasons" attributes in human readable text. If the Printer object supports this attribute, the Printer object MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 3.1.4.1).
4.4.14 ipp-versions-supported (1setOf type2 keyword)
4.4.14 ipp-versions-supported (1setOf type2 keyword)
This REQUIRED attribute identifies the IPP protocol version(s) that this Printer supports, including major and minor versions, i.e., the version numbers for which this Printer implementation meets the conformance requirements. For version number validation, the Printer matches the (two-octet binary) "version-number" parameter supplied by the client in each request (see sections 3.1.1 and 3.1.8) with the (US-ASCII) keyword values of this attribute.
This REQUIRED attribute identifies the IPP protocol version(s) that this Printer supports, including major and minor versions, i.e., the version numbers for which this Printer implementation meets the conformance requirements. For version number validation, the Printer matches the (two-octet binary) "version-number" parameter supplied by the client in each request (see sections 3.1.1 and 3.1.8) with the (US-ASCII) keyword values of this attribute.
Hastings, et al. Standards Track [Page 134] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 134] RFC 2911 IPP/1.1: Model and Semantics September 2000
The following standard keyword values are defined:
The following standard keyword values are defined:
'1.0': Meets the conformance requirement of IPP version 1.0 as
specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565]
including any extensions registered according to Section 6 and
any extension defined in this version or any future version of
the IPP "Model and Semantics" document or the IPP "Encoding and
Transport" document following the rules, if any, when the
"version-number" parameter is '1.0'.
'1.1': Meets the conformance requirement of IPP version 1.1 as
specified in this document and [RFC2910] including any
extensions registered according to Section 6 and any extension
defined in any future versions of the IPP "Model and Semantics"
document or the IPP Encoding and Transport document following
the rules, if any, when the "version-number" parameter is
'1.1'.
'1.0': Meets the conformance requirement of IPP version 1.0 as specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565] including any extensions registered according to Section 6 and any extension defined in this version or any future version of the IPP "Model and Semantics" document or the IPP "Encoding and Transport" document following the rules, if any, when the "version-number" parameter is '1.0'. '1.1': Meets the conformance requirement of IPP version 1.1 as specified in this document and [RFC2910] including any extensions registered according to Section 6 and any extension defined in any future versions of the IPP "Model and Semantics" document or the IPP Encoding and Transport document following the rules, if any, when the "version-number" parameter is '1.1'.
4.4.15 operations-supported (1setOf type2 enum)
4.4.15 operations-supported (1setOf type2 enum)
This REQUIRED Printer attribute specifies the set of supported operations for this Printer object and contained Job objects.
This REQUIRED Printer attribute specifies the set of supported operations for this Printer object and contained Job objects.
This attribute is encoded as any other enum attribute syntax according to [RFC2910] as 32-bits. However, all 32-bit enum values for this attribute MUST NOT exceed 0x00008FFF, since these same values are also passed in two octets in the "operation-id" parameter (see section 3.1.1) in each Protocol request with the two high order octets omitted in order to indicate the operation being performed [RFC2910].
This attribute is encoded as any other enum attribute syntax according to [RFC2910] as 32-bits. However, all 32-bit enum values for this attribute MUST NOT exceed 0x00008FFF, since these same values are also passed in two octets in the "operation-id" parameter (see section 3.1.1) in each Protocol request with the two high order octets omitted in order to indicate the operation being performed [RFC2910].
The following standard enum and "operation-id" (see section 3.1.2) values are defined:
The following standard enum and "operation-id" (see section 3.1.2) values are defined:
Hastings, et al. Standards Track [Page 135] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 135] RFC 2911 IPP/1.1: Model and Semantics September 2000
Value Operation Name
----------------- -------------------------------------
Value Operation Name ----------------- -------------------------------------
0x0000 reserved, not used
0x0001 reserved, not used
0x0002 Print-Job
0x0003 Print-URI
0x0004 Validate-Job
0x0005 Create-Job
0x0006 Send-Document
0x0007 Send-URI
0x0008 Cancel-Job
0x0009 Get-Job-Attributes
0x000A Get-Jobs
0x000B Get-Printer-Attributes
0x000C Hold-Job
0x000D Release-Job
0x000E Restart-Job
0x000F reserved for a future operation
0x0010 Pause-Printer
0x0011 Resume-Printer
0x0012 Purge-Jobs
0x0013-0x3FFF reserved for future IETF standards track
operations (see section 6.4)
0x4000-0x8FFF reserved for vendor extensions (see section 6.4)
0x0000 reserved, not used 0x0001 reserved, not used 0x0002 Print-Job 0x0003 Print-URI 0x0004 Validate-Job 0x0005 Create-Job 0x0006 Send-Document 0x0007 Send-URI 0x0008 Cancel-Job 0x0009 Get-Job-Attributes 0x000A Get-Jobs 0x000B Get-Printer-Attributes 0x000C Hold-Job 0x000D Release-Job 0x000E Restart-Job 0x000F reserved for a future operation 0x0010 Pause-Printer 0x0011 Resume-Printer 0x0012 Purge-Jobs 0x0013-0x3FFF reserved for future IETF standards track operations (see section 6.4) 0x4000-0x8FFF reserved for vendor extensions (see section 6.4)
4.4.16 multiple-document-jobs-supported (boolean)
4.4.16 multiple-document-jobs-supported (boolean)
This Printer attribute indicates whether or not the Printer supports more than one document per job, i.e., more than one Send-Document or Send-Data operation with document data. If the Printer supports the Create-Job and Send-Document operations (see section 3.2.4 and 3.3.1), it MUST support this attribute.
This Printer attribute indicates whether or not the Printer supports more than one document per job, i.e., more than one Send-Document or Send-Data operation with document data. If the Printer supports the Create-Job and Send-Document operations (see section 3.2.4 and 3.3.1), it MUST support this attribute.
4.4.17 charset-configured (charset)
4.4.17 charset-configured (charset)
This REQUIRED Printer attribute identifies the charset that the Printer object has been configured to represent 'text' and 'name' Printer attributes that are set by the operator, system administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make- and-model" (text). Therefore, the value of the Printer object's "charset-configured" attribute MUST also be among the values of the Printer object's "charset-supported" attribute.
This REQUIRED Printer attribute identifies the charset that the Printer object has been configured to represent 'text' and 'name' Printer attributes that are set by the operator, system administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make- and-model" (text). Therefore, the value of the Printer object's "charset-configured" attribute MUST also be among the values of the Printer object's "charset-supported" attribute.
Hastings, et al. Standards Track [Page 136] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 136] RFC 2911 IPP/1.1: Model and Semantics September 2000
4.4.18 charset-supported (1setOf charset)
4.4.18 charset-supported (1setOf charset)
This REQUIRED Printer attribute identifies the set of charsets that the Printer and contained Job objects support in attributes with attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST be present, since IPP objects MUST support the UTF-8 [RFC2279] charset. If a Printer object supports a charset, it means that for all attributes of syntax 'text' and 'name' the IPP object MUST (1) accept the charset in requests and return the charset in responses as needed.
This REQUIRED Printer attribute identifies the set of charsets that the Printer and contained Job objects support in attributes with attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST be present, since IPP objects MUST support the UTF-8 [RFC2279] charset. If a Printer object supports a charset, it means that for all attributes of syntax 'text' and 'name' the IPP object MUST (1) accept the charset in requests and return the charset in responses as needed.
If more charsets than UTF-8 are supported, the IPP object MUST perform charset conversion between the charsets as described in Section 3.1.4.2.
If more charsets than UTF-8 are supported, the IPP object MUST perform charset conversion between the charsets as described in Section 3.1.4.2.
4.4.19 natural-language-configured (naturalLanguage)
4.4.19 natural-language-configured (naturalLanguage)
This REQUIRED Printer attribute identifies the natural language that the Printer object has been configured to represent 'text' and 'name' Printer attributes that are set by the operator, system administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make- and-model" (text). When returning these Printer attributes, the Printer object MAY return them in the configured natural language specified by this attribute, instead of the natural language requested by the client in the "attributes-natural-language" operation attribute. See Section 3.1.4.1 for the specification of the OPTIONAL multiple natural language support. Therefore, the value of the Printer object's "natural-language-configured" attribute MUST also be among the values of the Printer object's "generated-natural- language-supported" attribute.
This REQUIRED Printer attribute identifies the natural language that the Printer object has been configured to represent 'text' and 'name' Printer attributes that are set by the operator, system administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make- and-model" (text). When returning these Printer attributes, the Printer object MAY return them in the configured natural language specified by this attribute, instead of the natural language requested by the client in the "attributes-natural-language" operation attribute. See Section 3.1.4.1 for the specification of the OPTIONAL multiple natural language support. Therefore, the value of the Printer object's "natural-language-configured" attribute MUST also be among the values of the Printer object's "generated-natural- language-supported" attribute.
4.4.20 generated-natural-language-supported (1setOf naturalLanguage)
4.4.20 generated-natural-language-supported (1setOf naturalLanguage)
This REQUIRED Printer attribute identifies the natural language(s) that the Printer object and contained Job objects support in attributes with attribute syntax 'text' and 'name'. The natural language(s) supported depends on implementation and/or configuration. Unlike charsets, IPP objects MUST accept requests with any natural language or any Natural Language Override whether the natural language is supported or not.
This REQUIRED Printer attribute identifies the natural language(s) that the Printer object and contained Job objects support in attributes with attribute syntax 'text' and 'name'. The natural language(s) supported depends on implementation and/or configuration. Unlike charsets, IPP objects MUST accept requests with any natural language or any Natural Language Override whether the natural language is supported or not.
If a Printer object supports a natural language, it means that for any of the attributes for which the Printer or Job object generates messages, i.e., for the "job-state-message" and "printer-state- message" attributes and Operation Messages (see Section 3.1.5) in operation responses, the Printer and Job objects MUST be able to
If a Printer object supports a natural language, it means that for any of the attributes for which the Printer or Job object generates messages, i.e., for the "job-state-message" and "printer-state- message" attributes and Operation Messages (see Section 3.1.5) in operation responses, the Printer and Job objects MUST be able to
Hastings, et al. Standards Track [Page 137] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 137] RFC 2911 IPP/1.1: Model and Semantics September 2000
generate messages in any of the Printer's supported natural languages. See section 3.1.4 for the definition of 'text' and 'name' attributes in operation requests and responses.
generate messages in any of the Printer's supported natural languages. See section 3.1.4 for the definition of 'text' and 'name' attributes in operation requests and responses.
Note: A Printer object that supports multiple natural languages, often has separate catalogs of messages, one for each natural language supported.
Note: A Printer object that supports multiple natural languages, often has separate catalogs of messages, one for each natural language supported.
4.4.21 document-format-default (mimeMediaType)
4.4.21 document-format-default (mimeMediaType)
This REQUIRED Printer attribute identifies the document format that the Printer object has been configured to assume if the client does not supply a "document-format" operation attribute in any of the operation requests that supply document data. The standard values for this attribute are Internet Media types (sometimes called MIME types). For further details see the description of the 'mimeMediaType' attribute syntax in Section 4.1.9.
This REQUIRED Printer attribute identifies the document format that the Printer object has been configured to assume if the client does not supply a "document-format" operation attribute in any of the operation requests that supply document data. The standard values for this attribute are Internet Media types (sometimes called MIME types). For further details see the description of the 'mimeMediaType' attribute syntax in Section 4.1.9.
4.4.22 document-format-supported (1setOf mimeMediaType)
4.4.22 document-format-supported (1setOf mimeMediaType)
This REQUIRED Printer attribute identifies the set of document formats that the Printer object and contained Job objects can support. For further details see the description of the 'mimeMediaType' attribute syntax in Section 4.1.9.
This REQUIRED Printer attribute identifies the set of document formats that the Printer object and contained Job objects can support. For further details see the description of the 'mimeMediaType' attribute syntax in Section 4.1.9.
4.4.23 printer-is-accepting-jobs (boolean)
4.4.23 printer-is-accepting-jobs (boolean)
This REQUIRED Printer attribute indicates whether the printer is currently able to accept jobs, i.e., is accepting Print-Job, Print- URI, and Create-Job requests. If the value is 'true', the printer is accepting jobs. If the value is 'false', the Printer object is currently rejecting any jobs submitted to it. In this case, the Printer object returns the 'server-error-not-accepting-jobs' status code.
This REQUIRED Printer attribute indicates whether the printer is currently able to accept jobs, i.e., is accepting Print-Job, Print- URI, and Create-Job requests. If the value is 'true', the printer is accepting jobs. If the value is 'false', the Printer object is currently rejecting any jobs submitted to it. In this case, the Printer object returns the 'server-error-not-accepting-jobs' status code.
This value is independent of the "printer-state" and "printer-state- reasons" attributes because its value does not affect the current job; rather it affects future jobs. This attribute, when 'false', causes the Printer to reject jobs even when the "printer-state" is 'idle' or, when 'true', causes the Printer object to accepts jobs even when the "printer-state" is 'stopped'.
This value is independent of the "printer-state" and "printer-state- reasons" attributes because its value does not affect the current job; rather it affects future jobs. This attribute, when 'false', causes the Printer to reject jobs even when the "printer-state" is 'idle' or, when 'true', causes the Printer object to accepts jobs even when the "printer-state" is 'stopped'.
4.4.24 queued-job-count (integer(0:MAX))
4.4.24 queued-job-count (integer(0:MAX))
This REQUIRED Printer attribute contains a count of the number of jobs that are either 'pending', 'processing', 'pending-held', or 'processing-stopped' and is set by the Printer object.
This REQUIRED Printer attribute contains a count of the number of jobs that are either 'pending', 'processing', 'pending-held', or 'processing-stopped' and is set by the Printer object.
Hastings, et al. Standards Track [Page 138] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 138] RFC 2911 IPP/1.1: Model and Semantics September 2000
4.4.25 printer-message-from-operator (text(127))
4.4.25 printer-message-from-operator (text(127))
This Printer attribute provides a message from an operator, system administrator or "intelligent" process to indicate to the end user information or status of the printer, such as why it is unavailable or when it is expected to be available.
This Printer attribute provides a message from an operator, system administrator or "intelligent" process to indicate to the end user information or status of the printer, such as why it is unavailable or when it is expected to be available.
4.4.26 color-supported (boolean)
4.4.26 color-supported (boolean)
This Printer attribute identifies whether the device is capable of any type of color printing at all, including highlight color. All document instructions having to do with color are embedded within the document PDL (none are external IPP attributes in IPP/1.1).
This Printer attribute identifies whether the device is capable of any type of color printing at all, including highlight color. All document instructions having to do with color are embedded within the document PDL (none are external IPP attributes in IPP/1.1).
Note: end-users are able to determine the nature and details of the color support by querying the "printer-more-info-manufacturer" Printer attribute.
Note: end-users are able to determine the nature and details of the color support by querying the "printer-more-info-manufacturer" Printer attribute.
4.4.27 reference-uri-schemes-supported (1setOf uriScheme)
4.4.27 reference-uri-schemes-supported (1setOf uriScheme)
This Printer attribute specifies which URI schemes are supported for use in the "document-uri" operation attribute of the Print-URI or Send-URI operation. If a Printer object supports these optional operations, it MUST support the "reference-uri-schemes-supported" Printer attribute with at least the following schemed URI value:
This Printer attribute specifies which URI schemes are supported for use in the "document-uri" operation attribute of the Print-URI or Send-URI operation. If a Printer object supports these optional operations, it MUST support the "reference-uri-schemes-supported" Printer attribute with at least the following schemed URI value:
'ftp': The Printer object will use an FTP 'get' operation as
defined in RFC 2228 [RFC2228] using FTP URLs as defined by
[RFC2396] and [RFC2316].
'ftp': The Printer object will use an FTP 'get' operation as defined in RFC 2228 [RFC2228] using FTP URLs as defined by [RFC2396] and [RFC2316].
The Printer object MAY OPTIONALLY support other URI schemes (see section 4.1.6).
The Printer object MAY OPTIONALLY support other URI schemes (see section 4.1.6).
4.4.28 pdl-override-supported (type2 keyword)
4.4.28 pdl-override-supported (type2 keyword)
This REQUIRED Printer attribute expresses the ability for a particular Printer implementation to either attempt to override document data instructions with IPP attributes or not.
This REQUIRED Printer attribute expresses the ability for a particular Printer implementation to either attempt to override document data instructions with IPP attributes or not.
This attribute takes on the following keyword values:
This attribute takes on the following keyword values:
- 'attempted': This value indicates that the Printer object
attempts to make the IPP attribute values take precedence over
embedded instructions in the document data, however there is no
guarantee.
- 'not-attempted': This value indicates that the Printer object
makes no attempt to make the IPP attribute values take
precedence over embedded instructions in the document data.
- 'attempted': This value indicates that the Printer object attempts to make the IPP attribute values take precedence over embedded instructions in the document data, however there is no guarantee. - 'not-attempted': This value indicates that the Printer object makes no attempt to make the IPP attribute values take precedence over embedded instructions in the document data.
Hastings, et al. Standards Track [Page 139] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 139] RFC 2911 IPP/1.1: Model and Semantics September 2000
Section 15 contains a full description of how this attribute interacts with and affects other IPP attributes, especially the "ipp-attribute-fidelity" attribute.
Section 15 contains a full description of how this attribute interacts with and affects other IPP attributes, especially the "ipp-attribute-fidelity" attribute.
4.4.29 printer-up-time (integer(1:MAX))
4.4.29 printer-up-time (integer(1:MAX))
This REQUIRED Printer attribute indicates the amount of time (in seconds) that this Printer instance has been up and running. The value is a monotonically increasing value starting from 1 when the Printer object is started-up (initialized, booted, etc.). This value is used to populate the Event Time Job Description Job attributes "time-at-creation", "time-at-processing", and "time-at-completed" (see section 4.3.14).
This REQUIRED Printer attribute indicates the amount of time (in seconds) that this Printer instance has been up and running. The value is a monotonically increasing value starting from 1 when the Printer object is started-up (initialized, booted, etc.). This value is used to populate the Event Time Job Description Job attributes "time-at-creation", "time-at-processing", and "time-at-completed" (see section 4.3.14).
If the Printer object goes down at some value 'n', and comes back up, the implementation MAY:
If the Printer object goes down at some value 'n', and comes back up, the implementation MAY:
1. Know how long it has been down, and resume at some value
greater than 'n', or
2. Restart from 1.
1. Know how long it has been down, and resume at some value greater than 'n', or 2. Restart from 1.
In other words, if the device or devices that the Printer object is representing are restarted or power cycled, the Printer object MAY continue counting this value or MAY reset this value to 1 depending on implementation. However, if the Printer object software ceases running, and restarts without knowing the last value for "printer- up-time", the implementation MUST reset this value to 1. If this value is reset and the Printer has persistent jobs, the Printer MUST reset the "time-at-xxx(integer) Event Time Job Description attributes according to Section 4.3.14. An implementation MAY use both implementation alternatives, depending on warm versus cold start, respectively.
In other words, if the device or devices that the Printer object is representing are restarted or power cycled, the Printer object MAY continue counting this value or MAY reset this value to 1 depending on implementation. However, if the Printer object software ceases running, and restarts without knowing the last value for "printer- up-time", the implementation MUST reset this value to 1. If this value is reset and the Printer has persistent jobs, the Printer MUST reset the "time-at-xxx(integer) Event Time Job Description attributes according to Section 4.3.14. An implementation MAY use both implementation alternatives, depending on warm versus cold start, respectively.
4.4.30 printer-current-time (dateTime)
4.4.30 printer-current-time (dateTime)
This Printer attribute indicates the current date and time. This value is used to populate the Event Time Job Description attributes: "date-time-at-creation", "date-time-at-processing", and "date-time- at-completed" (see Section 4.3.14).
This Printer attribute indicates the current date and time. This value is used to populate the Event Time Job Description attributes: "date-time-at-creation", "date-time-at-processing", and "date-time- at-completed" (see Section 4.3.14).
The date and time is obtained on a "best efforts basis" and does not have to be that precise in order to work in practice. A Printer implementation sets the value of this attribute by obtaining the date and time via some implementation-dependent means, such as getting the value from a network time server, initialization at time of manufacture, or setting by an administrator. See [IPP-IIG] for examples. If an implementation supports this attribute and the implementation knows that it has not yet been set, then the
The date and time is obtained on a "best efforts basis" and does not have to be that precise in order to work in practice. A Printer implementation sets the value of this attribute by obtaining the date and time via some implementation-dependent means, such as getting the value from a network time server, initialization at time of manufacture, or setting by an administrator. See [IPP-IIG] for examples. If an implementation supports this attribute and the implementation knows that it has not yet been set, then the
Hastings, et al. Standards Track [Page 140] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 140] RFC 2911 IPP/1.1: Model and Semantics September 2000
implementation MUST return the value of this attribute using the out-of-band 'no-value' meaning not configured. See the beginning of section 4.1.
implementation MUST return the value of this attribute using the out-of-band 'no-value' meaning not configured. See the beginning of section 4.1.
The time zone of this attribute NEED NOT be the time zone used by people located near the Printer object or device. The client MUST NOT expect that the time zone of any received 'dateTime' value to be in the time zone of the client or in the time zone of the people located near the printer.
The time zone of this attribute NEED NOT be the time zone used by people located near the Printer object or device. The client MUST NOT expect that the time zone of any received 'dateTime' value to be in the time zone of the client or in the time zone of the people located near the printer.
The client SHOULD display any dateTime attributes to the user in client local time by converting the 'dateTime' value returned by the server to the time zone of the client, rather than using the time zone returned by the Printer in attributes that use the 'dateTime' attribute syntax.
The client SHOULD display any dateTime attributes to the user in client local time by converting the 'dateTime' value returned by the server to the time zone of the client, rather than using the time zone returned by the Printer in attributes that use the 'dateTime' attribute syntax.
4.4.31 multiple-operation-time-out (integer(1:MAX))
4.4.31 multiple-operation-time-out (integer(1:MAX))
This Printer attributes identifies the minimum time (in seconds) that the Printer object waits for additional Send-Document or Send-URI operations to follow a still-open Job object before taking any recovery actions, such as the ones indicated in section 3.3.1. If the Printer object supports the Create-Job and Send-Document operations (see section 3.2.4 and 3.3.1), it MUST support this attribute.
This Printer attributes identifies the minimum time (in seconds) that the Printer object waits for additional Send-Document or Send-URI operations to follow a still-open Job object before taking any recovery actions, such as the ones indicated in section 3.3.1. If the Printer object supports the Create-Job and Send-Document operations (see section 3.2.4 and 3.3.1), it MUST support this attribute.
It is RECOMMENDED that vendors supply a value for this attribute that is between 60 and 240 seconds. An implementation MAY allow a system administrator to set this attribute (by means outside this IPP/1.1 document). If so, the system administrator MAY be able to set values outside this range.
It is RECOMMENDED that vendors supply a value for this attribute that is between 60 and 240 seconds. An implementation MAY allow a system administrator to set this attribute (by means outside this IPP/1.1 document). If so, the system administrator MAY be able to set values outside this range.
4.4.32 compression-supported (1setOf type3 keyword)
4.4.32 compression-supported (1setOf type3 keyword)
This REQUIRED Printer attribute identifies the set of supported compression algorithms for document data. Compression only applies to the document data; compression does not apply to the encoding of the IPP operation itself. The supported values are used to validate the client supplied "compression" operation attributes in Print-Job, Send-Document, and Send-URI requests.
This REQUIRED Printer attribute identifies the set of supported compression algorithms for document data. Compression only applies to the document data; compression does not apply to the encoding of the IPP operation itself. The supported values are used to validate the client supplied "compression" operation attributes in Print-Job, Send-Document, and Send-URI requests.
Standard keyword values are :
Standard keyword values are :
'none': no compression is used.
'deflate': ZIP public domain inflate/deflate) compression technology
in RFC 1951 [RFC1951]
'gzip' GNU zip compression technology described in RFC 1952
[RFC1952].
'none': no compression is used. 'deflate': ZIP public domain inflate/deflate) compression technology in RFC 1951 [RFC1951] 'gzip' GNU zip compression technology described in RFC 1952 [RFC1952].
Hastings, et al. Standards Track [Page 141] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 141] RFC 2911 IPP/1.1: Model and Semantics September 2000
'compress': UNIX compression technology in RFC 1977 [RFC1977]
'compress': UNIX compression technology in RFC 1977 [RFC1977]
4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX))
4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX))
This Printer attribute specifies the upper and lower bounds of total sizes of jobs in K octets, i.e., in units of 1024 octets. The supported values are used to validate the client supplied "job-k- octets" operation attributes in create requests. The corresponding job description attribute "job-k-octets" is defined in section 4.3.17.1.
This Printer attribute specifies the upper and lower bounds of total sizes of jobs in K octets, i.e., in units of 1024 octets. The supported values are used to validate the client supplied "job-k- octets" operation attributes in create requests. The corresponding job description attribute "job-k-octets" is defined in section 4.3.17.1.
4.4.34 job-impressions-supported (rangeOfInteger(0:MAX))
4.4.34 job-impressions-supported (rangeOfInteger(0:MAX))
This Printer attribute specifies the upper and lower bounds for the number of impressions per job. The supported values are used to validate the client supplied "job-impressions" operation attributes in create requests. The corresponding job description attribute "job-impressions" is defined in section 4.3.17.2.
This Printer attribute specifies the upper and lower bounds for the number of impressions per job. The supported values are used to validate the client supplied "job-impressions" operation attributes in create requests. The corresponding job description attribute "job-impressions" is defined in section 4.3.17.2.
4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX))
4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX))
This Printer attribute specifies the upper and lower bounds for the number of media sheets per job. The supported values are used to validate the client supplied "job-media-sheets" operation attributes in create requests. The corresponding Job attribute "job-media- sheets" is defined in section 4.3.17.3.
This Printer attribute specifies the upper and lower bounds for the number of media sheets per job. The supported values are used to validate the client supplied "job-media-sheets" operation attributes in create requests. The corresponding Job attribute "job-media- sheets" is defined in section 4.3.17.3.
4.4.36 pages-per-minute (integer(0:MAX))
4.4.36 pages-per-minute (integer(0:MAX))
This Printer attributes specifies the nominal number of pages per minute to the nearest whole number which may be generated by this printer (e.g., simplex, black-and-white). This attribute is informative, not a service guarantee. Generally, it is the value used in the marketing literature to describe the device.
This Printer attributes specifies the nominal number of pages per minute to the nearest whole number which may be generated by this printer (e.g., simplex, black-and-white). This attribute is informative, not a service guarantee. Generally, it is the value used in the marketing literature to describe the device.
A value of 0 indicates a device that takes more than two minutes to process a page.
A value of 0 indicates a device that takes more than two minutes to process a page.
4.4.37 pages-per-minute-color (integer(0:MAX))
4.4.37 pages-per-minute-color (integer(0:MAX))
This Printer attributes specifies the nominal number of pages per minute to the nearest whole number which may be generated by this printer when printing color (e.g., simplex, color). For purposes of this attribute, "color" means the same as for the "color-supported" attribute, namely, the device is capable of any type of color printing at all, including highlight color. This attribute is
This Printer attributes specifies the nominal number of pages per minute to the nearest whole number which may be generated by this printer when printing color (e.g., simplex, color). For purposes of this attribute, "color" means the same as for the "color-supported" attribute, namely, the device is capable of any type of color printing at all, including highlight color. This attribute is
Hastings, et al. Standards Track [Page 142] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 142] RFC 2911 IPP/1.1: Model and Semantics September 2000
informative, not a service guarantee. Generally, it is the value used in the marketing literature to describe the color capabilities of this device.
informative, not a service guarantee. Generally, it is the value used in the marketing literature to describe the color capabilities of this device.
A value of 0 indicates a device that takes more than two minutes to process a page.
A value of 0 indicates a device that takes more than two minutes to process a page.
If a color device has several color modes, it MAY use the pages-per- minute value for this attribute that corresponds to the mode that produces the highest number.
If a color device has several color modes, it MAY use the pages-per- minute value for this attribute that corresponds to the mode that produces the highest number.
Black and white only printers MUST NOT support this attribute. If this attribute is present, then the "color-supported" Printer description attribute MUST be present and have a 'true' value.
Black and white only printers MUST NOT support this attribute. If this attribute is present, then the "color-supported" Printer description attribute MUST be present and have a 'true' value.
The values of these two attributes returned by the Get-Printer- Attributes operation MAY be affected by the "document-format" attribute supplied by the client in the Get-Printer-Attributes request. In other words, the implementation MAY have different speeds depending on the document format being processed. See section 3.2.5.1 Get-Printer-Attributes.
The values of these two attributes returned by the Get-Printer- Attributes operation MAY be affected by the "document-format" attribute supplied by the client in the Get-Printer-Attributes request. In other words, the implementation MAY have different speeds depending on the document format being processed. See section 3.2.5.1 Get-Printer-Attributes.
5. Conformance
5. Conformance
This section describes conformance issues and requirements. This document introduces model entities such as objects, operations, attributes, attribute syntaxes, and attribute values. These conformance sections describe the conformance requirements which apply to these model entities.
This section describes conformance issues and requirements. This document introduces model entities such as objects, operations, attributes, attribute syntaxes, and attribute values. These conformance sections describe the conformance requirements which apply to these model entities.
5.1 Client Conformance Requirements
5.1 Client Conformance Requirements
This section describes the conformance requirements for a client (see section 2.1), whether it be:
This section describes the conformance requirements for a client (see section 2.1), whether it be:
1. contained within software controlled by an end user, e.g.
activated by the "Print" menu item in an application that sends
IPP requests or
1. contained within software controlled by an end user, e.g. activated by the "Print" menu item in an application that sends IPP requests or
2. the print server component that sends IPP requests to either an
output device or another "downstream" print server.
2. the print server component that sends IPP requests to either an output device or another "downstream" print server.
A conforming client MUST support all REQUIRED operations as defined in this document. For each attribute included in an operation request, a conforming client MUST supply a value whose type and value syntax conforms to the requirements of the Model document as specified in Sections 3 and 4. A conforming client MAY supply any
A conforming client MUST support all REQUIRED operations as defined in this document. For each attribute included in an operation request, a conforming client MUST supply a value whose type and value syntax conforms to the requirements of the Model document as specified in Sections 3 and 4. A conforming client MAY supply any
Hastings, et al. Standards Track [Page 143] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 143] RFC 2911 IPP/1.1: Model and Semantics September 2000
IETF standards track extensions and/or vendor extensions in an operation request, as long as the extensions meet the requirements in Section 6.
IETF standards track extensions and/or vendor extensions in an operation request, as long as the extensions meet the requirements in Section 6.
Otherwise, there are no conformance requirements placed on the user interfaces provided by IPP clients or their applications. For example, one application might not allow an end user to submit multiple documents per job, while another does. One application might first query a Printer object in order to supply a graphical user interface (GUI) dialogue box with supported and default values whereas a different implementation might not.
Otherwise, there are no conformance requirements placed on the user interfaces provided by IPP clients or their applications. For example, one application might not allow an end user to submit multiple documents per job, while another does. One application might first query a Printer object in order to supply a graphical user interface (GUI) dialogue box with supported and default values whereas a different implementation might not.
When sending a request, an IPP client NEED NOT supply any attributes that are indicated as OPTIONALLY supplied by the client.
When sending a request, an IPP client NEED NOT supply any attributes that are indicated as OPTIONALLY supplied by the client.
A client MUST be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, that may be returned to it in a response from a Printer object. In particular for each attribute that the client supports whose attribute syntax is 'text', the client MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each attribute that the client supports whose attribute syntax is 'name', the client MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. For presentation purposes, truncation of long attribute values is not recommended. A recommended approach would be for the client implementation to allow the user to scroll through long attribute values.
A client MUST be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, that may be returned to it in a response from a Printer object. In particular for each attribute that the client supports whose attribute syntax is 'text', the client MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each attribute that the client supports whose attribute syntax is 'name', the client MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. For presentation purposes, truncation of long attribute values is not recommended. A recommended approach would be for the client implementation to allow the user to scroll through long attribute values.
A response MAY contain attribute groups, attributes, attribute syntaxes, values, and status codes that the client does not expect. Therefore, a client implementation MUST gracefully handle such responses and not refuse to inter-operate with a conforming Printer that is returning IETF standards track extension or vendor extensions, including attribute groups, attributes, attribute syntaxes, attribute values, status codes, and out-of-band attribute values that conform to Section 6. Clients may choose to ignore any parameters, attribute groups, attributes, attribute syntaxes, or values that they do not understand.
A response MAY contain attribute groups, attributes, attribute syntaxes, values, and status codes that the client does not expect. Therefore, a client implementation MUST gracefully handle such responses and not refuse to inter-operate with a conforming Printer that is returning IETF standards track extension or vendor extensions, including attribute groups, attributes, attribute syntaxes, attribute values, status codes, and out-of-band attribute values that conform to Section 6. Clients may choose to ignore any parameters, attribute groups, attributes, attribute syntaxes, or values that they do not understand.
While a client is sending data to a printer, it SHOULD do its best to prevent a channel from being closed by a lower layer when the channel is blocked (i.e. flow-controlled off) for whatever reason, e.g. 'out of paper' or 'job ahead hasn't freed up enough memory'. However, the layer that launched the print submission (e.g. an end user) MAY close the channel in order to cancel the job. When a client closes a channel, a Printer MAY print all or part of the received portion of the document. See the "Encoding and Transport" document [RFC2910] for more details.
While a client is sending data to a printer, it SHOULD do its best to prevent a channel from being closed by a lower layer when the channel is blocked (i.e. flow-controlled off) for whatever reason, e.g. 'out of paper' or 'job ahead hasn't freed up enough memory'. However, the layer that launched the print submission (e.g. an end user) MAY close the channel in order to cancel the job. When a client closes a channel, a Printer MAY print all or part of the received portion of the document. See the "Encoding and Transport" document [RFC2910] for more details.
Hastings, et al. Standards Track [Page 144] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 144] RFC 2911 IPP/1.1: Model and Semantics September 2000
A client MUST support Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A client SHOULD support Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. See also section 8 of this document.
A client MUST support Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A client SHOULD support Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. See also section 8 of this document.
5.2 IPP Object Conformance Requirements
5.2 IPP Object Conformance Requirements
This section specifies the conformance requirements for conforming implementations of IPP objects (see section 2). These requirements apply to an IPP object whether it is:
This section specifies the conformance requirements for conforming implementations of IPP objects (see section 2). These requirements apply to an IPP object whether it is:
(1) an (embedded) device component that accepts IPP requests and
controls the device or
(1) an (embedded) device component that accepts IPP requests and controls the device or
(2) a component of a print server that accepts IPP requests (where
the print server control one or more networked devices using IPP or
other protocols).
(2) a component of a print server that accepts IPP requests (where the print server control one or more networked devices using IPP or other protocols).
5.2.1 Objects
5.2.1 Objects
Conforming implementations MUST implement all of the model objects as defined in this document in the indicated sections:
Conforming implementations MUST implement all of the model objects as defined in this document in the indicated sections:
Section 2.1 - Printer Object
Section 2.2 - Job Object
Section 2.1 - Printer Object Section 2.2 - Job Object
5.2.2 Operations
5.2.2 Operations
Conforming IPP object implementations MUST implement all of the REQUIRED model operations, including REQUIRED responses, as defined in this document in the indicated sections:
Conforming IPP object implementations MUST implement all of the REQUIRED model operations, including REQUIRED responses, as defined in this document in the indicated sections:
For a Printer object:
Print-Job (section 3.2.1) REQUIRED
Print-URI (section 3.2.2) OPTIONAL
Validate-Job (section 3.2.3) REQUIRED
Create-Job (section 3.2.4) OPTIONAL
Get-Printer-Attributes (section 3.2.5) REQUIRED
Get-Jobs (section 3.2.6) REQUIRED
Pause-Printer (section 3.2.7) OPTIONAL
Resume-Printer (section 3.2.8) OPTIONAL
Purge-Jobs (section 3.2.9) OPTIONAL
For a Printer object: Print-Job (section 3.2.1) REQUIRED Print-URI (section 3.2.2) OPTIONAL Validate-Job (section 3.2.3) REQUIRED Create-Job (section 3.2.4) OPTIONAL Get-Printer-Attributes (section 3.2.5) REQUIRED Get-Jobs (section 3.2.6) REQUIRED Pause-Printer (section 3.2.7) OPTIONAL Resume-Printer (section 3.2.8) OPTIONAL Purge-Jobs (section 3.2.9) OPTIONAL
Hastings, et al. Standards Track [Page 145] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 145] RFC 2911 IPP/1.1: Model and Semantics September 2000
For a Job object:
Send-Document (section 3.3.1) OPTIONAL
Send-URI (section 3.3.2) OPTIONAL
Cancel-Job (section 3.3.3) REQUIRED
Get-Job-Attributes (section 3.3.4) REQUIRED
Hold-Job (section 3.3.5) OPTIONAL
Release-Job (section 3.3.6) OPTIONAL
Restart-Job (section 3.3.7) OPTIONAL
For a Job object: Send-Document (section 3.3.1) OPTIONAL Send-URI (section 3.3.2) OPTIONAL Cancel-Job (section 3.3.3) REQUIRED Get-Job-Attributes (section 3.3.4) REQUIRED Hold-Job (section 3.3.5) OPTIONAL Release-Job (section 3.3.6) OPTIONAL Restart-Job (section 3.3.7) OPTIONAL
Conforming IPP objects MUST support all REQUIRED operation attributes and all values of such attributes if so indicated in the description. Conforming IPP objects MUST ignore all unsupported or unknown operation attributes or operation attribute groups received in a request, but MUST reject a request that contains a supported operation attribute that contains an unsupported value.
Conforming IPP objects MUST support all REQUIRED operation attributes and all values of such attributes if so indicated in the description. Conforming IPP objects MUST ignore all unsupported or unknown operation attributes or operation attribute groups received in a request, but MUST reject a request that contains a supported operation attribute that contains an unsupported value.
Conforming IPP objects MAY return operation responses that contain attributes groups, attributes names, attribute syntaxes, attribute values, and status codes that are extensions to this standard. The additional attribute groups MAY occur in any order.
Conforming IPP objects MAY return operation responses that contain attributes groups, attributes names, attribute syntaxes, attribute values, and status codes that are extensions to this standard. The additional attribute groups MAY occur in any order.
The following section on object attributes specifies the support required for object attributes.
The following section on object attributes specifies the support required for object attributes.
5.2.3 IPP Object Attributes
5.2.3 IPP Object Attributes
Conforming IPP objects MUST support all of the REQUIRED object attributes, as defined in this document in the indicated sections.
Conforming IPP objects MUST support all of the REQUIRED object attributes, as defined in this document in the indicated sections.
If an object supports an attribute, it MUST support only those values specified in this document or through the extension mechanism described in section 5.2.4. It MAY support any non-empty subset of these values. That is, it MUST support at least one of the specified values and at most all of them.
If an object supports an attribute, it MUST support only those values specified in this document or through the extension mechanism described in section 5.2.4. It MAY support any non-empty subset of these values. That is, it MUST support at least one of the specified values and at most all of them.
5.2.4 Versions
5.2.4 Versions
IPP/1.1 clients MUST meet the conformance requirements for clients specified in this document and [RFC2910]. IPP/1.1 clients MUST send requests containing a "version-number" parameter with a '1.1' value.
IPP/1.1 clients MUST meet the conformance requirements for clients specified in this document and [RFC2910]. IPP/1.1 clients MUST send requests containing a "version-number" parameter with a '1.1' value.
IPP/1.1 Printer and Job objects MUST meet the conformance requirements for IPP objects specified in this document and [RFC2910]. IPP/1.1 objects MUST accept requests containing a "version-number" parameter with a '1.1' value (or reject the request if the operation is not supported).
IPP/1.1 Printer and Job objects MUST meet the conformance requirements for IPP objects specified in this document and [RFC2910]. IPP/1.1 objects MUST accept requests containing a "version-number" parameter with a '1.1' value (or reject the request if the operation is not supported).
Hastings, et al. Standards Track [Page 146] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 146] RFC 2911 IPP/1.1: Model and Semantics September 2000
It is beyond the scope of this specification to mandate conformance with previous versions. IPP/1.1 was deliberately designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification (1999), we would expect IPP/1.1 Printer implementations to:
It is beyond the scope of this specification to mandate conformance with previous versions. IPP/1.1 was deliberately designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification (1999), we would expect IPP/1.1 Printer implementations to:
understand any valid request in the format of IPP/1.0, or 1.1;
understand any valid request in the format of IPP/1.0, or 1.1;
respond appropriately with a response containing the same
"version-number" parameter value used by the client in the request.
respond appropriately with a response containing the same "version-number" parameter value used by the client in the request.
And we would expect IPP/1.1 clients to:
And we would expect IPP/1.1 clients to:
understand any valid response in the format of IPP/1.0, or 1.1.
understand any valid response in the format of IPP/1.0, or 1.1.
It is recommended that IPP/1.1 clients try supplying alternate version numbers if they receive a 'server-error-version-not- supported' error return in a response.
It is recommended that IPP/1.1 clients try supplying alternate version numbers if they receive a 'server-error-version-not- supported' error return in a response.
5.2.5 Extensions
5.2.5 Extensions
A conforming IPP object MAY support IETF standards track extensions and vendor extensions, as long as the extensions meet the requirements specified in Section 6.
A conforming IPP object MAY support IETF standards track extensions and vendor extensions, as long as the extensions meet the requirements specified in Section 6.
For each attribute included in an operation response, a conforming IPP object MUST return a value whose type and value syntax conforms to the requirement of the Model document as specified in Sections 3 and 4.
For each attribute included in an operation response, a conforming IPP object MUST return a value whose type and value syntax conforms to the requirement of the Model document as specified in Sections 3 and 4.
5.2.6 Attribute Syntaxes
5.2.6 Attribute Syntaxes
An IPP object MUST be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, in any operation in which a client may supply attributes or the system administrator may configure attributes (by means outside the scope of this IPP/1.1 document). In particular for each attribute that the IPP object supports whose attribute syntax is 'text', the IPP object MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each attribute that the IPP object supports whose attribute syntax is 'name', the IPP object MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. Furthermore, an IPP object MUST return attributes to the client in operation responses that conform to the syntax specified in Section 4.1, including their full range if supplied previously by a client.
An IPP object MUST be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, in any operation in which a client may supply attributes or the system administrator may configure attributes (by means outside the scope of this IPP/1.1 document). In particular for each attribute that the IPP object supports whose attribute syntax is 'text', the IPP object MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each attribute that the IPP object supports whose attribute syntax is 'name', the IPP object MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. Furthermore, an IPP object MUST return attributes to the client in operation responses that conform to the syntax specified in Section 4.1, including their full range if supplied previously by a client.
Hastings, et al. Standards Track [Page 147] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 147] RFC 2911 IPP/1.1: Model and Semantics September 2000
5.2.7 Security
5.2.7 Security
An IPP Printer implementation SHOULD contain support for Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the Printer so that all, some, or none of the users are authenticated. See also section 8 of this document.
An IPP Printer implementation SHOULD contain support for Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the Printer so that all, some, or none of the users are authenticated. See also section 8 of this document.
An IPP Printer implementation SHOULD contain support for Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the degree of support for Operation Privacy and Server Authentication. See also section 8 of this document.
An IPP Printer implementation SHOULD contain support for Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the degree of support for Operation Privacy and Server Authentication. See also section 8 of this document.
Security MUST NOT be compromised when a client supplies a lower "version-number" parameter in a request. For example, if an IPP/1.1 conforming Printer object accepts version '1.0' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.0' request.
Security MUST NOT be compromised when a client supplies a lower "version-number" parameter in a request. For example, if an IPP/1.1 conforming Printer object accepts version '1.0' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.0' request.
5.3 Charset and Natural Language Requirements
5.3 Charset and Natural Language Requirements
All clients and IPP objects MUST support the 'utf-8' charset as defined in section 4.1.7.
All clients and IPP objects MUST support the 'utf-8' charset as defined in section 4.1.7.
IPP objects MUST be able to accept any client request which correctly uses the "attributes-natural-language" operation attribute or the Natural Language Override mechanism on any individual attribute whether or not the natural language is supported by the IPP object. If an IPP object supports a natural language, then it MUST be able to translate (perhaps by table lookup) all generated 'text' or 'name' attribute values into one of the supported languages (see section 3.1.4). That is, the IPP object that supports a natural language NEED NOT be a general purpose translator of any arbitrary 'text' or 'name' value supplied by the client into that natural language. However, the object MUST be able to translate (automatically generate) any of its own attribute values and messages into that natural language.
IPP objects MUST be able to accept any client request which correctly uses the "attributes-natural-language" operation attribute or the Natural Language Override mechanism on any individual attribute whether or not the natural language is supported by the IPP object. If an IPP object supports a natural language, then it MUST be able to translate (perhaps by table lookup) all generated 'text' or 'name' attribute values into one of the supported languages (see section 3.1.4). That is, the IPP object that supports a natural language NEED NOT be a general purpose translator of any arbitrary 'text' or 'name' value supplied by the client into that natural language. However, the object MUST be able to translate (automatically generate) any of its own attribute values and messages into that natural language.
6. IANA Considerations
6. IANA Considerations
This section describes the procedures for defining semantics for the following IETF standards track extensions and vendor extensions to the IPP/1.1 Model and Semantics document:
This section describes the procedures for defining semantics for the following IETF standards track extensions and vendor extensions to the IPP/1.1 Model and Semantics document:
1. keyword attribute values
2. enum attribute values
1. keyword attribute values 2. enum attribute values
Hastings, et al. Standards Track [Page 148] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 148] RFC 2911 IPP/1.1: Model and Semantics September 2000
3. attributes
4. attribute syntaxes
5. operations
6. attribute groups
7. status codes
8. out-of-band attribute values
3. attributes 4. attribute syntaxes 5. operations 6. attribute groups 7. status codes 8. out-of-band attribute values
Extensions registered for use with IPP/1.1 are OPTIONAL for client and IPP object conformance to the IPP/1.1 "Model and Semantics" document (this document).
Extensions registered for use with IPP/1.1 are OPTIONAL for client and IPP object conformance to the IPP/1.1 "Model and Semantics" document (this document).
These extension procedures are aligned with the guidelines as set forth by the IESG [IANA-CON]. Section 11 describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or do not follow the appropriate format described in Section 11. The IPP/1.1 Model and Semantics document may also be extended by an appropriate RFC that specifies any of the above extensions.
These extension procedures are aligned with the guidelines as set forth by the IESG [IANA-CON]. Section 11 describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or do not follow the appropriate format described in Section 11. The IPP/1.1 Model and Semantics document may also be extended by an appropriate RFC that specifies any of the above extensions.
6.1 Typed 'keyword' and 'enum' Extensions
6.1 Typed 'keyword' and 'enum' Extensions
IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3 and 4.1.4). This document uses prefixes to the 'keyword' and 'enum' basic attribute syntax type in order to communicate extra information to the reader through its name. This extra information is not represented in the protocol because it is unimportant to a client or Printer object. The list below describes the prefixes and their meaning.
IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3 and 4.1.4). This document uses prefixes to the 'keyword' and 'enum' basic attribute syntax type in order to communicate extra information to the reader through its name. This extra information is not represented in the protocol because it is unimportant to a client or Printer object. The list below describes the prefixes and their meaning.
"type1": This IPP specification document must be revised (or
another IETF standards track document which augments this
document) to add a new keyword or a new enum. No vendor
defined keywords or enums are allowed.
"type1": This IPP specification document must be revised (or another IETF standards track document which augments this document) to add a new keyword or a new enum. No vendor defined keywords or enums are allowed.
"type2": Implementers can, at any time, add new keyword or enum
values by proposing the complete specification to IANA:
"type2": Implementers can, at any time, add new keyword or enum values by proposing the complete specification to IANA:
iana@iana.org
iana@iana.org
IANA will forward the registration proposal to the IPP
Designated Expert who will review the proposal with a mailing
list that the Designated Expert keeps for this purpose.
Initially, that list will be the mailing list used by the IPP
WG:
IANA will forward the registration proposal to the IPP Designated Expert who will review the proposal with a mailing list that the Designated Expert keeps for this purpose. Initially, that list will be the mailing list used by the IPP WG:
ipp@pwg.org
ipp@pwg.org
even after the IPP WG is disbanded as permitted by [IANA-CON].
even after the IPP WG is disbanded as permitted by [IANA-CON].
Hastings, et al. Standards Track [Page 149] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 149] RFC 2911 IPP/1.1: Model and Semantics September 2000
The IPP Designated Expert is appointed by the IESG Area
Director responsible for IPP, according to [IANA-CON].
The IPP Designated Expert is appointed by the IESG Area Director responsible for IPP, according to [IANA-CON].
When a type2 keyword or enum is approved, the IPP Designated
Expert becomes the point of contact for any future maintenance
that might be required for that registration.
When a type2 keyword or enum is approved, the IPP Designated Expert becomes the point of contact for any future maintenance that might be required for that registration.
"type3": Implementers can, at any time, add new keyword and enum
values by submitting the complete specification to IANA as for
type2 who will forward the proposal to the IPP Designated
Expert. While no additional technical review is required, the
IPP Designated Expert may, at his/her discretion, forward the
proposal to the same mailing list as for type2 registrations
for advice and comment.
"type3": Implementers can, at any time, add new keyword and enum values by submitting the complete specification to IANA as for type2 who will forward the proposal to the IPP Designated Expert. While no additional technical review is required, the IPP Designated Expert may, at his/her discretion, forward the proposal to the same mailing list as for type2 registrations for advice and comment.
When a type3 keyword or enum is approved by the IPP Designated
Expert, the original proposer becomes the point of contact for
any future maintenance that might be required for that
registration.
When a type3 keyword or enum is approved by the IPP Designated Expert, the original proposer becomes the point of contact for any future maintenance that might be required for that registration.
For type2 and type3 keywords, the proposer includes the name of the keyword in the registration proposal and the name is part of the technical review.
For type2 and type3 keywords, the proposer includes the name of the keyword in the registration proposal and the name is part of the technical review.
After type2 and type3 enums specifications are approved, the IPP Designated Expert in consultation with IANA assigns the next available enum number for each enum value.
After type2 and type3 enums specifications are approved, the IPP Designated Expert in consultation with IANA assigns the next available enum number for each enum value.
IANA will publish approved type2 and type3 keyword and enum attributes value registration specifications in:
IANA will publish approved type2 and type3 keyword and enum attributes value registration specifications in:
ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
where xxx is the attribute name that specifies the initial values and yyy.txt is a descriptive file name that contains one or more enums or keywords approved at the same time. For example, if several additional enums for stapling are approved for use with the "finishings" attribute (and "finishings-default" and "finishings- supported" attributes), IANA will publish the additional values in the file:
where xxx is the attribute name that specifies the initial values and yyy.txt is a descriptive file name that contains one or more enums or keywords approved at the same time. For example, if several additional enums for stapling are approved for use with the "finishings" attribute (and "finishings-default" and "finishings- supported" attributes), IANA will publish the additional values in the file:
ftp.isi.edu/iana/assignments/ipp/attribute-
values/finishings/stapling.txt
ftp.isi.edu/iana/assignments/ipp/attribute- values/finishings/stapling.txt
Note: Some attributes are defined to be: 'type3 keywords' | 'name' which allows for attribute values to be extended by a site administrator with administrator defined names. Such names are not registered with IANA.
Note: Some attributes are defined to be: 'type3 keywords' | 'name' which allows for attribute values to be extended by a site administrator with administrator defined names. Such names are not registered with IANA.
Hastings, et al. Standards Track [Page 150] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 150] RFC 2911 IPP/1.1: Model and Semantics September 2000
By definition, each of the three types above assert some sort of registry or review process in order for extensions to be considered valid. Each higher numbered level (1, 2, 3) tends to be decreasingly less stringent than the previous level. Therefore, any typeN value MAY be registered using a process for some typeM where M is less than N, however such registration is NOT REQUIRED. For example, a type3 value MAY be registered in a type 1 manner (by being included in a future version of an IPP specification), however, it is NOT REQUIRED.
By definition, each of the three types above assert some sort of registry or review process in order for extensions to be considered valid. Each higher numbered level (1, 2, 3) tends to be decreasingly less stringent than the previous level. Therefore, any typeN value MAY be registered using a process for some typeM where M is less than N, however such registration is NOT REQUIRED. For example, a type3 value MAY be registered in a type 1 manner (by being included in a future version of an IPP specification), however, it is NOT REQUIRED.
This document defines keyword and enum values for all of the above types, including type3 keywords.
This document defines keyword and enum values for all of the above types, including type3 keywords.
For vendor keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-" where xxx follows the syntax rules for keywords (see section 4.1.3) and is the (lowercase) fully qualified company name registered with IANA for use in domain names [RFC1035]. For example, if the company XYZ Corp. had obtained the domain name "XYZ.com", then a vendor keyword 'abc' would be: 'xyz.com-abc'.
For vendor keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-" where xxx follows the syntax rules for keywords (see section 4.1.3) and is the (lowercase) fully qualified company name registered with IANA for use in domain names [RFC1035]. For example, if the company XYZ Corp. had obtained the domain name "XYZ.com", then a vendor keyword 'abc' would be: 'xyz.com-abc'.
Note: RFC 1035 [RFC1035] indicates that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. Also, the labels in a domain name must follow the rules for ARPANET host names: They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. Labels must be 63 characters or less. Labels are separated by the "." character.
Note: RFC 1035 [RFC1035] indicates that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. Also, the labels in a domain name must follow the rules for ARPANET host names: They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. Labels must be 63 characters or less. Labels are separated by the "." character.
For vendor enum extensions, implementers MUST use values in the reserved integer range which is 2**30 to 2**31-1.
For vendor enum extensions, implementers MUST use values in the reserved integer range which is 2**30 to 2**31-1.
6.2 Attribute Extensibility
6.2 Attribute Extensibility
Attribute names (see section 4.1.3) are type2 keywords. Therefore, new attributes may be registered and have the same status as attributes in this document by following the type2 extension rules. For vendor attribute extensions, implementers SHOULD use keywords with a suitable distinguishing prefix as described in Section 6.1.
Attribute names (see section 4.1.3) are type2 keywords. Therefore, new attributes may be registered and have the same status as attributes in this document by following the type2 extension rules. For vendor attribute extensions, implementers SHOULD use keywords with a suitable distinguishing prefix as described in Section 6.1.
IANA will publish approved attribute registration specifications as separate files:
IANA will publish approved attribute registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt
ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt
where "xxx-yyy" is the new attribute name.
where "xxx-yyy" is the new attribute name.
Hastings, et al. Standards Track [Page 151] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 151] RFC 2911 IPP/1.1: Model and Semantics September 2000
If a new Printer object attribute is defined and its values can be affected by a specific document format, its specification needs to contain the following sentence:
If a new Printer object attribute is defined and its values can be affected by a specific document format, its specification needs to contain the following sentence:
"The value of this attribute returned in a Get-Printer-
Attributes response MAY depend on the "document-format"
attribute supplied (see Section 3.2.5.1)."
"The value of this attribute returned in a Get-Printer- Attributes response MAY depend on the "document-format" attribute supplied (see Section 3.2.5.1)."
If the specification does not, then its value in the Get-Printer- Attributes response MUST NOT depend on the "document-format" supplied in the request. When a new Job Template attribute is registered, the value of the Printer attributes MAY vary with "document-format" supplied in the request without the specification having to indicate so.
If the specification does not, then its value in the Get-Printer- Attributes response MUST NOT depend on the "document-format" supplied in the request. When a new Job Template attribute is registered, the value of the Printer attributes MAY vary with "document-format" supplied in the request without the specification having to indicate so.
6.3 Attribute Syntax Extensibility
6.3 Attribute Syntax Extensibility
Attribute syntaxes (see section 4.1) are like type2 enums. Therefore, new attribute syntaxes may be registered and have the same status as attribute syntaxes in this document by following the type2 extension rules described in Section 6.1. The initial set of value codes that identify each of the attribute syntaxes have been assigned in the "Encoding and Transport" document [RFC2910], including a designated range for vendor extension.
Attribute syntaxes (see section 4.1) are like type2 enums. Therefore, new attribute syntaxes may be registered and have the same status as attribute syntaxes in this document by following the type2 extension rules described in Section 6.1. The initial set of value codes that identify each of the attribute syntaxes have been assigned in the "Encoding and Transport" document [RFC2910], including a designated range for vendor extension.
For attribute syntaxes, the IPP Designated Expert in consultation with IANA assigns the next attribute syntax code in the appropriate range as specified in [RFC2910]. IANA will publish approved attribute syntax registration specifications as separate files:
For attribute syntaxes, the IPP Designated Expert in consultation with IANA assigns the next attribute syntax code in the appropriate range as specified in [RFC2910]. IANA will publish approved attribute syntax registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt
ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt
where 'xxx-yyy' is the new attribute syntax name.
where 'xxx-yyy' is the new attribute syntax name.
6.4 Operation Extensibility
6.4 Operation Extensibility
Operations (see section 3) may also be registered following the type2 procedures described in Section 6.1, though major new operations will usually be done by a new standards track RFC that augments this document. For vendor operation extensions, implementers MUST use the range for the "operation-id" in requests specified in Section 4.4.15 "operations-supported" Printer attribute.
Operations (see section 3) may also be registered following the type2 procedures described in Section 6.1, though major new operations will usually be done by a new standards track RFC that augments this document. For vendor operation extensions, implementers MUST use the range for the "operation-id" in requests specified in Section 4.4.15 "operations-supported" Printer attribute.
For operations, the IPP Designated Expert in consultation with IANA assigns the next operation-id code as specified in Section 4.4.15. IANA will publish approved operation registration specifications as separate files:
For operations, the IPP Designated Expert in consultation with IANA assigns the next operation-id code as specified in Section 4.4.15. IANA will publish approved operation registration specifications as separate files:
Hastings, et al. Standards Track [Page 152] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 152] RFC 2911 IPP/1.1: Model and Semantics September 2000
ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt
ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt
where "Xxx-Yyy" is the new operation name.
where "Xxx-Yyy" is the new operation name.
6.5 Attribute Group Extensibility
6.5 Attribute Group Extensibility
Attribute groups (see section 3.1.3) passed in requests and responses may be registered following the type2 procedures described in Section 6.1. The initial set of attribute group tags have been assigned in the "Encoding and Transport" document [RFC2910], including a designated range for vendor extension.
Attribute groups (see section 3.1.3) passed in requests and responses may be registered following the type2 procedures described in Section 6.1. The initial set of attribute group tags have been assigned in the "Encoding and Transport" document [RFC2910], including a designated range for vendor extension.
For attribute groups, the IPP Designated Expert in consultation with IANA assigns the next attribute group tag code in the appropriate range as specified in [RFC2910]. IANA will publish approved attribute group registration specifications as separate files:
For attribute groups, the IPP Designated Expert in consultation with IANA assigns the next attribute group tag code in the appropriate range as specified in [RFC2910]. IANA will publish approved attribute group registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
tag.txt
ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy- tag.txt
where 'xxx-yyy-tag' is the new attribute group tag name.
where 'xxx-yyy-tag' is the new attribute group tag name.
6.6 Status Code Extensibility
6.6 Status Code Extensibility
Operation status codes (see section 3.1.6.1) may also be registered following the type2 procedures described in Section 6.1. The values for status codes are allocated in ranges as specified in Section 14 for each status code class:
Operation status codes (see section 3.1.6.1) may also be registered following the type2 procedures described in Section 6.1. The values for status codes are allocated in ranges as specified in Section 14 for each status code class:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood, and
accepted
"redirection" - Further action must be taken in order to complete the
request
"client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid request
"informational" - Request received, continuing process "successful" - The action was successfully received, understood, and accepted "redirection" - Further action must be taken in order to complete the request "client-error" - The request contains bad syntax or cannot be fulfilled "server-error" - The IPP object failed to fulfill an apparently valid request
For vendor operation status code extensions, implementers MUST use the top of each range as specified in Section 13.
For vendor operation status code extensions, implementers MUST use the top of each range as specified in Section 13.
For operation status codes, the IPP Designated Expert in consultation with IANA assigns the next status code in the appropriate class range as specified in Section 13. IANA will publish approved status code registration specifications as separate files:
For operation status codes, the IPP Designated Expert in consultation with IANA assigns the next status code in the appropriate class range as specified in Section 13. IANA will publish approved status code registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt
ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt
Hastings, et al. Standards Track [Page 153] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 153] RFC 2911 IPP/1.1: Model and Semantics September 2000
where "xxx-yyy" is the new operation status code keyword.
where "xxx-yyy" is the new operation status code keyword.
6.7 Out-of-band Attribute Value Extensibility
6.7 Out-of-band Attribute Value Extensibility
Out-of-band attribute values (see the beginning of section 4.1) passed in requests and responses may be registered following the type2 procedures described in Section 6.1. The initial set of out- of-band attribute value tags have been assigned in the "Encoding and Transport" document [RFC2910].
Out-of-band attribute values (see the beginning of section 4.1) passed in requests and responses may be registered following the type2 procedures described in Section 6.1. The initial set of out- of-band attribute value tags have been assigned in the "Encoding and Transport" document [RFC2910].
For out-of-band attribute value tags, the IPP Designated Expert in consultation with IANA assigns the next out-of-band attribute value tag code in the appropriate range as specified in [RFC2910]. IANA will publish approved out-of-band attribute value tags registration specifications as separate files:
For out-of-band attribute value tags, the IPP Designated Expert in consultation with IANA assigns the next out-of-band attribute value tag code in the appropriate range as specified in [RFC2910]. IANA will publish approved out-of-band attribute value tags registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-
tags/xxx-yyy-tag.txt
ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value- tags/xxx-yyy-tag.txt
where 'xxx-yyy-tag' is the new out-of-band attribute value tag name.
where 'xxx-yyy-tag' is the new out-of-band attribute value tag name.
6.8 Registration of MIME types/sub-types for document-formats
6.8 Registration of MIME types/sub-types for document-formats
The "document-format" attribute's syntax is 'mimeMediaType'. This means that valid values are Internet Media Types (see Section 4.1.9). RFC 2045 [RFC2045] defines the syntax for valid Internet media types. IANA is the registry for all Internet media types.
The "document-format" attribute's syntax is 'mimeMediaType'. This means that valid values are Internet Media Types (see Section 4.1.9). RFC 2045 [RFC2045] defines the syntax for valid Internet media types. IANA is the registry for all Internet media types.
6.9 Registration of charsets for use in 'charset' attribute values
6.9 Registration of charsets for use in 'charset' attribute values
The "attributes-charset" attribute's syntax is 'charset'. This means that valid values are charsets names. When a charset in the IANA registry has more than one name (alias), the name labeled as "(preferred MIME name)", if present, MUST be used (see Section 4.1.7). IANA is the registry for charsets following the procedures of [RFC2278].
The "attributes-charset" attribute's syntax is 'charset'. This means that valid values are charsets names. When a charset in the IANA registry has more than one name (alias), the name labeled as "(preferred MIME name)", if present, MUST be used (see Section 4.1.7). IANA is the registry for charsets following the procedures of [RFC2278].
7. Internationalization Considerations
7. Internationalization Considerations
Some of the attributes have values that are text strings and names which are intended for human understanding rather than machine understanding (see the 'text' and 'name' attribute syntaxes in Sections 4.1.1 and 4.1.2).
Some of the attributes have values that are text strings and names which are intended for human understanding rather than machine understanding (see the 'text' and 'name' attribute syntaxes in Sections 4.1.1 and 4.1.2).
In each operation request, the client
In each operation request, the client
- identifies the charset and natural language of the request which
affects each supplied 'text' and 'name' attribute value, and
- identifies the charset and natural language of the request which affects each supplied 'text' and 'name' attribute value, and
Hastings, et al. Standards Track [Page 154] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 154] RFC 2911 IPP/1.1: Model and Semantics September 2000
- requests the charset and natural language for attributes
returned by the IPP object in operation responses (as described
in Section 3.1.4.1).
- requests the charset and natural language for attributes returned by the IPP object in operation responses (as described in Section 3.1.4.1).
In addition, the client MAY separately and individually identify the Natural Language Override of a supplied 'text' or 'name' attribute using the 'textWithLanguage' and 'nameWithLanguage' technique described section 4.1.1.2 and 4.1.2.2 respectively.
In addition, the client MAY separately and individually identify the Natural Language Override of a supplied 'text' or 'name' attribute using the 'textWithLanguage' and 'nameWithLanguage' technique described section 4.1.1.2 and 4.1.2.2 respectively.
All IPP objects MUST support the UTF-8 [RFC2279] charset in all 'text' and 'name' attributes supported. If an IPP object supports more than the UTF-8 charset, the object MUST convert between them in order to return the requested charset to the client according to Section 3.1.4.2. If an IPP object supports more than one natural language, the object SHOULD return 'text' and 'name' values in the natural language requested where those values are generated by the Printer (see Section 3.1.4.1).
All IPP objects MUST support the UTF-8 [RFC2279] charset in all 'text' and 'name' attributes supported. If an IPP object supports more than the UTF-8 charset, the object MUST convert between them in order to return the requested charset to the client according to Section 3.1.4.2. If an IPP object supports more than one natural language, the object SHOULD return 'text' and 'name' values in the natural language requested where those values are generated by the Printer (see Section 3.1.4.1).
For Printers that support multiple charsets and/or multiple natural languages in 'text' and 'name' attributes, different jobs may have been submitted in differing charsets and/or natural languages. All responses MUST be returned in the charset requested by the client. However, the Get-Jobs operation uses the 'textWithLanguage' and 'nameWithLanguage' mechanism to identify the differing natural languages with each job attribute returned.
For Printers that support multiple charsets and/or multiple natural languages in 'text' and 'name' attributes, different jobs may have been submitted in differing charsets and/or natural languages. All responses MUST be returned in the charset requested by the client. However, the Get-Jobs operation uses the 'textWithLanguage' and 'nameWithLanguage' mechanism to identify the differing natural languages with each job attribute returned.
The Printer object also has configured charset and natural language attributes. The client can query the Printer object to determine the list of charsets and natural languages supported by the Printer object and what the Printer object's configured values are. See the "charset-configured", "charset-supported", "natural-language- configured", and "generated-natural-language-supported" Printer description attributes for more details.
The Printer object also has configured charset and natural language attributes. The client can query the Printer object to determine the list of charsets and natural languages supported by the Printer object and what the Printer object's configured values are. See the "charset-configured", "charset-supported", "natural-language- configured", and "generated-natural-language-supported" Printer description attributes for more details.
The "charset-supported" attributed identifies the supported charsets. If a charset is supported, the IPP object MUST be capable of converting to and from that charset into any other supported charset. In many cases, an IPP object will support only one charset and it MUST be the UTF-8 charset.
The "charset-supported" attributed identifies the supported charsets. If a charset is supported, the IPP object MUST be capable of converting to and from that charset into any other supported charset. In many cases, an IPP object will support only one charset and it MUST be the UTF-8 charset.
The "charset-configured" attribute identifies the one supported charset which is the native charset given the current configuration of the IPP object (administrator defined).
The "charset-configured" attribute identifies the one supported charset which is the native charset given the current configuration of the IPP object (administrator defined).
The "generated-natural-language-supported" attribute identifies the set of supported natural languages for generated messages; it is not related to the set of natural languages that must be accepted for client supplied 'text' and 'name' attributes. For client supplied
The "generated-natural-language-supported" attribute identifies the set of supported natural languages for generated messages; it is not related to the set of natural languages that must be accepted for client supplied 'text' and 'name' attributes. For client supplied
Hastings, et al. Standards Track [Page 155] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 155] RFC 2911 IPP/1.1: Model and Semantics September 2000
'text' and 'name' attributes, an IPP object MUST accept ALL supplied natural languages. Just because a Printer object is currently configured to support 'en-us' natural language does not mean that the Printer object should reject a job if the client supplies a job name that is in 'fr-ca'.
'text' and 'name' attributes, an IPP object MUST accept ALL supplied natural languages. Just because a Printer object is currently configured to support 'en-us' natural language does not mean that the Printer object should reject a job if the client supplies a job name that is in 'fr-ca'.
The "natural-language-configured" attribute identifies the one supported natural language for generated messages which is the native natural language given the current configuration of the IPP object (administrator defined).
The "natural-language-configured" attribute identifies the one supported natural language for generated messages which is the native natural language given the current configuration of the IPP object (administrator defined).
Attributes of type 'text' and 'name' are populated from different sources. These attributes can be categorized into following groups (depending on the source of the attribute):
Attributes of type 'text' and 'name' are populated from different sources. These attributes can be categorized into following groups (depending on the source of the attribute):
1. Some attributes are supplied by the client (e.g., the client
supplied "job-name", "document-name", and "requesting-user-
name" operation attributes along with the corresponding Job
object's "job-name" and "job-originating-user-name"
attributes). The IPP object MUST accept these attributes in
any natural language no matter what the set of supported
languages for generated messages
2. Some attributes are supplied by the system administrator (e.g.,
the Printer object's "printer-name" and "printer-location"
attributes). These too can be in any natural language. If the
natural language for these attributes is different than what a
client requests, then they must be reported using the Natural
Language Override mechanism.
3. Some attributes are supplied by the device manufacturer (e.g.,
the Printer object's "printer-make-and-model" attribute).
These too can be in any natural language. If the natural
language for these attributes is different than what a client
requests, then they must be reported using the Natural Language
Override mechanism.
4. Some attributes are supplied by the operator (e.g., the Job
object's "job-message-from-operator" attribute). These too can
be in any natural language. If the natural language for these
attributes is different than what a client requests, then they
must be reported using the Natural Language Override mechanism.
5. Some attributes are generated by the IPP object (e.g., the Job
object's "job-state-message" attribute, the Printer object's
"printer-state-message" attribute, and the "status-message"
operation attribute). These attributes can only be in one of
the "generated-natural-language-supported" natural languages.
If a client requests some natural language for these attributes
other than one of the supported values, the IPP object SHOULD
1. Some attributes are supplied by the client (e.g., the client supplied "job-name", "document-name", and "requesting-user- name" operation attributes along with the corresponding Job object's "job-name" and "job-originating-user-name" attributes). The IPP object MUST accept these attributes in any natural language no matter what the set of supported languages for generated messages 2. Some attributes are supplied by the system administrator (e.g., the Printer object's "printer-name" and "printer-location" attributes). These too can be in any natural language. If the natural language for these attributes is different than what a client requests, then they must be reported using the Natural Language Override mechanism. 3. Some attributes are supplied by the device manufacturer (e.g., the Printer object's "printer-make-and-model" attribute). These too can be in any natural language. If the natural language for these attributes is different than what a client requests, then they must be reported using the Natural Language Override mechanism. 4. Some attributes are supplied by the operator (e.g., the Job object's "job-message-from-operator" attribute). These too can be in any natural language. If the natural language for these attributes is different than what a client requests, then they must be reported using the Natural Language Override mechanism. 5. Some attributes are generated by the IPP object (e.g., the Job object's "job-state-message" attribute, the Printer object's "printer-state-message" attribute, and the "status-message" operation attribute). These attributes can only be in one of the "generated-natural-language-supported" natural languages. If a client requests some natural language for these attributes other than one of the supported values, the IPP object SHOULD
Hastings, et al. Standards Track [Page 156] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 156] RFC 2911 IPP/1.1: Model and Semantics September 2000
respond using the value of the "natural-language-configured"
attribute (using the Natural Language Override mechanism if
needed).
「構成された自然な言語」属性の値を使用することで(必要であるならNatural Language Overrideメカニズムを使用して)、応じてください。
The 'text' and 'name' attributes specified in this version of this document (additional ones will be registered according to the procedures in Section 6) are:
属性というこのドキュメント(セクション6の手順によると、追加ものは登録される)のこのバージョンで指定された'テキスト'と'名前'は以下の通りです。
Attributes Source
属性ソース
Operation Attributes:
job-name (name) client
document-name (name) client
requesting-user-name (name) client
status-message (text) Job or Printer object
detailed-status-message (text) Job or Printer object -
see rule 1
document-access-error (text) Job or Printer object -
see rule 1
操作属性: ジョブ名(名前)クライアントドキュメント名の(名前)クライアント要求ユーザ名(名前)クライアントステータスメッセージ(テキスト)仕事かPrinterオブジェクト詳細なステータスメッセージ(テキスト)の仕事かPrinterが反対します--規則1ドキュメントアクセスエラー(テキスト)仕事かPrinterが反対するのを見てください--規則1を見てください。
Job Template Attributes:
job-hold-until (keyword | name) client matches
administrator-configured
job-hold-until-default (keyword | name) client matches
administrator-configured
job-hold-until-supported (keyword | client matches
name) administrator-configured
job-sheets (keyword | name) client matches
administrator-configured
job-sheets-default (keyword | name) client matches
administrator-configured
job-sheets-supported (keyword | name) client matches
administrator-configured
media (keyword | name) client matches
administrator-configured
media-default (keyword | name) client matches
administrator-configured
media-supported (keyword | name) client matches
administrator-configured
media-ready (keyword | name) client matches
administrator-configured
仕事のテンプレート属性: 仕事の保持、(キーワード| 名前)クライアントマッチは、デフォルトまでの仕事の保持(キーワード| 名前)クライアントが管理者によって構成された仕事のシートデフォルト(キーワード| 名前)クライアントマッチが管理者と同じくらい構成したサポートされるまでの管理者によって構成された仕事の保持(キーワード| マッチが命名するクライアント)の管理者によって構成された仕事シート(キーワード| 名前)クライアントマッチに合っているのを管理者と同じくらい構成しました; 管理者によって構成されたメディア(キーワード| 名前)クライアントが合っているシートがサポートした仕事(キーワード| 名前)のクライアントマッチは、メディアデフォルト(キーワード| 名前)クライアントが管理者によって構成されたメディア持ち合わせ(キーワード| 名前)のクライアントマッチが管理者と同じくらい構成した管理者によって構成されたメディアによってサポートされた(キーワード| 名前)クライアントマッチに合っているのを管理者と同じくらい構成しました。
Job Description Attributes:
job-name (name) client or Printer object
job-originating-user-name (name) Printer object
job-state-message (text) Job or Printer object
output-device-assigned (name(127)) administrator
job-message-from-operator (text(127)) operator
職務記述書属性: ジョブ名(名前)クライアント、Printerオブジェクト仕事の起因するユーザ名(名前)プリンタオブジェクト仕事の州のメッセージ(テキスト)仕事または選任されたPrinterオブジェクト出力デバイス、(オペレータからの名前(127))管理者仕事のメッセージ、(テキスト(127))オペレータ
Hastings, et al. Standards Track [Page 157] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[157ページ]: モデルと意味論2000年9月
job-detailed-status-messages (1setOf Job or Printer object -
text) see rule 1
job-document-access-errors (1setOf Job or Printer object -
text) see rule 1
仕事はステータスメッセージを詳しく述べました。規則1仕事のドキュメントアクセスエラーを見てください。(1setOf JobかPrinterが反対します--、テキスト)、(1setOf JobかPrinterが反対します--、テキスト)、規則1を見てください。
Printer Description Attributes:
printer-name (name(127)) administrator
printer-location (text(127)) administrator
printer-info (text(127)) administrator
printer-make-and-model (text(127)) administrator or
manufacturer
printer-state-message (text) Printer object
printer-message-from-operator operator
(text(127))
プリンタ記述属性: プリンタ名、(管理者プリンタ位置と(127))を命名してください、(テキスト(127))管理者プリンタインフォメーション、(テキスト(127))管理者プリンタメーカーとモデル、(テキスト(127))管理者かメーカープリンタ州のメッセージ(テキスト)プリンタオブジェクトオペレータからのプリンタメッセージオペレータ(テキスト(127))
Rule 1 - Neither the Printer nor the client localizes these message attributes, since they are intended for use by the system administrator or other experienced technical persons.
規則1--Printerもクライアントもこれらのメッセージ属性をローカライズしません、それらが使用のためにシステム管理者か他の経験豊富な技術人々によって意図されるので。
8. Security Considerations
8. セキュリティ問題
It is difficult to anticipate the security risks that might exist in any given IPP environment. For example, if IPP is used within a given corporation over a private network, the risks of exposing document data may be low enough that the corporation will choose not to use encryption on that data. However, if the connection between the client and the IPP object is over a public network, the client may wish to protect the content of the information during transmission through the network with encryption.
IPP環境を考えて、いずれにも存在するかもしれないセキュリティ危険を予期するのは難しいです。 例えば、IPPが私設のネットワークの上で与えられた会社の中で使用されるなら、ドキュメントデータを暴露するリスクは会社が、そのデータで暗号化を使用しないのを選ぶほど低いかもしれません。 しかしながら、公衆通信回線の上にクライアントとIPPオブジェクトとの接続があるなら、クライアントはネットワークを通した暗号化によるトランスミッションの間、情報の内容を保護したがっているかもしれません。
Furthermore, the value of the information being printed may vary from one IPP environment to the next. Printing payroll checks, for example, would have a different value than printing public information from a file. There is also the possibly of denial-of- service attacks, but denial-of-service attacks against printing resources are not well understood and there is no published precedents regarding this scenario.
その上、印刷される情報の価値は1つのIPP環境から次に異なるかもしれません。 例えば、給料支払名簿チェックを印刷するのにおいて、異価がファイルから公開情報を印刷するよりあるでしょう。 また、ある、-サービス攻撃では、リソースを印刷するサービス不能攻撃だけが良くないということによると否定には、このシナリオに関する発行された先例は、全く分かって、ありません。
Once the authenticated identity of the requester has been supplied to the IPP object, the object uses that identity to enforce any authorization policy that might be in place. For example, one site's policy might be that only the job owner is allowed to cancel a job. The details and mechanisms to set up a particular access control policy are not part of IPP/1.1, and must be established via some other type of administrative or access control framework. However, there are operation status codes that allow an IPP server to return information back to a client about any potential access control violations for an IPP object.
いったんリクエスタの認証されたアイデンティティをIPPオブジェクトに供給すると、オブジェクトは、適所にあるどんな承認方針も実施するのにそのアイデンティティを使用します。 例えば、1つのサイトの方針は仕事の所有者だけが仕事を中止できるということであるかもしれません。 特定のアクセス制御方針に設定する詳細とメカニズムをIPP/1.1の一部でなく、ある他のタイプの管理かアクセス制御フレームワークで確立しなければなりません。 しかしながら、IPPサーバがIPPオブジェクトのためのどんな潜在的アクセス制御違反に関しても情報をクライアントに返して戻すことができる操作ステータスコードがあります。
Hastings, et al. Standards Track [Page 158] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[158ページ]: モデルと意味論2000年9月
During a create operation, the client's identity is recorded in the Job object in an implementation-defined attribute. This information can be used to verify a client's identity for subsequent operations on that Job object in order to enforce any access control policy that might be in effect. See section 8.3 below for more details.
aの間、操作を作成してください、そして、クライアントのアイデンティティは実装で定義された属性でJobオブジェクトに記録されます。 どんな有効であるかもしれないアクセス制御方針も実施して、その後の操作のためにそのJobオブジェクトの上にクライアントのアイデンティティについて確かめるのにこの情報を使用できます。 その他の詳細に関して下のセクション8.3を見てください。
Since the security levels or the specific threats that an IPP system administrator may be concerned with cannot be anticipated, IPP MUST be capable of operating with different security mechanisms and security policies as required by the individual installation. Security policies might vary from very strong, to very weak, to none at all, and corresponding security mechanisms will be required.
IPP MUST、以来に、IPPシステム管理者に関するかもしれないセキュリティー・レベルか特定の脅威を予期できません。必要に応じて個々のインストールで異なったセキュリティー対策と安全保障政策で作動できてください。 安全保障政策は非常に強いのと異なるかもしれません、非常に弱く、全くなにもにそうしません、そして、対応するセキュリティー対策が必要でしょう。
8.1 Security Scenarios
8.1 セキュリティシナリオ
The following sections describe specific security attacks for IPP environments. Where examples are provided they should be considered illustrative of the environment and not an exhaustive set. Not all of these environments will necessarily be addressed in initial implementations of IPP.
以下のセクションはIPP環境のための特定のセキュリティー攻撃について説明します。 例を提供するところでは、それらは徹底的なセットではなく、環境で説明に役立つと考えられるべきです。 これらの環境のすべてが必ずIPPの初期の実装で扱われるというわけではないでしょう。
8.1.1 Client and Server in the Same Security Domain
8.1.1 同じセキュリティー領域のクライアントとサーバ
This environment is typical of internal networks where traditional office workers print the output of personal productivity applications on shared work-group printers, or where batch applications print their output on large production printers. Although the identity of the user may be trusted in this environment, a user might want to protect the content of a document against such attacks as eavesdropping, replaying or tampering.
この環境は伝統的な事務員が共有されたワークグループプリンタに個人的な生産性アプリケーションの出力を印刷するか、またはバッチアプリケーションが大量生産プリンタに彼らの出力を印刷する内部のネットワークの典型です。 ユーザのアイデンティティはこの環境で信じられるかもしれませんが、ユーザは盗み聞くか、再演するか、またはいじるような攻撃に対してドキュメントの中身を保護したがっているかもしれません。
8.1.2 Client and Server in Different Security Domains
8.1.2 異なったセキュリティー領域のクライアントとサーバ
Examples of this environment include printing a document created by the client on a publicly available printer, such as at a commercial print shop; or printing a document remotely on a business associate's printer. This latter operation is functionally equivalent to sending the document to the business associate as a facsimile. Printing sensitive information on a Printer in a different security domain requires strong security measures. In this environment authentication of the printer is required as well as protection against unauthorized use of print resources. Since the document crosses security domains, protection against eavesdropping and document tampering are also required. It will also be important in this environment to protect Printers against "spamming" and malicious document content.
この環境に関する例は、クライアントによって公的に利用可能なプリンタに作成されたドキュメントを印刷するのを含んでいます、商業印刷所などのように。 または、ビジネス関連のときにドキュメントを離れて印刷するのは、プリンタです。 この後者の操作はファクシミリとしてドキュメントを仕事関係者に送るのに機能上同等です。 異なったセキュリティー領域のPrinterに関する機密情報を印刷するのは強い安全策を必要とします。 この環境で、印刷リソースの無断使用に対する保護と同様にプリンタの認証が必要です。 ドキュメントがセキュリティー領域に交差しているので、また、盗聴に対する保護とドキュメント改ざんが必要です。 また、「ばらまくこと」と悪意があるドキュメント内容に対してPrintersを保護するのもこの環境で重要でしょう。
Hastings, et al. Standards Track [Page 159] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[159ページ]: モデルと意味論2000年9月
8.1.3 Print by Reference
8.1.3 参照で、印刷してください。
When the document is not stored on the client, printing can be done by reference. That is, the print request can contain a reference, or pointer, to the document instead of the actual document itself (see sections 3.2.2 and 3.3.2). Standard methods currently do not exist for remote entities to "assume" the credentials of a client for forwarding requests to a 3rd party. It is anticipated that Print-By- Reference will be used to access "public" documents and that sophisticated methods for authenticating "proxies" is not specified in this document.
クライアントの上にドキュメントを保存しないとき、参照で印刷できます。 セクション3.2.2と3.3を見てください。すなわち、印刷要求は参照、または指針を含むことができます、実際のドキュメント自体の代わりにドキュメントに(.2)。 リモート実体が推進要求のために3番目のパーティーにクライアントの資格証明書を「仮定する」ように、標準方法は現在、存在しません。 近くPrint参照が「公共」のドキュメントにアクセスするのに使用されて、「プロキシ」を認証するのがあるので高度なメソッドが本書では指定しなかったと予期されます。
8.2 URIs in Operation, Job, and Printer attributes
8.2 Operation、Job、およびPrinter属性におけるURI
The "printer-uri-supported" attribute contains the Printer object's URI(s). Its companion attribute, "uri-security-supported", identifies the security mechanism used for each URI listed in the "printer-uri-supported" attribute. For each Printer operation request, a client MUST supply only one URI in the "printer-uri" operation attribute. In other words, even though the Printer supports more than one URI, the client only interacts with the Printer object using one if its URIs. This duality is not needed for Job objects, since the Printer objects is the factory for Job objects, and the Printer object will generate the correct URI for new Job objects depending on the Printer object's security configuration.
「uriが支えたプリンタ」属性はPrinterオブジェクトのURIを含んでいます。 「セキュリティがサポートしたuri」という仲間属性は「uriが支えたプリンタ」属性で記載された各URIに使用されるセキュリティー対策を特定します。 それぞれのPrinter操作要求のために、クライアントは「プリンタ-uri」操作属性における1つのURIだけを供給しなければなりません。 言い換えれば、Printerは1つ以上のURIをサポートしますが、クライアントは、URIであるなら1つを使用することでPrinterオブジェクトと対話するだけです。 この二重性はJobオブジェクトに必要ではありません、Printer目的がJobオブジェクトのための工場であり、PrinterオブジェクトがPrinterオブジェクトのセキュリティ設定による新しいJobオブジェクトのために正しいURIを生成するので。
8.3 URIs for each authentication mechanisms
各認証あたり8.3のURI、メカニズム
Each URI has an authentication mechanism associated with it. If the URI is the i'th element of "printer-uri-supported", then authentication mechanism is the "i th" element of "uri- authentication-supported". For a list of possible authentication mechanisms, see section 4.4.2.
各URIには、それに関連している認証機構があります。 URIが「uriが支えたプリンタ」のi'th要素であるなら、次に、認証機構が要素である、「i、」 「uriに認証でサポートされること」の第要素。 可能な認証機構のリストに関しては、セクション4.4.2を見てください。
The Printer object uses an authentication mechanism to determine the name of the user performing an operation. This user is called the "authenticated user". The credibility of authentication depends on the mechanism that the Printer uses to obtain the user's name. When the authentication mechanism is 'none', all authenticated users are "anonymous".
Printerオブジェクトは、操作を実行しているユーザの名前を決定するのに認証機構を使用します。 このユーザは「認証されたユーザ」と呼ばれます。 認証の真実性はPrinterがユーザの名前を得るのに使用するメカニズムによります。 認証機構が'なにも'であるときに、すべての認証されたユーザが「匿名です」。
During job creation operations, the Printer initializes the value of the "job-originating-user-name" attribute (see section 4.3.6) to be the authenticated user. The authenticated user is this case is called the "job owner".
雇用創出操作の間、Printerは、認証されたユーザになるように「仕事の起因するユーザ名」属性(セクション4.3.6を見る)の値を初期化します。 認証されたユーザは本件が「仕事の所有者」と呼ばれるということです。
Hastings, et al. Standards Track [Page 160] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[160ページ]: モデルと意味論2000年9月
If an implementation can be configured to support more than one authentication mechanism (see section 4.4.2), then it MUST implement rules for determining equality of authenticated user names which have been authenticated via different authentication mechanisms. One possible policy is that identical names that are authenticated via different mechanisms are different. For example, a user can cancel his job only if he uses the same authentication mechanism for both Cancel-Job and Print-Job. Another policy is that identical names that are authenticated via different mechanism are the same if the authentication mechanism for the later operation is not less strong than the authentication mechanism for the earlier job creation operation. For example, a user can cancel his job only if he uses the same or stronger authentication mechanism for Cancel-Job and Print-Job. With this second policy a job submitted via 'requesting- user-name' authentication could be canceled via 'digest' authentication. With the first policy, the job could not be canceled in this way.
1台以上の認証機構をサポートするために実装を構成できるなら(セクション4.4.2を見てください)、それは異なった認証機構で認証された認証されたユーザ名の平等を決定するための規則を実装しなければなりません。1つの可能な方針は異なったメカニズムで認証される同じ名前が異なっているということです。 例えば、キャンセル仕事とPrint-仕事の両方に同じ認証機構を使用する場合にだけ、ユーザは彼の仕事を中止できます。 別の方針は以前の雇用創出操作には、後の操作のための認証機構が認証機構ほど強くないというわけではないなら異なったメカニズムで認証される同じ名前が同じであるということです。 例えば、キャンセル仕事とPrint-仕事に同じであるか、より強い認証機構を使用する場合にだけ、ユーザは彼の仕事を中止できます。 この2番目の方針で、'ダイジェスト'認証で'要求ユーザ名'認証で提出された仕事は中止できるでしょう。 最初の方針で、このように仕事を中止できないでしょう。
A client is able to determine the authentication mechanism used to create a job. It is the i'th value of the Printer's "uri- authentication-supported" attribute (see section 4.4.2), where i is the index of the element of the Printer's "printer-uri-supported" attribute (see section 4.4.1) equal to the job's "job-printer-uri" attribute (see section 4.3.3).
クライアントは、認証機構が雇用を創り出したことを決定できます。 それはPrinterの「uriに認証でサポートしている」属性(セクション4.4.2を見る)のi'th値です。そこでは、iがPrinterの仕事の「賃仕事のプリンタuri」属性と等しい「uriが支えたプリンタ」属性(セクション4.4.1を見る)の要素のインデックス(セクション4.3.3を見る)です。
8.4 Restricted Queries
8.4 制限された質問
In many IPP operations, a client supplies a list of attributes to be returned in the response. For security reasons, an IPP object may be configured not to return all attributes (or all values) that a client requests. The job attributes returned MAY depend on whether the requesting user is the same as the user that submitted the job. The IPP object MAY even return none of the requested attributes. In such cases, the status returned is the same as if the object had returned all requested attributes. The client cannot tell by such a response whether the requested attribute was present or absent on the object.
多くのIPP操作では、クライアントは応答で返される属性のリストを提供します。 安全保障上の理由で、IPPオブジェクトは、クライアントが要求するすべての属性(または、すべての値)を返さないように構成されるかもしれません。 属性が返した仕事は要求しているユーザが仕事を提出したユーザと同じであるかどうかよるかもしれません。 IPPオブジェクトは要求された属性のいずれも返してさえいないかもしれません。 そのような場合、まるでオブジェクトがすべての要求された属性を返したかのように返された状態は同じです。 クライアントは、要求された属性にオブジェクトで現在である、または欠けていたかそのような応答でわかりません。
8.5 Operations performed by operators and system administrators
8.5の操作がオペレータとシステム管理者で働きました。
For the three printer operations Pause-Printer, Resume-Printer, and Purge-Jobs (see sections 3.2.7, 3.2.8 and 3.2.9), the requesting user is intended to be an operator or administrator of the Printer object (see section 1). Otherwise, the IPP Printer MUST reject the operation and return: 'client-error-forbidden', 'client-error-not- authenticated', or 'client-error-not-authorized' as appropriate. For operations on jobs, the requesting user is intended to be the job
そして、3プリンタ操作Pause-プリンタ、Resume-プリンタ、およびPurge-ジョブス、(セクション3.2.7、3.2を見てください、.8、3.2 .9) 要求しているユーザはPrinterオブジェクトのオペレータか管理者であることを意図します(セクション1を見てください)。 さもなければ、IPP Printerは操作を拒絶して、戻らなければなりません: ''禁じられたクライアント誤り'、'クライアント誤りで認証されなかった'認可されなかったクライアント誤り'、適宜。 仕事の操作において、要求しているユーザは仕事であることを意図します。
Hastings, et al. Standards Track [Page 161] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[161ページ]: モデルと意味論2000年9月
owner or may be an operator or administrator of the Printer object. The means for authorizing an operator or administrator of the Printer object are not specified in this document.
所有者、Printerオブジェクトのオペレータか管理者がそうです。 Printerオブジェクトのオペレータか管理者に権限を与えるための手段は本書では指定されません。
8.6 Queries on jobs submitted using non-IPP protocols
仕事の8.6の質問が、非IPPプロトコルを使用することで提出されました。
If the device that an IPP Printer is representing is able to accept jobs using other job submission protocols in addition to IPP, it is RECOMMENDED that such an implementation at least allow such "foreign" jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as 'unknown'. Such an implementation NEED NOT support all of the same IPP job attributes as for IPP jobs. The IPP object returns the 'unknown' out-of-band value for any requested attribute of a foreign job that is supported for IPP jobs, but not for foreign jobs.
IPP Printerが表しているデバイスがIPPに加えた他のジョブ依頼プロトコルを使用することで仕事を受け入れることができるなら、そのような実装が、そのような「外国」の仕事が質問されるのを'未知'のGet-ジョブスの戻っている「仕事イド」と「仕事-uri」を使用することで少なくとも許容するのは、RECOMMENDEDです。 そのような実装はIPP仕事のように同じIPP仕事の属性のすべてをサポートする必要はありません。 IPPオブジェクトは、IPP仕事のためにサポートされる外国仕事のどんな要求された属性のためにもバンドで出ている'未知'の値を返しますが、外国仕事のために返すというわけではありません。
It is further RECOMMENDED, that the IPP Printer generate "job-id" and "job-uri" values for such "foreign jobs", if possible, so that they may be targets of other IPP operations, such as Get-Job-Attributes and Cancel-Job. Such an implementation also needs to deal with the problem of authentication of such foreign jobs. One approach would be to treat all such foreign jobs as belonging to users other than the user of the IPP client. Another approach would be for the foreign job to belong to 'anonymous'. Only if the IPP client has been authenticated as an operator or administrator of the IPP Printer object, could the foreign jobs be queried by an IPP request. Alternatively, if the security policy is to allow users to query other users' jobs, then the foreign jobs would also be visible to an end-user IPP client using Get-Jobs and Get-Job-Attributes.
それが一層のRECOMMENDEDである、IPP Printerが「仕事イド」と「仕事-uri」を生成するのがそのようなもののために「外国仕事」を評価します、できれば、それらが他のIPP操作の目標であることができるように、Get仕事の属性やキャンセル仕事のように。 また、そのような実装は、そのような外国仕事の認証の問題に対処する必要があります。 1つのアプローチはIPPクライアントのユーザ以外のユーザに属すようなすべての外国仕事を扱うだろうことです。 別のアプローチは外国仕事が'匿名'に属するだろうことです。 IPPクライアントがIPP Printerオブジェクトのオペレータか管理者として認証された場合にだけ、外国仕事はIPP要求で質問されるかもしれませんか? あるいはまた、また、安全保障政策がユーザが他のユーザの仕事について質問するのを許容することであるなら、エンドユーザIPPクライアントにとって、外国仕事もGet-仕事とGet仕事の属性を使用するのにおいて目に見えるでしょう。
9. References
9. 参照
[ASME-Y14.1M] Metric Drawing Sheet Size and Format, ASME Y14.1M-1995.
This standard defines metric sheet sizes and formats
for engineering drawings.
[ASME-Y14.1M]メートル法の描いているシートサイズと形式、ASME Y14.1M-1995。 この規格は機械製図のためにメートル法のシートサイズと書式を定義します。
[ASCII] Coded Character Set - 7-bit American Standard Code for
Information Interchange (ASCII), ANSI X3.4-1986. This
standard is the specification of the US-ASCII charset.
[ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード(ASCII)、ANSI X3.4-1986。 この規格は米国-ASCII charsetの仕様です。
[BCP-11] Bradner S. and R. Hovey, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[BCP-11] ブラドナーS.とR.ハービ、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。
[HTPP] J. Barnett, K. Carter, R. DeBry, "Initial Draft -
Hypertext Printing Protocol - HTPP/1.0", October 1996,
ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz
[HTPP] J.バーネット、K.カーター、R.DeBryは「草稿--ハイパーテキスト印刷プロトコル--HTPP/1インチ、1996年10月、 ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz に頭文字をつけます」。
Hastings, et al. Standards Track [Page 162] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[162ページ]: モデルと意味論2000年9月
[IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IANA-まやかし] Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[IANA-CS] IANA Registry of Coded Character Sets:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets
[IANA-Cs] コード化文字集合のIANA登録: ftp://ftp.isi.edu/in-notes/iana/assignments/character- セット
[IANA-MT] IANA Registry of Media Types: ftp://ftp.isi.edu/in-
notes/iana/assignments/media-types/
[IANA-MT] メディアのIANA登録はタイプされます: ftp://ftp.isi.edu/in- メディア注意/iana/課題/タイプ/
[IPP-IIG] Hastings, T., Manros, C., Kugler, C., Holst, H., and P.
Zehler, "Internet Printing Protocol/1.1: draft-ietf-
ipp-implementers-guide-v11-01.txt, work in progress,
May 30, 2000.
[IPP-IIG] ヘイスティングズ、T.、Manros、C.、クーグラー、C.、ホルスト、H.、およびP.Zehler、「プロトコル/1.1に以下を印刷するインターネット」 2000年5月30日にietf- ipp-implementersガイドv11-01.txtを作成してください、そして、進行中で働いてください。
[ISO10646-1] ISO/IEC 10646-1:1993, "Information technology --
Universal Multiple-Octet Coded Character Set (UCS) -
Part 1: Architecture and Basic Multilingual Plane,
JTC1/SC2."
[ISO10646-1]ISO/IEC10646-1:1993、「情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部:、」 「アーキテクチャと基本多言語水準、JTC1/SC2。」
[ISO8859-1] ISO/IEC 8859-1:1987, "Information technology -- 8-bit
One-Byte Coded Character Set - Part 1: Latin Alphabet
Nr 1", 1987, JTC1/SC2.
[ISO8859-1]ISO/IEC8859-1:1987、「情報技術--8ビットのOne-バイトCoded文字コード--第1部:、」 ローマ字Nr、1インチ、1987、JTC1/SC2。
[ISO10175] ISO/IEC 10175 Document Printing Application (DPA), June
1996.
[ISO10175]ISO/IEC10175は印刷アプリケーション(DPA)、1996年6月を記録します。
[LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D.
Taylor, P. Zehler, "LDPA - Lightweight Document
Printing Application", October 1996,
ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
[LDPA]T.ヘイスティングズ、S.イサクソン、M.マッケイ、C.Manros、D.テイラー、P.Zehler、「LDPA--ライト級は印刷アプリケーションを記録します」、1996年10月、 ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
[P1387.4] Kirk, M. (editor), POSIX System Administration - Part
4: Printing Interfaces, POSIX 1387.4 D8, 1994.
[P1387.4]カーク、POSIXシステム管理のM.(エディタ)--パート4: インタフェース、POSIX1387.4D8、1994を印刷します。
[PSIS] Herriot, R. (editor), X/Open A Printing System
Interoperability Specification (PSIS), August 1995.
[PSIS]エリオ、R.(エディタ)、システム相互運用性仕様(PSIS)を印刷するX/Open A、1995年8月。
[PWG] Printer Working Group, http://www.pwg.org.
[PWG] プリンタ作業部会、 http://www.pwg.org 。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC
1179, August 1990.
[RFC1179] マクラフリン、L.、「ラインプリンタデーモンプロトコル」、RFC1179、1990年8月。
Hastings, et al. Standards Track [Page 163] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[163ページ]: モデルと意味論2000年9月
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1759] スミスとR.とライトとF.とヘイスティングズとT.とZillesとS.と1995年のJ.Gyllenskog、「プリンタMIB」、RFC1759行進。
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1766]Alvestrand、H.、「言語の識別のためのタグ」、RFC1766、1995年3月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3 ", RFC 1951, May 1996.
[RFC1951] ドイツ語(P.、「DEFLATE Compressed Data Format Specificationバージョン1.3」、RFC1951)は1996がそうするかもしれません。
[RFC1952] Deutsch, P., "GZIP file format specification version
4.3", RFC 1952, May 1996.
ドイツ語、P.、[RFC1952]「GZIPは1996年5月に書式仕様バージョン4.3インチ、RFC1952をファイルします」。
[RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
August 1996.
[RFC1977] Schryver、V.、「ppp BSD圧縮プロトコル」、RFC1977、1996年8月。
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2045] Freed, N. and N. Borenstein, ", Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
「解放された[RFC2045]、N.、およびN.Borenstein」、マルチパーパスインターネットメールエクステンション(MIME)パート1: 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
解放された[RFC2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
解放された[RFC2048]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions",
RFC 2228, October 1997.
[RFC2228] ホロビッツとM.とS.ラント、「FTPセキュリティ拡大」、RFC2228、1997年10月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages" BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand、H.、「文字コードと言語に関するIETF方針」BCP18、RFC2277、1998年1月。
[RFC2278] Freed, N. and J. Postel: "IANA CharSet Registration
Procedures", BCP 19, RFC 2278, January 1998.
解放された[RFC2278]、N.、およびJ.ポステル: 「IANA CharSet登録手順」、BCP19、RFC2278、1998年1月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
Hastings, et al. Standards Track [Page 164] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[164ページ]: モデルと意味論2000年9月
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin、S.、「IABセキュリティー体系ワークショップのレポート」、RFC2316、1998年4月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
[RFC2565] エリオとR.とバトラーとS.とムーアとP.とR.ターナー、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2566] deBryとR.とヘイスティングズとT.とエリオとR.とイサクソンとS.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2567] ライト、D.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
[RFC2568]Zilles、S.、「インターネット印刷プロトコルのための構造、モデル、およびプロトコルのための原理」、RFC2568、1999年4月。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569,
April 1999.
[RFC2569] エリオとR.とヘイスティングズとT.とジェイコブズとN.とJ.マーチン、「LPDとIPPプロトコルの間のマッピング」、RFC2569、1999年4月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[RFC2617] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[RFC2639] Hastings, T. and C. Manros, "Internet Printing
Protocol/1.0: Encoding and Transport", RFC 2639, July
1999.
[RFC2639] ヘイスティングズとT.とC.Manros、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2639、7月1999日
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[RFC2910] エリオとR.とバトラーとS.とムーアとP.とターナーとR.とJ.Wenn、「プロトコル/1.1に以下を印刷するインターネット」 「コード化と輸送」、RFC2910、9月2000日
Hastings, et al. Standards Track [Page 165] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[165ページ]: モデルと意味論2000年9月
[SSL] Netscape, The SSL Protocol, Version 3, (Text version
3.02), November 1996.
[SSL]Netscape、SSLプロトコル、バージョン3、(テキストバージョン3.02)、1996年11月。
[SWP] P. Moore, B. Jahromi, S. Butler, "Simple Web Printing
SWP/1.0", May 7, 1997,
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf
[SWP] P.ムーア、B.Jahromi、S.バトラー、「簡単なウェブ印刷SWP/1インチ、1997年5月7日、 ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf 」
10. Authors' Addresses
10. 作者のアドレス
Scott A. Isaacson, Editor Novell, Inc. 122 E 1700 S Provo, UT 84606
スコット・A.イサクソン、エディタのノベルInc.122のEの1700秒間のプロボ、ユタ 84606
Phone: 801-861-7366 Fax: 801-861-2517 EMail: sisaacson@novell.com
以下に電話をしてください。 801-861-7366 Fax: 801-861-2517 メールしてください: sisaacson@novell.com
Tom Hastings Xerox Corporation 737 Hawaii St. ESAE 231 El Segundo, CA 90245
エルセガンド、トムヘイスティングズゼロックス社737のハワイ通りESAE231カリフォルニア 90245
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
以下に電話をしてください。 310-333-6413 Fax: 310-333-5514 メールしてください: hastings@cp10.es.xerox.com
Robert Herriot Xerox Corp. 3400 Hill View Ave, Building 1 Palo Alto, CA 94304
ヒル視点Ave、ロバートエリオゼロックス社3400のBuilding1パロアルト、カリフォルニア 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: robert.herriot@pahv.xerox.com
以下に電話をしてください。 650-813-7696 Fax: 650-813-6860 メールしてください: robert.herriot@pahv.xerox.com
Roger deBry Utah Valley State College Orem, UT 84058
ロジャー・deBryユタバレー州立大学オレーム、ユタ 84058
Phone: (801) 222-8000 EMail: debryro@uvsc.edu
以下に電話をしてください。 (801) 222-8000 メールしてください: debryro@uvsc.edu
Hastings, et al. Standards Track [Page 166] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[166ページ]: モデルと意味論2000年9月
Patrick Powell Astart Technologies 9475 Chesapeake Dr., Suite D San Diego, CA 95123
パトリックパウエルAstart Technologies9475チェサピーク博士、スイートDサンディエゴ、カリフォルニア 95123
Phone: (619) 874-6543 Fax: (619) 279-8424 EMail: papowell@astart.com
以下に電話をしてください。 (619) 874-6543 Fax: (619) 279-8424 メールしてください: papowell@astart.com
IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: ipp@pwg.org
IPPウェブページ: http://www.pwg.org/ipp/ IPPメーリングリスト: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
end
To subscribe to the ipp mailing list, send the following email: 1) send it to majordomo@pwg.org 2) leave the subject line blank 3) put the following two lines in the message body: subscribe ipp end
Implementers of this specification document are encouraged to join IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values.
Implementers of this specification document are encouraged to join IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values.
Other Participants:
Other Participants:
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Chuck Adams - Tektronix Shivaun Albright - HP Stefan Andersson - Axis Jeff Barnett - IBM Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM Systems Keith Carter - IBM Angelo Caruso - Xerox Rajesh Chawla - TR Computing Nancy Chen - Okidata Solutions Josh Cohen - Microsoft Jeff Copeland - QMS Andy Davidson - Tektronix Roger deBry - IBM Maulik Desai - Auco Mabry Dozier - QMS Lee Farrell - Canon Information Satoshi Fujitami - Ricoh Systems Steve Gebert - IBM Sue Gleeson - Digital Charles Gordon - Osicom Brian Grimshaw - Apple Jerry Hadsell - IBM Richard Hart - Digital Tom Hastings - Xerox Henrik Holst - I-data Stephen Holmstead Zhi-Hong Huang - Zenographics Scott Isaacson - Novell Babek Jahromi - Microsoft Swen Johnson - Xerox David Kellerman - Northlake Software Robert Kline - TrueSpectra Charles Kong - Panasonic Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Hastings, et al. Standards Track [Page 167] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 167] RFC 2911 IPP/1.1: Model and Semantics September 2000
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Devon Taylor - Novell
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Toshiba Lloyd Young - Lexmark
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang- Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems
Takami Kurono - Brother Rick Landau - Digital Scott Lawrence - Agranot Systems Greg LeClair - Epson Dwight Lewis - Lexmark Harry Lewis - IBM Tony Liao - Vivid Image Roy Lomicka - Digital Pete Loya - HP Ray Lutz - Cognisys Mike MacKay - Novell, Inc. David Manchala - Xerox Carl-Uno Manros - Xerox Jay Martin - Underscore Stan McConnell - Xerox Larry Masinter - Xerox Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft Ira McDonald - High North Inc. Mike Moldovan - G3 Nova Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh Pat Nogay - IBM Ron Norton - Printronics Hugo Parra, Novell Bob Pentecost - Hewlett-Packard Patrick Powell - Astart Jeff Rackowitz - Intermec Technologies Eric Random - Peerless Rob Rhoads - Intel Xavier Riley - Xerox Gary Roberts - Ricoh David Roach - Unisys Stuart Rowley - Kyocera Yuji Sasaki - Japan Computer Richard Schneider - Epson Industry Kris Schoff - HP Katsuaki Sekiguchi - Canon Bob Setterbo - Adobe Gail Songer - Peerless Hideki Tanaka - Cannon Devon Taylor - Novell Mike Timperman - Lexmark Atsushi Uchino - Epson Shigeru Ueda - Canon Bob Von Andel - Allegro Software William Wagner - NetSilicon/DPI Jim Walker - DAZEL Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc. Jasper Wong - Xionics Don Wright - Lexmark Michael Wu - Heidelberg Digital Rick Yardumian - Xerox Michael Yeung - Toshiba Lloyd Young - Lexmark Atsushi Yuki - Kyocera Peter Zehler - Xerox William Zhang- Canon Information Frank Zhao - Panasonic Systems Steve Zilles - Adobe Rob Zirnstein - Canon Information Systems
11. Formats for IPP Registration Proposals
11. Formats for IPP Registration Proposals
In order to propose an IPP extension for registration, the proposer must submit an application to IANA by email to "iana@iana.org" or by filling out the appropriate form on the IANA web pages (http://www.iana.org). This section specifies the required information and the formats for proposing registrations of extensions to IPP as provided in Section 6 for:
In order to propose an IPP extension for registration, the proposer must submit an application to IANA by email to "iana@iana.org" or by filling out the appropriate form on the IANA web pages (http://www.iana.org). This section specifies the required information and the formats for proposing registrations of extensions to IPP as provided in Section 6 for:
Hastings, et al. Standards Track [Page 168] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 168] RFC 2911 IPP/1.1: Model and Semantics September 2000
1. type2 'keyword' attribute values
2. type3 'keyword' attribute values
3. type2 'enum' attribute values
4. type3 'enum' attribute values
5. attributes
6. attribute syntaxes
7. operations
8. status codes
9. out-of-band attribute values
1. type2 'keyword' attribute values 2. type3 'keyword' attribute values 3. type2 'enum' attribute values 4. type3 'enum' attribute values 5. attributes 6. attribute syntaxes 7. operations 8. status codes 9. out-of-band attribute values
11.1 Type2 keyword attribute values registration,
11.1 Type2 keyword attribute values registration,
Type of registration: type2 keyword attribute value Name of attribute to which this keyword specification is to be added: Proposed keyword name of this keyword value: Specification of this keyword value (follow the style of IPP Model Section 4.1.2.3): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: type2 keyword attribute value Name of attribute to which this keyword specification is to be added: Proposed keyword name of this keyword value: Specification of this keyword value (follow the style of IPP Model Section 4.1.2.3): Name of proposer: Address of proposer: Email address of proposer:
Note: For type2 keywords, the Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For type2 keywords, the Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.2 Type3 keyword attribute values registration
11.2 Type3 keyword attribute values registration
Type of registration: type3 keyword attribute value Name of attribute to which this keyword specification is to be added: Proposed keyword name of this keyword value: Specification of this keyword value (follow the style of IPP Model Section 4.1.2.3): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: type3 keyword attribute value Name of attribute to which this keyword specification is to be added: Proposed keyword name of this keyword value: Specification of this keyword value (follow the style of IPP Model Section 4.1.2.3): Name of proposer: Address of proposer: Email address of proposer:
Note: For type3 keywords, the proposer will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For type3 keywords, the proposer will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.3 Type2 enum attribute values registration
11.3 Type2 enum attribute values registration
Type of registration: type2 enum attribute value Name of attribute to which this enum specification is to be added: Keyword symbolic name of this enum value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA):
Type of registration: type2 enum attribute value Name of attribute to which this enum specification is to be added: Keyword symbolic name of this enum value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA):
Hastings, et al. Standards Track [Page 169] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 169] RFC 2911 IPP/1.1: Model and Semantics September 2000
Specification of this enum value (follow the style of IPP Model Section 4.1.4): Name of proposer: Address of proposer: Email address of proposer:
Specification of this enum value (follow the style of IPP Model Section 4.1.4): Name of proposer: Address of proposer: Email address of proposer:
Note: For type2 enums, the Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For type2 enums, the Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.4 Type3 enum attribute values registration
11.4 Type3 enum attribute values registration
Type of registration: type3 enum attribute value Name of attribute to which this enum specification is to be added: Keyword symbolic name of this enum value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA): Specification of this enum value (follow the style of IPP Model Section 4.1.4): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: type3 enum attribute value Name of attribute to which this enum specification is to be added: Keyword symbolic name of this enum value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA): Specification of this enum value (follow the style of IPP Model Section 4.1.4): Name of proposer: Address of proposer: Email address of proposer:
Note: For type3 enums, the proposer will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For type3 enums, the proposer will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.5 Attribute registration
11.5 Attribute registration
Type of registration: attribute Proposed keyword name of this attribute: Types of attribute (Operation, Job Template, Job Description, Printer Description): Operations to be used with if the attribute is an operation attribute: Object (Job, Printer, etc. if bound to an object): Attribute syntax(es) (include 1setOf and range as in Section 4.2): If attribute syntax is 'keyword' or 'enum', is it type2 or type3: If this is a Printer attribute, MAY the value returned depend on "document-format" (See Section 6.2): If this is a Job Template attribute, how does its specification depend on the value of the "multiple-document-handling" attribute: Specification of this attribute (follow the style of IPP Model Section 4.2): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: attribute Proposed keyword name of this attribute: Types of attribute (Operation, Job Template, Job Description, Printer Description): Operations to be used with if the attribute is an operation attribute: Object (Job, Printer, etc. if bound to an object): Attribute syntax(es) (include 1setOf and range as in Section 4.2): If attribute syntax is 'keyword' or 'enum', is it type2 or type3: If this is a Printer attribute, MAY the value returned depend on "document-format" (See Section 6.2): If this is a Job Template attribute, how does its specification depend on the value of the "multiple-document-handling" attribute: Specification of this attribute (follow the style of IPP Model Section 4.2): Name of proposer: Address of proposer: Email address of proposer:
Hastings, et al. Standards Track [Page 170] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 170] RFC 2911 IPP/1.1: Model and Semantics September 2000
Note: For attributes, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For attributes, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.6 Attribute Syntax registration
11.6 Attribute Syntax registration
Type of registration: attribute syntax Proposed name of this attribute syntax: Type of attribute syntax (integer, octetString, character-string, see [RFC2910]): Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA): Specification of this attribute (follow the style of IPP Model Section 4.1): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: attribute syntax Proposed name of this attribute syntax: Type of attribute syntax (integer, octetString, character-string, see [RFC2910]): Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA): Specification of this attribute (follow the style of IPP Model Section 4.1): Name of proposer: Address of proposer: Email address of proposer:
Note: For attribute syntaxes, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For attribute syntaxes, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.7 Operation registration
11.7 Operation registration
Type of registration: operation Proposed name of this operation: Numeric operation-id value according to section 4.4.15 (to be assigned by the IPP Designated Expert in consultation with IANA): Object Target (Job, Printer, etc. that operation is upon): Specification of this operation (follow the style of IPP Model Section 3): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: operation Proposed name of this operation: Numeric operation-id value according to section 4.4.15 (to be assigned by the IPP Designated Expert in consultation with IANA): Object Target (Job, Printer, etc. that operation is upon): Specification of this operation (follow the style of IPP Model Section 3): Name of proposer: Address of proposer: Email address of proposer:
Note: For operations, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For operations, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.8 Attribute Group registration
11.8 Attribute Group registration
Type of registration: attribute group Proposed name of this attribute group: Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA): Operation requests and group number for each operation in which the attribute group occurs:
Type of registration: attribute group Proposed name of this attribute group: Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA): Operation requests and group number for each operation in which the attribute group occurs:
Hastings, et al. Standards Track [Page 171] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 171] RFC 2911 IPP/1.1: Model and Semantics September 2000
Operation responses and group number for each operation in which the attribute group occurs: Specification of this attribute group (follow the style of IPP Model Section 3): Name of proposer: Address of proposer: Email address of proposer:
Operation responses and group number for each operation in which the attribute group occurs: Specification of this attribute group (follow the style of IPP Model Section 3): Name of proposer: Address of proposer: Email address of proposer:
Note: For attribute groups, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For attribute groups, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.9 Status code registration
11.9 Status code registration
Type of registration: status code Keyword symbolic name of this status code value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA): Operations that this status code may be used with: Specification of this status code (follow the style of IPP Model Section 13 APPENDIX B: Status Codes and Suggested Status Code Messages): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: status code Keyword symbolic name of this status code value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA): Operations that this status code may be used with: Specification of this status code (follow the style of IPP Model Section 13 APPENDIX B: Status Codes and Suggested Status Code Messages): Name of proposer: Address of proposer: Email address of proposer:
Note: For status codes, the Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For status codes, the Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
11.10 Out-of-band Attribute Value registration
11.10 Out-of-band Attribute Value registration
Type of registration: out-of-band attribute value Proposed name of this out-of-band attribute value: Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA): Operations that this out-of-band attribute value may be used with: Attributes that this out-of-band attribute value may be used with: Specification of this out-of-band attribute value (follow the style of the beginning of IPP Model Section 4.1): Name of proposer: Address of proposer: Email address of proposer:
Type of registration: out-of-band attribute value Proposed name of this out-of-band attribute value: Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA): Operations that this out-of-band attribute value may be used with: Attributes that this out-of-band attribute value may be used with: Specification of this out-of-band attribute value (follow the style of the beginning of IPP Model Section 4.1): Name of proposer: Address of proposer: Email address of proposer:
Note: For out-of-band attribute values, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Note: For out-of-band attribute values, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed.
Hastings, et al. Standards Track [Page 172] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 172] RFC 2911 IPP/1.1: Model and Semantics September 2000
12. APPENDIX A: Terminology
12. APPENDIX A: Terminology
This specification document uses the terminology defined in this section.
This specification document uses the terminology defined in this section.
12.1 Conformance Terminology
12.1 Conformance Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
12.1.1 NEED NOT
12.1.1 NEED NOT
This term is not included in RFC 2119. The verb "NEED NOT" indicates an action that the subject of the sentence does not have to implement in order to claim conformance to the standard. The verb "NEED NOT" is used instead of "MAY NOT" since "MAY NOT" sounds like a prohibition.
This term is not included in RFC 2119. The verb "NEED NOT" indicates an action that the subject of the sentence does not have to implement in order to claim conformance to the standard. The verb "NEED NOT" is used instead of "MAY NOT" since "MAY NOT" sounds like a prohibition.
12.2 Model Terminology
12.2 Model Terminology
12.2.1 Keyword
12.2.1 Keyword
Keywords are used within this document as identifiers of semantic entities within the abstract model (see section 4.1.2.3). Attribute names, some attribute values, attribute syntaxes, and attribute group names are represented as keywords.
Keywords are used within this document as identifiers of semantic entities within the abstract model (see section 4.1.2.3). Attribute names, some attribute values, attribute syntaxes, and attribute group names are represented as keywords.
12.2.2 Attributes
12.2.2 Attributes
An attribute is an item of information that is associated with an instance of an IPP object. An attribute consists of an attribute name and one or more attribute values. Each attribute has a specific attribute syntax. All object attributes are defined in section 4 and all operation attributes are defined in section 3.
An attribute is an item of information that is associated with an instance of an IPP object. An attribute consists of an attribute name and one or more attribute values. Each attribute has a specific attribute syntax. All object attributes are defined in section 4 and all operation attributes are defined in section 3.
Job Template Attributes are described in section 4.2. The client optionally supplies Job Template attributes in a create request (operation requests that create Job objects). The Printer object has associated attributes which define supported and default values for the Printer.
Job Template Attributes are described in section 4.2. The client optionally supplies Job Template attributes in a create request (operation requests that create Job objects). The Printer object has associated attributes which define supported and default values for the Printer.
12.2.2.1 Attribute Name
12.2.2.1 Attribute Name
Each attribute is uniquely identified in this document by its attribute name. An attribute name is a keyword. The keyword attribute name is given in the section header describing that
Each attribute is uniquely identified in this document by its attribute name. An attribute name is a keyword. The keyword attribute name is given in the section header describing that
Hastings, et al. Standards Track [Page 173] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 173] RFC 2911 IPP/1.1: Model and Semantics September 2000
attribute. In running text in this document, attribute names are
indicated inside double quotation marks (") where the quotation marks
are not part of the keyword itself.
attribute. In running text in this document, attribute names are indicated inside double quotation marks (") where the quotation marks are not part of the keyword itself.
12.2.2.2 Attribute Group Name
12.2.2.2 Attribute Group Name
Related attributes are grouped into named groups. The name of the group is a keyword. The group name may be used in place of naming all the attributes in the group explicitly. Attribute groups are defined in section 3.
Related attributes are grouped into named groups. The name of the group is a keyword. The group name may be used in place of naming all the attributes in the group explicitly. Attribute groups are defined in section 3.
12.2.2.3 Attribute Value
12.2.2.3 Attribute Value
Each attribute has one or more values. Attribute values are
represented in the syntax type specified for that attribute. In
running text in this document, attribute values are indicated inside
single quotation marks ('), whether their attribute syntax is
keyword, integer, text, etc. where the quotation marks are not part
of the value itself.
Each attribute has one or more values. Attribute values are represented in the syntax type specified for that attribute. In running text in this document, attribute values are indicated inside single quotation marks ('), whether their attribute syntax is keyword, integer, text, etc. where the quotation marks are not part of the value itself.
12.2.2.4 Attribute Syntax
12.2.2.4 Attribute Syntax
Each attribute is defined using an explicit syntax type. In this document, each syntax type is defined as a keyword with specific meaning. The "Encoding and Transport" document [RFC2910] indicates the actual "on-the-wire" encoding rules for each syntax type. Attribute syntax types are defined in section 4.1.
Each attribute is defined using an explicit syntax type. In this document, each syntax type is defined as a keyword with specific meaning. The "Encoding and Transport" document [RFC2910] indicates the actual "on-the-wire" encoding rules for each syntax type. Attribute syntax types are defined in section 4.1.
12.2.3 Supports
12.2.3 Supports
By definition, a Printer object supports an attribute only if that Printer object responds with the corresponding attribute populated with some value(s) in a response to a query for that attribute. A Printer object supports an attribute value if the value is one of the Printer object's "supported values" attributes. The device behind a Printer object may exhibit a behavior that corresponds to some IPP attribute, but if the Printer object, when queried for that attribute, doesn't respond with the attribute, then as far as IPP is concerned, that implementation does not support that feature. If the Printer object's "xxx-supported" attribute is not populated with a particular value (even if that value is a legal value for that attribute), then that Printer object does not support that particular value.
By definition, a Printer object supports an attribute only if that Printer object responds with the corresponding attribute populated with some value(s) in a response to a query for that attribute. A Printer object supports an attribute value if the value is one of the Printer object's "supported values" attributes. The device behind a Printer object may exhibit a behavior that corresponds to some IPP attribute, but if the Printer object, when queried for that attribute, doesn't respond with the attribute, then as far as IPP is concerned, that implementation does not support that feature. If the Printer object's "xxx-supported" attribute is not populated with a particular value (even if that value is a legal value for that attribute), then that Printer object does not support that particular value.
Hastings, et al. Standards Track [Page 174] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 174] RFC 2911 IPP/1.1: Model and Semantics September 2000
A conforming implementation MUST support all REQUIRED attributes. However, even for REQUIRED attributes, conformance to IPP does not mandate that all implementations support all possible values representing all possible job processing behaviors and features. For example, if a given instance of a Printer supports only certain document formats, then that Printer responds with the "document- format-supported" attribute populated with a set of values, possibly only one, taken from the entire set of possible values defined for that attribute. This limited set of values represents the Printer's set of supported document formats. Supporting an attribute and some set of values for that attribute enables IPP end users to be aware of and make use of those features associated with that attribute and those values. If an implementation chooses to not support an attribute or some specific value, then IPP end users would have no ability to make use of that feature within the context of IPP itself. However, due to existing practice and legacy systems which are not IPP aware, there might be some other mechanism outside the scope of IPP to control or request the "unsupported" feature (such as embedded instructions within the document data itself).
A conforming implementation MUST support all REQUIRED attributes. However, even for REQUIRED attributes, conformance to IPP does not mandate that all implementations support all possible values representing all possible job processing behaviors and features. For example, if a given instance of a Printer supports only certain document formats, then that Printer responds with the "document- format-supported" attribute populated with a set of values, possibly only one, taken from the entire set of possible values defined for that attribute. This limited set of values represents the Printer's set of supported document formats. Supporting an attribute and some set of values for that attribute enables IPP end users to be aware of and make use of those features associated with that attribute and those values. If an implementation chooses to not support an attribute or some specific value, then IPP end users would have no ability to make use of that feature within the context of IPP itself. However, due to existing practice and legacy systems which are not IPP aware, there might be some other mechanism outside the scope of IPP to control or request the "unsupported" feature (such as embedded instructions within the document data itself).
For example, consider the "finishings-supported" attribute.
For example, consider the "finishings-supported" attribute.
1) If a Printer object is not physically capable of stapling, the
"finishings-supported" attribute MUST NOT be populated with the
value of 'staple'.
2) A Printer object is physically capable of stapling, however an
implementation chooses not to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST NOT be a
value in the "finishings-supported" Printer object attribute.
Without support for the value 'staple', an IPP end user would
have no means within the protocol itself to request that a Job
be stapled. However, an existing document data formatter might
be able to request that the document be stapled directly with
an embedded instruction within the document data. In this
case, the IPP implementation does not "support" stapling,
however the end user is still able to have some control over
the stapling of the completed job.
3) A Printer object is physically capable of stapling, and an
implementation chooses to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST be a value
in the "finishings-supported" Printer object attribute. Doing
so, would enable end users to be aware of and make use of the
stapling feature using IPP attributes.
1) If a Printer object is not physically capable of stapling, the "finishings-supported" attribute MUST NOT be populated with the value of 'staple'. 2) A Printer object is physically capable of stapling, however an implementation chooses not to support stapling in the IPP "finishings" attribute. In this case, 'staple' MUST NOT be a value in the "finishings-supported" Printer object attribute. Without support for the value 'staple', an IPP end user would have no means within the protocol itself to request that a Job be stapled. However, an existing document data formatter might be able to request that the document be stapled directly with an embedded instruction within the document data. In this case, the IPP implementation does not "support" stapling, however the end user is still able to have some control over the stapling of the completed job. 3) A Printer object is physically capable of stapling, and an implementation chooses to support stapling in the IPP "finishings" attribute. In this case, 'staple' MUST be a value in the "finishings-supported" Printer object attribute. Doing so, would enable end users to be aware of and make use of the stapling feature using IPP attributes.
Hastings, et al. Standards Track [Page 175] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 175] RFC 2911 IPP/1.1: Model and Semantics September 2000
Even though support for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED that if the device behind a Printer object is capable of realizing any feature or function that corresponds to an IPP attribute and some associated value, then that implementation SHOULD support that IPP attribute and value.
Even though support for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED that if the device behind a Printer object is capable of realizing any feature or function that corresponds to an IPP attribute and some associated value, then that implementation SHOULD support that IPP attribute and value.
The set of values in any of the supported value attributes is set (populated) by some administrative process or automatic sensing mechanism that is outside the scope of this IPP/1.1 document. For administrative policy and control reasons, an administrator may choose to make only a subset of possible values visible to the end user. In this case, the real output device behind the IPP Printer abstraction may be capable of a certain feature, however an administrator is specifying that access to that feature not be exposed to the end user through the IPP protocol. Also, since a Printer object may represent a logical print device (not just a physical device) the actual process for supporting a value is undefined and left up to the implementation. However, if a Printer object supports a value, some manual human action may be needed to realize the semantic action associated with the value, but no end user action is required.
The set of values in any of the supported value attributes is set (populated) by some administrative process or automatic sensing mechanism that is outside the scope of this IPP/1.1 document. For administrative policy and control reasons, an administrator may choose to make only a subset of possible values visible to the end user. In this case, the real output device behind the IPP Printer abstraction may be capable of a certain feature, however an administrator is specifying that access to that feature not be exposed to the end user through the IPP protocol. Also, since a Printer object may represent a logical print device (not just a physical device) the actual process for supporting a value is undefined and left up to the implementation. However, if a Printer object supports a value, some manual human action may be needed to realize the semantic action associated with the value, but no end user action is required.
For example, if one of the values in the "finishings-supported" attribute is 'staple', the actual process might be an automatic staple action by a physical device controlled by some command sent to the device. Or, the actual process of stapling might be a manual action by an operator at an operator attended Printer object.
For example, if one of the values in the "finishings-supported" attribute is 'staple', the actual process might be an automatic staple action by a physical device controlled by some command sent to the device. Or, the actual process of stapling might be a manual action by an operator at an operator attended Printer object.
For another example of how supported attributes function, consider a system administrator who desires to control all print jobs so that no job sheets are printed in order to conserve paper. To force no job sheets, the system administrator sets the only supported value for the "job-sheets-supported" attribute to 'none'. In this case, if a client requests anything except 'none', the create request is rejected or the "job-sheets" value is ignored (depending on the value of "ipp-attribute-fidelity"). To force the use of job start/end sheets on all jobs, the administrator does not include the value 'none' in the "job-sheets- supported" attribute. In this case, if a client requests 'none', the create request is rejected or the "job- sheets" value is ignored (again depending on the value of "ipp- attribute-fidelity").
For another example of how supported attributes function, consider a system administrator who desires to control all print jobs so that no job sheets are printed in order to conserve paper. To force no job sheets, the system administrator sets the only supported value for the "job-sheets-supported" attribute to 'none'. In this case, if a client requests anything except 'none', the create request is rejected or the "job-sheets" value is ignored (depending on the value of "ipp-attribute-fidelity"). To force the use of job start/end sheets on all jobs, the administrator does not include the value 'none' in the "job-sheets- supported" attribute. In this case, if a client requests 'none', the create request is rejected or the "job- sheets" value is ignored (again depending on the value of "ipp- attribute-fidelity").
12.2.4 print-stream page
12.2.4 print-stream page
A "print-stream page" is a page according to the definition of pages in the language used to express the document data.
A "print-stream page" is a page according to the definition of pages in the language used to express the document data.
Hastings, et al. Standards Track [Page 176] RFC 2911 IPP/1.1: Model and Semantics September 2000
Hastings, et al. Standards Track [Page 176] RFC 2911 IPP/1.1: Model and Semantics September 2000
12.2.5 impression
12.2.5 impression
An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page.
An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page.
13. APPENDIX B: Status Codes and Suggested Status Code Messages
13. APPENDIX B: Status Codes and Suggested Status Code Messages
This section defines status code enum keywords and values that are used to provide semantic information on the results of an operation request. Each operation response MUST include a status code. The response MAY also contain a status message that provides a short textual description of the status. The status code is intended for use by automata, and the status message is intended for the human end user. Since the status message is an OPTIONAL component of the operation response, an IPP application (i.e., a browser, GUI, print driver or gateway) is NOT REQUIRED to examine or display the status message, since it MAY not be returned to the application.
This section defines status code enum keywords and values that are used to provide semantic information on the results of an operation request. Each operation response MUST include a status code. The response MAY also contain a status message that provides a short textual description of the status. The status code is intended for use by automata, and the status message is intended for the human end user. Since the status message is an OPTIONAL component of the operation response, an IPP application (i.e., a browser, GUI, print driver or gateway) is NOT REQUIRED to examine or display the status message, since it MAY not be returned to the application.
The prefix of the status keyword defines the class of response as follows:
The prefix of the status keyword defines the class of response as follows:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood,
and accepted
"redirection" - Further action must be taken in order to complete
the request
"client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid request
"informational" - Request received, continuing process "successful" - The action was successfully received, understood, and accepted "redirection" - Further action must be taken in order to complete the request "client-error" - The request contains bad syntax or cannot be fulfilled "server-error" - The IPP object failed to fulfill an apparently valid request
As with type2 enums, IPP status codes are extensible. IPP clients are NOT REQUIRED to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, IPP clients MUST understand the class of any status code, as indicated by the prefix, and treat any unrecognized response as being equivalent to the first status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of "client-error-xxx-yyy" is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a "client- error-bad-request" status code. In such cases, IPP applications SHOULD present the OPTIONAL message (if present) to the end user since the message is likely to contain human readable information which will help to explain the unusual status. The name of the enum is the suggested status message for US English.
type2 enumsのように、IPPステータスコードは広げることができます。 そのような理解は明らかに望ましいのですが、IPPクライアントはすべての登録されたステータスコードの意味を理解するNOT REQUIREDです。 しかしながら、IPPクライアントは、キャッシュされていた状態で接頭語によって示されるようにどんなステータスコードのクラスも理解して、認識されていない応答が例外があるそのクラスのステータスコードであるに違いありませんが、1日に同等であるとしてどんな認識されていない応答も扱わなければなりません。 例えば、「クライアント誤りxxx-yyy」の認識されていないステータスコードがクライアントによって受け取られるなら、それは、まるで「クライアントの誤りの悪い要求」ステータスコードを受け取ったかのように要求には不具合があったと安全に仮定して、応答を扱うことができます。 そのような場合、メッセージが珍しい状態について説明するのを助ける人間の読み込み可能な情報を含みそうであるので、IPPアプリケーションSHOULDはOPTIONALメッセージ(存在しているなら)をエンドユーザに提示します。 enumの名前は米国の英語のための提案されたステータスメッセージです。
Hastings, et al. Standards Track [Page 177] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[177ページ]: モデルと意味論2000年9月
The status code values range from 0x0000 to 0x7FFF. The value ranges for each status code class are as follows:
状態コード値は0×0000から0x7FFFまで及びます。 それぞれのステータスコードのクラスのための値の範囲は以下の通りです:
"successful" - 0x0000 to 0x00FF
"informational" - 0x0100 to 0x01FF
"redirection" - 0x0200 to 0x02FF
"client-error" - 0x0400 to 0x04FF
"server-error" - 0x0500 to 0x05FF
0x04FF「サーバ誤り」への「うまくいっている」(0x02FF「クライアント誤り」への「情報(0x01FF「リダイレクション」への0×0100)」の0x00FF0×0000対0×0200)0×0400--0x05FFへの0×0500
The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0 to 5) is reserved for vendor use within each status code class. Values 0x0600 to 0x7FFF are reserved for future assignment by IETF standards track documents and MUST NOT be used.
それぞれの範囲(0〜n=5のための0x0nFFへの0x0n40)の上半分(128の値)はベンダー使用のためにそれぞれのステータスコードのクラスの中で予約されます。 0x7FFFへの値0x0600を、将来の課題のためにIETF標準化過程ドキュメントで予約して、使用してはいけません。
13.1 Status Codes
13.1 状態コード
Each status code is described below. Section 13.1.5.9 contains a table that indicates which status codes apply to which operations. The Implementer's Guide [IPP-IIG] describe the suggested steps for processing IPP attributes for all operations, including returning status codes.
各ステータスコードは以下で説明されます。 セクション13.1 .5 .9 どのステータスコードがどの操作に適用されるかを示すテーブルを含んでいます。 Implementerのガイド[IPP-IIG]はステータスコードを返すのを含むすべての操作のために処理IPP属性のための提案されたステップについて説明します。
13.1.1 Informational
13.1.1 情報です。
This class of status code indicates a provisional response and is to be used for informational purposes only.
このクラスのステータスコードは、暫定的な応答を示して、情報の目的だけに使用されることです。
There are no status codes defined in IPP/1.1 for this class of status code.
このクラスのステータスコードのためにIPP/1.1で定義されたステータスコードが全くありません。
13.1.2 Successful Status Codes
13.1.2 うまくいっているステータスコード
This class of status code indicates that the client's request was successfully received, understood, and accepted.
このクラスのステータスコードは、クライアントの要求が首尾よく受け取られて、理解されて、受け入れられたのを示します。
13.1.2.1 successful-ok (0x0000)
13.1.2.1 うまくいって間違いありません。(0×0000)
The request has succeeded and no request attributes were substituted or ignored. In the case of a response to a create request, the 'successful-ok' status code indicates that the request was successfully received and validated, and that the Job object has been created; it does not indicate that the job has been processed. The transition of the Job object into the 'completed' state is the only indicator that the job has been printed.
要求が成功して、要求属性を全く代入もしませんでしたし、無視もしませんでした。 aへの応答の場合では、'うまくいっているOK'ステータスコードが、要求が首尾よく受け取られて、有効にされたのを示して、Jobオブジェクトが作成されたという要求を作成してください。 それは、仕事を処理してあるのを示しません。 '完成した'状態へのJobオブジェクトの変遷は仕事が印刷されたという唯一のインディケータです。
Hastings, et al. Standards Track [Page 178] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[178ページ]: モデルと意味論2000年9月
13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)
13.1.2.2 うまくいっているOKは、属性を無視したか、または代入しました。(0×0001)
The request has succeeded, but some supplied (1) attributes were ignored or (2) unsupported values were substituted with supported values or were ignored in order to perform the operation without rejecting it. Unsupported attributes, attribute syntaxes, or values MUST be returned in the Unsupported Attributes group of the response for all operations. There is an exception to this rule for the query operations: Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes for the "requested-attributes" operation attribute only. When the supplied values of the "requested-attributes" operation attribute are requesting attributes that are not supported, the IPP object MAY, but is NOT REQUIRED to, return the "requested-attributes" attribute in the Unsupported Attribute response group (with the unsupported values only). See sections 3.1.7 and 3.2.1.2.
(2) 要求が成功しましたが、いくつかの供給された(1)属性が無視されたか、またはサポートされない値をサポートしている値で代入したか、それを拒絶しないで操作を実行するために無視しました。 すべての操作のための応答のUnsupported Attributesグループでサポートされない属性、属性構文、または値を返さなければなりません。 質問操作のためのこの規則への例外があります: プリンタ属性を得ているGet-仕事、および「要求された属性」のためのGet仕事の属性の操作属性専用。 いつまで、「要求された属性」操作属性の供給値がサポートされない属性、IPPオブジェクトがそうするかもしれないよう要求しますが、NOT REQUIREDであるか、Unsupported Attribute応答グループ(サポートされない値だけがある)で「要求された属性」属性を返してください。 セクション3.1.7と3.2を見てください。.1 .2。
13.1.2.3 successful-ok-conflicting-attributes (0x0002)
13.1.2.3 うまくいっている間違いない闘争属性(0×0002)
The request has succeeded, but some supplied attribute values conflicted with the values of other supplied attributes. These conflicting values were either (1) substituted with (supported) values or (2) the attributes were removed in order to process the job without rejecting it. Attributes or values which conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response for all operations as supplied by the client. See sections 3.1.7 and 3.2.1.2.
要求は成功しましたが、いくつかの供給された属性値が他の供給された属性の値と衝突しました。 (2) これらの闘争値は(サポートされます)値で代入された(1)であったかそれを拒絶しないで仕事を処理するために属性を取り除きました。 クライアントによって供給されるようにすべての操作のために、応答のUnsupported Attributesグループで他の属性と衝突して、代入するか、または無視した属性か値を返さなければなりません。 セクション3.1.7と3.2を見てください。.1 .2。
13.1.3 Redirection Status Codes
13.1.3 リダイレクションステータスコード
This class of status code indicates that further action needs to be taken to fulfill the request.
このクラスのステータスコードは、さらなる動作が、要求を実現させるために取られる必要であるのを示します。
There are no status codes defined in IPP/1.1 for this class of status code.
このクラスのステータスコードのためにIPP/1.1で定義されたステータスコードが全くありません。
13.1.4 Client Error Status Codes
13.1.4 クライアント誤りステータスコード
This class of status code is intended for cases in which the client seems to have erred. The IPP object SHOULD return a message containing an explanation of the error situation and whether it is a temporary or permanent condition.
このクラスのステータスコードはクライアントが間違えたように思える場合のために意図します。 IPPオブジェクトSHOULDはエラー状態とそれが一時的であるか永久的な状態であるかどうかに関する説明を含むメッセージを返します。
Hastings, et al. Standards Track [Page 179] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[179ページ]: モデルと意味論2000年9月
13.1.4.1 client-error-bad-request (0x0400)
13.1.4.1 クライアントの誤りの悪い要求(0×0400)
The request could not be understood by the IPP object due to malformed syntax (such as the value of a fixed length attribute whose length does not match the prescribed length for that attribute - see the Implementer's Guide [IPP-IIG] ). The IPP application SHOULD NOT repeat the request without modifications.
奇形の構文のためIPPオブジェクトに要求を解釈できませんでした(長さがその属性のための処方された長さに合っていない固定長属性の値などのように--Implementerのガイド[IPP-IIG]を見てください)。 IPPアプリケーションSHOULD NOTは変更なしで要求を繰り返します。
13.1.4.2 client-error-forbidden (0x0401)
13.1.4.2 禁じられたクライアント誤り(0×0401)
The IPP object understood the request, but is refusing to fulfill it. Additional authentication information or authorization credentials will not help and the request SHOULD NOT be repeated. This status code is commonly used when the IPP object does not wish to reveal exactly why the request has been refused or when no other response is applicable.
IPPオブジェクトは、要求を理解していますが、それを実現させるのを拒否しています。 繰り返されて、追加認証情報か承認資格証明書が助けでなくて要求SHOULD NOTを望んでいます。 IPPオブジェクトが、要求がちょうどなぜ拒否されたか、そして、または他のどんな応答もいつ適切でないかを明らかにしたがっていないとき、このステータスコードは一般的に使用されます。
13.1.4.3 client-error-not-authenticated (0x0402)
13.1.4.3 誤りが認証しなかったクライアント(0×0402)
The request requires user authentication. The IPP client may repeat the request with suitable authentication information. If the request already included authentication information, then this status code indicates that authorization has been refused for those credentials. If this response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the response message may contain relevant diagnostic information. This status codes reveals more information than "client-error-forbidden".
要求はユーザー認証を必要とします。 IPPクライアントは適当な認証情報で要求を繰り返すかもしれません。 要求が既に認証情報を含んだなら、このステータスコードは、承認がそれらの資格証明書のために拒否されたのを示します。 この応答が先の応答と同じ挑戦を含んでいて、ユーザエージェントが少なくとも一度既に認証を試みたことがあるなら、応答メッセージは関連診断情報を含むかもしれません。 このステータスコードは「禁じられたクライアント誤り」より多くの情報を明らかにします。
13.1.4.4 client-error-not-authorized (0x0403)
13.1.4.4 誤りが権限を与えなかったクライアント(0×0403)
The requester is not authorized to perform the request. Additional authentication information or authorization credentials will not help and the request SHOULD NOT be repeated. This status code is used when the IPP object wishes to reveal that the authentication information is understandable, however, the requester is explicitly not authorized to perform the request. This status codes reveals more information than "client-error-forbidden" and "client-error- not-authenticated".
リクエスタが要求を実行するのが認可されません。 繰り返されて、追加認証情報か承認資格証明書が助けでなくて要求SHOULD NOTを望んでいます。 認証情報が理解できるのを明らかにするというIPPオブジェクト願望であるときに、このステータスコードが使用されている、しかしながら、リクエスタが要求を実行するのが明らかに認可されません。 このステータスコードは「禁じられたクライアント誤り」で「クライアント誤りで認証されていない」より多くの情報を明らかにします。
13.1.4.5 client-error-not-possible (0x0404)
13.1.4.5 可能でないクライアント誤り(0×0404)
This status code is used when the request is for something that can not happen. For example, there might be a request to cancel a job that has already been canceled or aborted by the system. The IPP client SHOULD NOT repeat the request.
要求が起こることができない何かのためのものであるときに、このステータスコードは使用されています。 例えば、システムによって既に中止されるか、または中止された仕事を中止するという要求があるかもしれません。 IPPクライアントSHOULD NOTは要求を繰り返します。
Hastings, et al. Standards Track [Page 180] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[180ページ]: モデルと意味論2000年9月
13.1.4.6 client-error-timeout (0x0405)
13.1.4.6 クライアント誤りタイムアウト(0×0405)
The client did not produce a request within the time that the IPP object was prepared to wait. For example, a client issued a Create- Job operation and then, after a long period of time, issued a Send- Document operation and this error status code was returned in response to the Send-Document request (see section 3.3.1). The IPP object might have been forced to clean up resources that had been held for the waiting additional Documents. The IPP object was forced to close the Job since the client took too long. The client SHOULD NOT repeat the request without modifications.
クライアントはIPPオブジェクトが待つように準備された時中に要求を作り出しませんでした。 例えば、クライアントは、仕事の操作をCreateに発行して、次に、長日月の後にドキュメント操作をSendに発行しました、そして、Send-資料請求に対応してこの誤りステータスコードを返しました(セクション3.3.1を見てください)。 IPPオブジェクトはやむを得ず待っている追加Documentsのために保持されたリソースをきれいにしたかもしれません。 クライアントがまた、時間がかかったので、IPPオブジェクトはやむを得ずJobを閉じました。 クライアントSHOULD NOTは変更なしで要求を繰り返します。
13.1.4.7 client-error-not-found (0x0406)
13.1.4.7 誤りが当たらなかったクライアント(0×0406)
The IPP object has not found anything matching the request URI. No indication is given of whether the condition is temporary or permanent. For example, a client with an old reference to a Job (a URI) tries to cancel the Job, however in the mean time the Job might have been completed and all record of it at the Printer has been deleted. This status code, 'client-error-not-found' is returned indicating that the referenced Job can not be found. This error status code is also used when a client supplies a URI as a reference to the document data in either a Print-URI or Send-URI operation, but the document can not be found.
IPPは、何も要求URIに合っているのがわかっていないのを反対します。 状態が一時的であるか、または永久的であるかを指示を全く与えません。 例えば、Job(URI)の古い参照のクライアントはJobを取り消そうとします、どんなにその間にJobが完成したかもしれなく、Printerでのそれに関するすべての記録が削除されていても。 参照をつけられたJobを見つけることができないのを示しながら、このステータスコード、'誤りが当たらなかったクライアント'を返します。 また、クライアントがPrint-URIかSend-URI操作のどちらかにおけるドキュメントデータの参照としてURIを供給するとき、この誤りステータスコードは使用されますが、ドキュメントを見つけることができません。
In practice, an IPP application should avoid a not found situation by first querying and presenting a list of valid Printer URIs and Job URIs to the end-user.
実際には、IPPアプリケーションは、有効なPrinter URIとJob URIのリストをエンドユーザに質問して、提示しながら、最初にで状況が見つけられなかったaを避けるべきです。
13.1.4.8 client-error-gone (0x0407)
13.1.4.8、クライアント誤り過ぎ去る。(0×0407)
The requested object is no longer available and no forwarding address is known. This condition should be considered permanent. Clients with link editing capabilities should delete references to the request URI after user approval. If the IPP object does not know or has no facility to determine, whether or not the condition is permanent, the status code "client-error-not-found" should be used instead.
要求されたオブジェクトはもう利用可能ではありません、そして、フォーワーディング・アドレスは全く知られていません。 この状態は永久的であると考えられるべきです。 連係編集能力があるクライアントはユーザ承認の後に要求URIの参照を削除するべきです。 IPP目的に、知らないか、または決定しない施設が全くあるなら、状態が永久的であるか否かに関係なく、ステータスコード「誤りが当たらなかったクライアント」は代わりに使用されるべきです。
This response is primarily intended to assist the task of maintenance by notifying the recipient that the resource is intentionally unavailable and that the IPP object administrator desires that remote links to that resource be removed. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the IPP object administrator and/or Printer implementation.
主として、リソースが故意に入手できなく、IPPオブジェクト管理者が、そのリソースへのリモートリンクが取り外されることを望んでいるように受取人に通知することによってこの応答がメインテナンスに関するタスクを補助することを意図します。 すべての永久に入手できないリソースが「過ぎ去る」とマークするか、またはどんな長さの時間にもマークを保つのは必要ではありません--すなわち、IPPオブジェクト管理者、そして/または、Printer実装の思慮深さにいなくなりました。
Hastings, et al. Standards Track [Page 181] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[181ページ]: モデルと意味論2000年9月
13.1.4.9 client-error-request-entity-too-large (0x0408)
13.1.4.9 クライアント誤りは大き過ぎる状態で実体を要求します。(0×0408)
The IPP object is refusing to process a request because the request entity is larger than the IPP object is willing or able to process. An IPP Printer returns this status code when it limits the size of print jobs and it receives a print job that exceeds that limit or when the attributes are so many that their encoding causes the request entity to exceed IPP object capacity.
IPPオブジェクトは、要求実体がIPPオブジェクトが望んでいるか、または処理できるより大きいので要求を処理するのを拒否しています。 印刷仕事のサイズを制限して、その限界を超えている印刷仕事を受けるか、または属性が非常に多いので要求実体がそれらのコード化でIPPオブジェクト容量を超えていると、IPP Printerはこのステータスコードを返します。
13.1.4.10 client-error-request-value-too-long (0x0409)
13.1.4.10 クライアント誤りはあまりに長い間、値を要求します。(0×0409)
The IPP object is refusing to service the request because one or more of the client-supplied attributes has a variable length value that is longer than the maximum length specified for that attribute. The IPP object might not have sufficient resources (memory, buffers, etc.) to process (even temporarily), interpret, and/or ignore a value larger than the maximum length. Another use of this error code is when the IPP object supports the processing of a large value that is less than the maximum length, but during the processing of the request as a whole, the object may pass the value onto some other system component which is not able to accept the large value. For more details, see the Implementer's Guide [IPP-IIG] .
IPPオブジェクトは、クライアントによって供給された属性の1つ以上には可変長値があるのでそれが最大の長さがその属性に指定したより長いという要求を修理するのを拒否しています。 IPPオブジェクトで、値を処理して(一時さえ)、解釈する、そして/または、無視できるくらいのリソース(メモリ、バッファなど)は最大の長さより大きくならないかもしれません。 このエラーコードの別の使用はIPPオブジェクトが最大の長さ以下である大きい価値の処理をサポートする時ですが、全体で要求の処理の間オブジェクトは大きい値を受け入れることができないある他のシステムの部品に値を通過するかもしれません。 その他の詳細に関しては、Implementerのガイド[IPP-IIG]を見てください。
Note: For attribute values that are URIs, this rare condition is only likely to occur when a client has improperly submitted a request with long query information (e.g. an IPP application allows an end- user to enter an invalid URI), when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the IPP object is under attack by a client attempting to exploit security holes present in some IPP objects using fixed-length buffers for reading or manipulating the Request-URI.
以下に注意してください。 クライアントが長い質問情報で不適切に要求を提出したときだけ(例えば、IPPアプリケーションで、終わりのユーザは無効のURIに入ることができます)、URIである属性値において、このまれな状態は起こりそうです; クライアントがいつ、リダイレクション(例えば、それ自体の接尾語を示す向け直されたURI接頭語)のURI「ブラックホール」の中に降りたか、そして、またはIPPがいつ反対するかはRequest-URIを読むか、または操るのに固定長バッファを使用することでいくつかのIPPオブジェクトの現在のセキュリティーホールを利用するのを試みるクライアントによって攻撃されています。
13.1.4.11 client-error-document-format-not-supported (0x040A)
13.1.4.11 形式が支えなかったクライアント誤りドキュメント(0x040A)
The IPP object is refusing to service the request because the document data is in a format, as specified in the "document-format" operation attribute, that is not supported by the Printer object. This error is returned independent of the client-supplied "ipp- attribute-fidelity". The Printer object MUST return this status code, even if there are other Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See sections 3.1.6.1, 3.1.7, and 3.2.1.1.
IPPオブジェクトは、「ドキュメント・フォーマット」操作属性で指定されるように形式にはドキュメントデータがあるので要求を修理するのを拒否していて、それはPrinterオブジェクトによってサポートされません。 この誤りはクライアントによって供給された「ipp属性信義」の如何にかかわらず返されます。 Printerオブジェクトはこのステータスコードを返さなければなりません、また、サポートされない他のJob Template属性があっても、この誤りがJob Template属性より大きい問題であるので。 そして、見る、セクション3.1 .6 .1 3.1 .7、3.2 .1 .1。
Hastings, et al. Standards Track [Page 182] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[182ページ]: モデルと意味論2000年9月
13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
13.1.4.12 属性か値がサポートしなかったクライアント誤り(0x040B)
In a create request, if the Printer object does not support one or more attributes, attribute syntaxes, or attribute values supplied in the request and the client supplied the "ipp-attribute-fidelity" operation attribute with the 'true' value, the Printer object MUST return this status code. The Printer object MUST also return in the Unsupported Attributes Group all the attributes and/or values supplied by the client that are not supported. See section 3.1.7. For example, if the request indicates 'iso-a4' media, but that media type is not supported by the Printer object. Or, if the client supplies a Job Template attribute and the attribute itself is not even supported by the Printer. If the "ipp-attribute-fidelity" attribute is 'false', the Printer MUST ignore or substitute values for unsupported Job Template attributes and values rather than reject the request and return this status code.
aでは、要求を作成してください、Printerオブジェクトが要求で供給された1つ以上の属性、属性構文、または属性値をサポートしないで、クライアントが'本当'の値と共に「ipp属性信義」操作属性を供給して、Printerオブジェクトがこのステータスコードを返さなければならないなら。 また、Printerオブジェクトはサポートされないで、すべての属性、そして/または、値がクライアントから供給したUnsupported Attributes Groupで戻らなければなりません。 セクション3.1.7を見てください。 例えば、要求が、'iso-a4'メディアと、メディアタイプがPrinterによってサポートされないのを示すなら、反対してください。 または、クライアントがJob Template属性を供給するか、そして、属性自体はPrinterによってサポートさえされません。 「ipp属性信義」属性が'誤っている'なら、Printerは要求を拒絶して、このステータスコードを返すよりむしろサポートされないJob Template属性と値に値を無視しなければならないか、または代入しなければなりません。
For any operation where a client requests attributes (such as a Get- Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if the IPP object does not support one or more of the requested attributes, the IPP object simply ignores the unsupported requested attributes and processes the request as if they had not been supplied, rather than returning this status code. In this case, the IPP object MUST return the 'successful-ok-ignored-or-substituted- attributes' status code and MAY return the unsupported attributes as values of the "requested-attributes" in the Unsupported Attributes Group (see section 13.1.2.2).
どんな操作のためにも、IPPオブジェクトが要求された属性の1つ以上をサポートしないなら、まるでそれらがこのステータスコードを返すよりむしろ供給されていないかのように、クライアントが属性(Get仕事、Getプリンタ属性、またはGet仕事の属性操作などの)を要求するところで、IPPオブジェクトは、単にサポートされない要求された属性を無視して、要求を処理します。 セクション13.1を見てください。この場合IPPオブジェクトが'うまくいっているOKを返さなければならない、-、無視、-、-代入された属性の'状態がUnsupported Attributes Groupの「要求された属性」の値としてのサポートされない属性をコード化して、返すかもしれない、(.2 .2)。
13.1.4.13 client-error-uri-scheme-not-supported (0x040C)
13.1.4.13 uri体系がサポートしなかったクライアント誤り(0x040C)
The scheme of the client-supplied URI in a Print-URI or a Send-URI operation is not supported. See sections 3.1.6.1 and 3.1.7.
Print-URIかSend-URI操作におけるクライアントによって供給されたURIの体系はサポートされません。 そして、セクション3.1.6を見てください、.1、3.1 .7。
13.1.4.14 client-error-charset-not-supported (0x040D)
13.1.4.14 charsetがサポートしなかったクライアント誤り(0x040D)
For any operation, if the IPP Printer does not support the charset supplied by the client in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status and any 'text' or 'name' attributes using the 'utf-8' charset (see Section 3.1.4.1). See sections 3.1.6.1 and 3.1.7.
セクション3.1を見てください。'utf-8'charsetを使用して、IPP Printerが「属性-charset」操作属性におけるクライアントによって供給されたcharsetをサポートしないなら、Printerがどんな操作のためにも、操作を拒絶して、この状態とどんな'テキスト'か'名前'属性も返さなければならない、(.4 .1)。 そして、セクション3.1.6を見てください、.1、3.1 .7。
13.1.4.15 client-error-conflicting-attributes (0x040E)
13.1.4.15 クライアント誤り闘争属性(0x040E)
The request is rejected because some attribute values conflicted with the values of other attributes which this document does not permit to be substituted or ignored. The Printer object MUST also return in the Unsupported Attributes Group the conflicting attributes supplied by the client. See sections 3.1.7 and 3.2.1.2.
いくつかの属性値がこのドキュメントが代入するか、または無視するのを可能にしない他の属性の値と衝突したので、要求は拒絶されます。 また、PrinterオブジェクトはUnsupported Attributes Groupで属性がクライアントから供給した闘争を返さなければなりません。 セクション3.1.7と3.2を見てください。.1 .2。
Hastings, et al. Standards Track [Page 183] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[183ページ]: モデルと意味論2000年9月
13.1.4.16 client-error-compression-not-supported (0x040F)
13.1.4.16 圧縮がサポートしなかったクライアント誤り(0x040F)
The IPP object is refusing to service the request because the document data, as specified in the "compression" operation attribute, is compressed in a way that is not supported by the Printer object. This error is returned independent of the client-supplied "ipp- attribute-fidelity". The Printer object MUST return this status code, even if there are other Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See sections 3.1.6.1, 3.1.7, and 3.2.1.1.
IPPオブジェクトは、「圧縮」操作属性で指定されるドキュメントデータがPrinterオブジェクトによってサポートされない方法で圧縮されるので要求を修理するのを拒否しています。 この誤りはクライアントによって供給された「ipp属性信義」の如何にかかわらず返されます。 Printerオブジェクトはこのステータスコードを返さなければなりません、また、サポートされない他のJob Template属性があっても、この誤りがJob Template属性より大きい問題であるので。 そして、見る、セクション3.1 .6 .1 3.1 .7、3.2 .1 .1。
13.1.4.17 client-error-compression-error (0x0410)
13.1.4.17 クライアント誤り圧縮誤り(0×0410)
The IPP object is refusing to service the request because the document data cannot be decompressed when using the algorithm specified by the "compression" operation attribute. This error is returned independent of the client-supplied "ipp-attribute-fidelity". The Printer object MUST return this status code, even if there are Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See sections 3.1.7 and 3.2.1.1.
IPPオブジェクトは、「圧縮」操作属性によって指定されたアルゴリズムを使用するとき、ドキュメントデータを減圧できないので要求を修理するのを拒否しています。 この誤りはクライアントによって供給された「ipp属性信義」の如何にかかわらず返されます。 Printerオブジェクトはこのステータスコードを返さなければなりません、また、サポートされないJob Template属性があっても、この誤りがJob Template属性より大きい問題であるので。 セクション3.1.7と3.2を見てください。.1 .1。
13.1.4.18 client-error-document-format-error (0x0411)
13.1.4.18 クライアント誤りドキュメント形式誤り(0×0411)
The IPP object is refusing to service the request because Printer encountered an error in the document data while interpreting it. This error is returned independent of the client-supplied "ipp- attribute-fidelity". The Printer object MUST return this status code, even if there are Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See sections 3.1.7 and 3.2.1.1.
IPPオブジェクトは、Printerがそれを解釈している間、ドキュメントデータにおける誤りに遭遇したので要求を修理するのを拒否しています。 この誤りはクライアントによって供給された「ipp属性信義」の如何にかかわらず返されます。 Printerオブジェクトはこのステータスコードを返さなければなりません、また、サポートされないJob Template属性があっても、この誤りがJob Template属性より大きい問題であるので。 セクション3.1.7と3.2を見てください。.1 .1。
13.1.4.19 client-error-document-access-error (0x0412)
13.1.4.19 クライアント誤りドキュメントアクセスエラー(0×0412)
The IPP object is refusing to service the Print-URI or Send-URI request because Printer encountered an access error while attempting to validate the accessibility or access the document data specified in the "document-uri" operation attribute. The Printer MAY also return a specific document access error code using the "document- access-error" operation attribute (see section 3.1.6.4). This error is returned independent of the client-supplied "ipp-attribute- fidelity". The Printer object MUST return this status code, even if there are Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See sections 3.1.6.1 and 3.1.7.
IPPオブジェクトは、アクセシビリティを有効にするのを試みている間、Printerがアクセスエラーに遭遇したのでPrint-URIかSend-URI要求を修理するか、または「ドキュメント-uri」操作属性で指定されたドキュメントデータにアクセスするのを拒否しています。 セクション3.1を見てください。また、「ドキュメントアクセスエラー」操作属性を使用して、Printerが特定のドキュメントアクセスエラーコードを返すかもしれない、(.6 .4)。 「ipp信義を結果と考えること」クライアントによって供給されたの如何にかかわらずこの誤りは返されます。 Printerオブジェクトはこのステータスコードを返さなければなりません、また、サポートされないJob Template属性があっても、この誤りがJob Template属性より大きい問題であるので。 そして、セクション3.1.6を見てください、.1、3.1 .7。
Hastings, et al. Standards Track [Page 184] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[184ページ]: モデルと意味論2000年9月
13.1.5 Server Error Status Codes
13.1.5 サーバ誤りステータスコード
This class of status codes indicates cases in which the IPP object is aware that it has erred or is incapable of performing the request. The IPP object SHOULD include a message containing an explanation of the error situation, and whether it is a temporary or permanent condition.
このクラスのステータスコードはIPPオブジェクトがそれが間違えたのを意識しているか、または要求を実行できない場合を示します。 IPPオブジェクトSHOULDはエラー状態とそれが一時的であるか永久的な状態であるかどうかに関する説明を含むメッセージを含んでいます。
13.1.5.1 server-error-internal-error (0x0500)
13.1.5.1 サーバ誤り内部エラー(0×0500)
The IPP object encountered an unexpected condition that prevented it from fulfilling the request. This error status code differs from "server-error-temporary-error" in that it implies a more permanent type of internal error. It also differs from "server-error-device- error" in that it implies an unexpected condition (unlike a paper-jam or out-of-toner problem which is undesirable but expected). This error status code indicates that probably some knowledgeable human intervention is required.
IPPオブジェクトはそれが要求を実現させるのを防いだ予期していなかった状態に遭遇しました。 この誤りステータスコードは、より永久的なタイプの内部エラーを含意するという点において「サーバの誤りの一時的な誤り」と異なっています。 また、異なっている、「サーバ誤りデバイス誤り、」 予期していなかった条件(望ましくない、しかし、期待している紙ジャムかトナーで出ている問題と異なった)を含意するので。 この誤りステータスコードは、たぶん何らかの博識な人間の介入が必要であることを示します。
13.1.5.2 server-error-operation-not-supported (0x0501)
13.1.5.2 操作がサポートしなかったサーバ誤り(0×0501)
The IPP object does not support the functionality required to fulfill the request. This is the appropriate response when the IPP object does not recognize an operation or is not capable of supporting it. See sections 3.1.6.1 and 3.1.7.
IPPオブジェクトは要求を実現させるのに必要である機能性をサポートしません。 これは、IPPオブジェクトが操作を認識しないときの適切な応答であるかそれをサポートすることができません。 そして、セクション3.1.6を見てください、.1、3.1 .7。
13.1.5.3 server-error-service-unavailable (0x0502)
13.1.5.3 入手できないサーバ誤りサービス(0×0502)
The IPP object is currently unable to handle the request due to a temporary overloading or maintenance of the IPP object. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay may be indicated in the message. If no delay is given, the IPP application should handle the response as it would for a "server-error- temporary-error" response. If the condition is more permanent, the error status codes "client-error-gone" or "client-error-not-found" could be used.
IPPオブジェクトは現在、IPPオブジェクトの一時的な積みすぎかメインテナンスのため要求を扱うことができません。 含意はこれが少し遅れてから軽減される一時的な病態であるということです。 知られているなら、遅れの長さはメッセージで示されるかもしれません。 遅れを全く与えないなら、IPPアプリケーションは「サーバ誤り一時的な誤り」応答のために処理するように応答を処理するべきです。 状態が、より多くのパーマ、誤りステータスコードである、「クライアント誤り過ぎ去る、」 「誤りが当たらなかったクライアント」を使用できました。
13.1.5.4 server-error-version-not-supported (0x0503)
13.1.5.4 誤りバージョンがサポートしなかったサーバ(0×0503)
The IPP object does not support, or refuses to support, the IPP protocol version that was supplied as the value of the "version- number" operation parameter in the request. The IPP object is indicating that it is unable or unwilling to complete the request using the same major and minor version number as supplied in the request other than with this error message. The error response SHOULD contain a "status-message" attribute (see section 3.1.6.2) describing
IPPオブジェクトは、サポートに支えもしませんし、拒否もしません、要求における、「バージョン番号」運転パラメータの値として供給されたIPPプロトコルバージョン。 IPPオブジェクトは、同じ主要で小さい方のバージョン番号を使用する要求を終了するのがこのエラーメッセージ以外の要求で供給するように不本意であることを示しています。 誤り応答SHOULDが「ステータスメッセージ」属性を含んでいる、(セクション3.1.6.2)説明を見てください。
Hastings, et al. Standards Track [Page 185] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[185ページ]: モデルと意味論2000年9月
why that version is not supported and what other versions are supported by that IPP object. See sections 3.1.6.1, 3.1.7, and 3.1.8.
そのバージョンがサポートされない理由と他のバージョンがサポートされることはそのIPPで反対します。 そして、見る、セクション3.1 .6 .1 3.1 .7、3.1 .8。
The error response MUST identify in the "version-number" operation parameter the closest version number that the IPP object does support. For example, if a client supplies version '1.0' and an IPP/1.1 object supports version '1.0', then it responds with version '1.0' in all responses to such a request. If the IPP/1.1 object does not support version '1.0', then it should accept the request and respond with version '1.1' or may reject the request and respond with this error code and version '1.1'. If a client supplies a version '1.2', the IPP/1.1 object should accept the request and return version '1.1' or may reject the request and respond with this error code and version '1.1'. See sections 3.1.8 and 4.4.14.
誤り応答は「バージョン番号」運転パラメータでIPPオブジェクトがサポートする中で最も近いバージョン番号を特定しなければなりません。 例えば、クライアントがバージョン'1.0'を供給して、IPP/1.1オブジェクトがバージョン'1.0'をサポートするなら、それはそのような要求へのすべての応答におけるバージョン'1.0'で応じます。 IPP/1.1オブジェクトがバージョン'1.0'をサポートしないなら、それは、要請を受け入れるべきであり、バージョン'1.1'で応じるか、要求を拒絶して、またはこのエラーコードとバージョン'1.1'で応じるかもしれません。 クライアントがバージョン'1.2'を供給するなら、IPP/1.1オブジェクトは、要請を受け入れるべきであり、バージョン'1.1'を返すか、要求を拒絶して、またはこのエラーコードとバージョン'1.1'で応じるかもしれません。 .14にセクション3.1 .8と4.4を見てください。
13.1.5.5 server-error-device-error (0x0504)
13.1.5.5 サーバ誤りデバイス誤り(0×0504)
A printer error, such as a paper jam, occurs while the IPP object processes a Print or Send operation. The response contains the true Job Status (the values of the "job-state" and "job-state-reasons" attributes). Additional information can be returned in the OPTIONAL "job-state-message" attribute value or in the OPTIONAL status message that describes the error in more detail. This error status code is only returned in situations where the Printer is unable to accept the create request because of such a device error. For example, if the Printer is unable to spool, and can only accept one job at a time, the reason it might reject a create request is that the printer currently has a paper jam. In many cases however, where the Printer object can accept the request even though the Printer has some error condition, the 'successful-ok' status code will be returned. In such a case, the client would look at the returned Job Object Attributes or later query the Printer to determine its state and state reasons.
IPPオブジェクトはPrintかSend操作を処理しますが、紙のジャムなどのプリンタ誤りは発生します。 応答は本当のJob Status(「仕事状態」と「仕事の州の理由」属性の値)を含んでいます。 OPTIONAL「仕事の州のメッセージ」属性値かさらに詳細に誤りについて説明するOPTIONALステータスメッセージで追加情報を返すことができます。 状況でPrinterが受け入れることができないところにこの誤りステータスコードを返すだけである、そのようなデバイス誤りのために要求を作成してください。 現在、それはプリンタです。例えば、Printerがスプールできないで、一度にある仕事を受け入れることができるだけであるなら、aを拒絶するかもしれない理由が要求を作成する、紙のジャムを食べます。 多くの場合しかしながら、Printerには何らかのエラー条件がありますが、Printerオブジェクトが要請を受け入れることができるところでは、'うまくいっているOK'ステータスコードを返すでしょう。 このような場合には、クライアントは、返されたJob Object Attributesを見るか、または後で状態と州の理由を決定するためにPrinterについて質問するでしょう。
13.1.5.6 server-error-temporary-error (0x0505)
13.1.5.6 サーバの誤りの一時的な誤り(0×0505)
A temporary error such as a buffer full write error, a memory overflow (i.e. the document data exceeds the memory of the Printer), or a disk full condition, occurs while the IPP Printer processes an operation. The client MAY try the unmodified request again at some later point in time with an expectation that the temporary internal error condition may have been cleared. Alternatively, as an implementation option, a Printer object MAY delay the response until the temporary condition is cleared so that no error is returned.
バッファ満などの一時的な誤りは誤りを書いて、IPP Printerは操作を処理しますが、メモリオーバーフロー(すなわち、ドキュメントデータはPrinterに関するメモリを超えている)、またはディスクの完全な条件が現れます。 クライアントは再び一時的な内部エラー状態がクリアされたかもしれないという時間内にの期待で何らかの後のポイントで変更されていない要求を試みるかもしれません。 あるいはまた、実装オプションとして、一時的な病態がクリアされるので誤りが全く返されないまで、Printerオブジェクトは応答を遅らせるかもしれません。
Hastings, et al. Standards Track [Page 186] RFC 2911 IPP/1.1: Model and Semantics September 2000
ヘイスティングズ、他 規格はRFC2911IPP/1.1を追跡します[186ページ]: モデルと意味論2000年9月
13.1.5.7 server-error-not-accepting-jobs (0x0506)
13.1.5.7 仕事を受け入れないサーバ誤り(0×0506)
A temporary error indicating that the Printer is not currently accepting jobs, because the administrator has set the value of the Printer's "printer-is-accepting-jobs" attribute to 'false' (by means outside the scope of this IPP/1.1 document).
管理者が'誤り'(このIPP/1.1ドキュメントの範囲の外の手段による)に「プリンタは仕事を受け入れている」というPrinterの属性の値を設定したのでPrinterが現在仕事を受け入れていないのを示す一時的な誤り。
13.1.5.8 server-error-busy (0x0507)
13.1.5.8 誤りが忙しくするサーバ(0×0507)
A temporary error indicating that the Printer is too busy processing jobs and/or other requests. The client SHOULD try the unmodified request again at some later point in time with an expectation that the temporary busy condition will have been cleared.
Printerが忙し過ぎる処理仕事、そして/または、他の要求であることを示す一時的な誤り。 クライアントSHOULDは再び一時的な忙しい状態がクリアされてしまうだろうという時間内にの期待で何らかの後のポイントで変更されていない要求を試みます。
13.1.5.9 server-error-job-canceled (0x0508)
13.1.5.9 サーバ誤り仕事は中止されました。(0×0508)
一覧
スポンサーリンク
