RFC2566 日本語訳
2566 Internet Printing Protocol/1.0: Model and Semantics. R. deBry, T.Hastings, R. Herriot, S. Isaacson, P. Powell. April 1999. (Format: TXT=438887 bytes) (Obsoleted by RFC2911) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. deBry
Request for Comments: 2566 Utah Valley State College
Category: Experimental T. Hastings
Xerox Corporation
R. Herriot
Xerox Corporation
S. Isaacson
Novell, Inc.
P. Powell
Astart Technologies
April 1999
Network Working Group R. deBry Request for Comments: 2566 Utah Valley State College Category: Experimental T. Hastings Xerox Corporation R. Herriot Xerox Corporation S. Isaacson Novell, Inc. P. Powell Astart Technologies April 1999
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Model and Semantics
Status of this Memo
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society (1999). All Rights Reserved.
IESG Note
IESG Note
This document defines an Experimental protocol for the Internet community. The IESG expects that a revised version of this protocol will be published as Proposed Standard protocol. The Proposed Standard, when published, is expected to change from the protocol defined in this memo. In particular, it is expected that the standards-track version of the protocol will incorporate strong authentication and privacy features, and that an "ipp:" URL type will be defined which supports those security measures. Other changes to the protocol are also possible. Implementors are warned that future versions of this protocol may not interoperate with the version of IPP defined in this document, or if they do interoperate, that some protocol features may not be available.
This document defines an Experimental protocol for the Internet community. The IESG expects that a revised version of this protocol will be published as Proposed Standard protocol. The Proposed Standard, when published, is expected to change from the protocol defined in this memo. In particular, it is expected that the standards-track version of the protocol will incorporate strong authentication and privacy features, and that an "ipp:" URL type will be defined which supports those security measures. Other changes to the protocol are also possible. Implementors are warned that future versions of this protocol may not interoperate with the version of IPP defined in this document, or if they do interoperate, that some protocol features may not be available.
The IESG encourages experimentation with this protocol, especially in combination with Transport Layer Security (TLS) [RFC 2246], to help determine how TLS may effectively be used as a security layer for IPP.
The IESG encourages experimentation with this protocol, especially in combination with Transport Layer Security (TLS) [RFC 2246], to help determine how TLS may effectively be used as a security layer for IPP.
deBry, et al. Experimental [Page 1] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 1] RFC 2566 IPP/1.0: Model and Semantics April 1999
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.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs. 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.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs. This document also addresses security, internationalization, and directory issues.
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.0: Model and Semantics (this document)
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
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.0: Model and Semantics (this document) Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The "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. Operator and administrator requirements are out of scope for version 1.0.
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 specifications, 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 specifications, and gives background and rationale for the IETF working group's major decisions.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of
deBry, et al. Experimental [Page 2] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 2] RFC 2566 IPP/1.0: Model and Semantics April 1999
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 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.
Table of Contents
Table of Contents
1. Introduction 8 1.1 Simplified Printing Model 9 2. IPP Objects 11 2.1 Printer Object 12 2.2 Job Object 14 2.3 Object Relationships 14 2.4 Object Identity 15 3. IPP Operations 18 3.1 Common Semantics 19 3.1.1 Required Parameters 19 3.1.2 Operation IDs and Request IDs 20 3.1.3 Attributes 20 3.1.4 Character Set and Natural Language Operation Attributes 22 3.1.4.1 Request Operation Attributes 22 3.1.4.2 Response Operation Attributes 26 3.1.5 Operation Targets 28 3.1.6 Operation Status Codes and Messages 29 3.1.7 Versions 30 3.1.8 Job Creation Operations 32 3.2 Printer Operations 34 3.2.1 Print-Job Operation 34 3.2.1.1 Print-Job Request 34 3.2.1.2 Print-Job Response 38 3.2.2 Print-URI Operation 41 3.2.3 Validate-Job Operation 42 3.2.4 Create-Job Operation 42 3.2.5 Get-Printer-Attributes Operation 43 3.2.5.1 Get-Printer-Attributes Request 44 3.2.5.2 Get-Printer-Attributes Response 46 3.2.6 Get-Jobs Operation 47 3.2.6.1 Get-Jobs Request 47 3.2.6.2 Get-Jobs Response 49 3.3 Job Operations 50 3.3.1 Send-Document Operation 50 3.3.1.1 Send-Document Request 51 3.3.1.2 Send-Document Response 53 3.3.2 Send-URI Operation 54
1. Introduction 8 1.1 Simplified Printing Model 9 2. IPP Objects 11 2.1 Printer Object 12 2.2 Job Object 14 2.3 Object Relationships 14 2.4 Object Identity 15 3. IPP Operations 18 3.1 Common Semantics 19 3.1.1 Required Parameters 19 3.1.2 Operation IDs and Request IDs 20 3.1.3 Attributes 20 3.1.4 Character Set and Natural Language Operation Attributes 22 3.1.4.1 Request Operation Attributes 22 3.1.4.2 Response Operation Attributes 26 3.1.5 Operation Targets 28 3.1.6 Operation Status Codes and Messages 29 3.1.7 Versions 30 3.1.8 Job Creation Operations 32 3.2 Printer Operations 34 3.2.1 Print-Job Operation 34 3.2.1.1 Print-Job Request 34 3.2.1.2 Print-Job Response 38 3.2.2 Print-URI Operation 41 3.2.3 Validate-Job Operation 42 3.2.4 Create-Job Operation 42 3.2.5 Get-Printer-Attributes Operation 43 3.2.5.1 Get-Printer-Attributes Request 44 3.2.5.2 Get-Printer-Attributes Response 46 3.2.6 Get-Jobs Operation 47 3.2.6.1 Get-Jobs Request 47 3.2.6.2 Get-Jobs Response 49 3.3 Job Operations 50 3.3.1 Send-Document Operation 50 3.3.1.1 Send-Document Request 51 3.3.1.2 Send-Document Response 53 3.3.2 Send-URI Operation 54
deBry, et al. Experimental [Page 3] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 3] RFC 2566 IPP/1.0: Model and Semantics April 1999
3.3.3 Cancel-Job Operation 54 3.3.3.1 Cancel-Job Request 54 3.3.3.2 Cancel-Job Response 55 3.3.4 Get-Job-Attributes Operation 56 3.3.4.1 Get-Job-Attributes Request 57 3.3.4.2 Get-Job-Attributes Response 57 4. Object Attributes 58 4.1 Attribute Syntaxes 59 4.1.1 'text' 60 4.1.1.1 'textWithoutLanguage' 61 4.1.1.2 'textWithLanguage' 61 4.1.2 'name' 62 4.1.2.1 'nameWithoutLanguage' 62 4.1.2.2 'nameWithLanguage' 63 4.1.2.3 Matching 'name' attribute values 63 4.1.3 'keyword' 64 4.1.4 'enum' 65 4.1.5 'uri' 65 4.1.6 'uriScheme' 65 4.1.7 'charset' 66 4.1.8 'naturalLanguage' 67 4.1.9 'mimeMediaType' 67 4.1.10 'octetString' 69 4.1.11 'boolean' 69 4.1.12 'integer' 69 4.1.13 'rangeOfInteger' 69 4.1.14 'dateTime' 69 4.1.15 'resolution' 69 4.1.16 '1setOf X' 70 4.2 Job Template Attributes 70 4.2.1 job-priority (integer(1:100)) 74 4.2.2 job-hold-until (type3 keyword | name (MAX)) 75 4.2.3 job-sheets (type3 keyword | name(MAX)) 75 4.2.4 multiple-document-handling (type2 keyword) 76 4.2.5 copies (integer(1:MAX)) 77 4.2.6 finishings (1setOf type2 enum) 78 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 79 4.2.8 sides (type2 keyword) 80 4.2.9 number-up (integer(1:MAX)) 80 4.2.10 orientation-requested (type2 enum) 81 4.2.11 media (type3 keyword | name(MAX)) 82 4.2.12 printer-resolution (resolution) 83 4.2.13 print-quality (type2 enum) 83 4.3 Job Description Attributes 84 4.3.1 job-uri (uri) 85 4.3.2 job-id (integer(1:MAX)) 85 4.3.3 job-printer-uri (uri) 86 4.3.4 job-more-info (uri) 86
3.3.3 Cancel-Job Operation 54 3.3.3.1 Cancel-Job Request 54 3.3.3.2 Cancel-Job Response 55 3.3.4 Get-Job-Attributes Operation 56 3.3.4.1 Get-Job-Attributes Request 57 3.3.4.2 Get-Job-Attributes Response 57 4. Object Attributes 58 4.1 Attribute Syntaxes 59 4.1.1 'text' 60 4.1.1.1 'textWithoutLanguage' 61 4.1.1.2 'textWithLanguage' 61 4.1.2 'name' 62 4.1.2.1 'nameWithoutLanguage' 62 4.1.2.2 'nameWithLanguage' 63 4.1.2.3 Matching 'name' attribute values 63 4.1.3 'keyword' 64 4.1.4 'enum' 65 4.1.5 'uri' 65 4.1.6 'uriScheme' 65 4.1.7 'charset' 66 4.1.8 'naturalLanguage' 67 4.1.9 'mimeMediaType' 67 4.1.10 'octetString' 69 4.1.11 'boolean' 69 4.1.12 'integer' 69 4.1.13 'rangeOfInteger' 69 4.1.14 'dateTime' 69 4.1.15 'resolution' 69 4.1.16 '1setOf X' 70 4.2 Job Template Attributes 70 4.2.1 job-priority (integer(1:100)) 74 4.2.2 job-hold-until (type3 keyword | name (MAX)) 75 4.2.3 job-sheets (type3 keyword | name(MAX)) 75 4.2.4 multiple-document-handling (type2 keyword) 76 4.2.5 copies (integer(1:MAX)) 77 4.2.6 finishings (1setOf type2 enum) 78 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 79 4.2.8 sides (type2 keyword) 80 4.2.9 number-up (integer(1:MAX)) 80 4.2.10 orientation-requested (type2 enum) 81 4.2.11 media (type3 keyword | name(MAX)) 82 4.2.12 printer-resolution (resolution) 83 4.2.13 print-quality (type2 enum) 83 4.3 Job Description Attributes 84 4.3.1 job-uri (uri) 85 4.3.2 job-id (integer(1:MAX)) 85 4.3.3 job-printer-uri (uri) 86 4.3.4 job-more-info (uri) 86
deBry, et al. Experimental [Page 4] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 4] RFC 2566 IPP/1.0: Model and Semantics April 1999
4.3.5 job-name (name(MAX)) 86 4.3.6 job-originating-user-name (name(MAX)) 86 4.3.7 job-state (type1 enum) 87 4.3.8 job-state-reasons (1setOf type2 keyword) 90 4.3.9 job-state-message (text(MAX)) 92 4.3.10 number-of-documents (integer(0:MAX)) 93 4.3.11 output-device-assigned (name(127)) 93 4.3.12 time-at-creation (integer(0:MAX)) 93 4.3.13 time-at-processing (integer(0:MAX)) 93 4.3.14 time-at-completed (integer(0:MAX)) 94 4.3.15 number-of-intervening-jobs (integer(0:MAX)) 94 4.3.16 job-message-from-operator (text(127)) 94 4.3.17 job-k-octets (integer(0:MAX)) 94 4.3.18 job-impressions (integer(0:MAX)) 95 4.3.19 job-media-sheets (integer(0:MAX)) 95 4.3.20 job-k-octets-processed (integer(0:MAX)) 96 4.3.21 job-impressions-completed (integer(0:MAX)) 96 4.3.22 job-media-sheets-completed (integer(0:MAX)) 96 4.3.23 attributes-charset (charset) 97 4.3.24 attributes-natural-language (naturalLanguage) 97 4.4 Printer Description Attributes 97 4.4.1 printer-uri-supported (1setOf uri) 99 4.4.2 uri-security-supported (1setOf type2 keyword) 100 4.4.3 printer-name (name(127)) 101 4.4.4 printer-location (text(127)) 101 4.4.5 printer-info (text(127)) 101 4.4.6 printer-more-info (uri) 101 4.4.7 printer-driver-installer (uri) 102 4.4.8 printer-make-and-model (text(127)) 102 4.4.9 printer-more-info-manufacturer (uri) 102 4.4.10 printer-state (type1 enum) 102 4.4.11 printer-state-reasons (1setOf type2 keyword) 103 4.4.12 printer-state-message (text(MAX)) 106 4.4.13 operations-supported (1setOf type2 enum) 106 4.4.14 charset-configured (charset) 107 4.4.15 charset-supported (1setOf charset) 107 4.4.16 natural-language-configured (naturalLanguage) 107 4.4.17 generated-natural-language-supported(1setOf naturalLanguage108 4.4.18 document-format-default (mimeMediaType) 108 4.4.19 document-format-supported (1setOf mimeMediaType) 108 4.4.20 printer-is-accepting-jobs (boolean) 109 4.4.21 queued-job-count (integer(0:MAX)) 109 4.4.22 printer-message-from-operator (text(127)) 109 4.4.23 color-supported (boolean) 109 4.4.24 reference-uri-schemes-supported (1setOf uriScheme) 109 4.4.25 pdl-override-supported (type2 keyword) 110 4.4.26 printer-up-time (integer(1:MAX)) 110 4.4.27 printer-current-time (dateTime) 111
4.3.5 job-name (name(MAX)) 86 4.3.6 job-originating-user-name (name(MAX)) 86 4.3.7 job-state (type1 enum) 87 4.3.8 job-state-reasons (1setOf type2 keyword) 90 4.3.9 job-state-message (text(MAX)) 92 4.3.10 number-of-documents (integer(0:MAX)) 93 4.3.11 output-device-assigned (name(127)) 93 4.3.12 time-at-creation (integer(0:MAX)) 93 4.3.13 time-at-processing (integer(0:MAX)) 93 4.3.14 time-at-completed (integer(0:MAX)) 94 4.3.15 number-of-intervening-jobs (integer(0:MAX)) 94 4.3.16 job-message-from-operator (text(127)) 94 4.3.17 job-k-octets (integer(0:MAX)) 94 4.3.18 job-impressions (integer(0:MAX)) 95 4.3.19 job-media-sheets (integer(0:MAX)) 95 4.3.20 job-k-octets-processed (integer(0:MAX)) 96 4.3.21 job-impressions-completed (integer(0:MAX)) 96 4.3.22 job-media-sheets-completed (integer(0:MAX)) 96 4.3.23 attributes-charset (charset) 97 4.3.24 attributes-natural-language (naturalLanguage) 97 4.4 Printer Description Attributes 97 4.4.1 printer-uri-supported (1setOf uri) 99 4.4.2 uri-security-supported (1setOf type2 keyword) 100 4.4.3 printer-name (name(127)) 101 4.4.4 printer-location (text(127)) 101 4.4.5 printer-info (text(127)) 101 4.4.6 printer-more-info (uri) 101 4.4.7 printer-driver-installer (uri) 102 4.4.8 printer-make-and-model (text(127)) 102 4.4.9 printer-more-info-manufacturer (uri) 102 4.4.10 printer-state (type1 enum) 102 4.4.11 printer-state-reasons (1setOf type2 keyword) 103 4.4.12 printer-state-message (text(MAX)) 106 4.4.13 operations-supported (1setOf type2 enum) 106 4.4.14 charset-configured (charset) 107 4.4.15 charset-supported (1setOf charset) 107 4.4.16 natural-language-configured (naturalLanguage) 107 4.4.17 generated-natural-language-supported(1setOf naturalLanguage108 4.4.18 document-format-default (mimeMediaType) 108 4.4.19 document-format-supported (1setOf mimeMediaType) 108 4.4.20 printer-is-accepting-jobs (boolean) 109 4.4.21 queued-job-count (integer(0:MAX)) 109 4.4.22 printer-message-from-operator (text(127)) 109 4.4.23 color-supported (boolean) 109 4.4.24 reference-uri-schemes-supported (1setOf uriScheme) 109 4.4.25 pdl-override-supported (type2 keyword) 110 4.4.26 printer-up-time (integer(1:MAX)) 110 4.4.27 printer-current-time (dateTime) 111
deBry, et al. Experimental [Page 5] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 5] RFC 2566 IPP/1.0: Model and Semantics April 1999
4.4.28 multiple-operation-time-out (integer(1:MAX)) 111 4.4.29 compression-supported (1setOf type3 keyword) 111 4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) 112 4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) 112 4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) 112 5. Conformance 112 5.1 Client Conformance Requirements 112 5.2 IPP Object Conformance Requirements 113 5.2.1 Objects 113 5.2.2 Operations 113 5.2.3 IPP Object Attributes 114 5.2.4 Extensions 114 5.2.5 Attribute Syntaxes 115 5.3 Charset and Natural Language Requirements 115 5.4 Security Conformance Requirements 115 6. IANA Considerations (registered and private extensions) 116 6.1 Typed 'keyword' and 'enum' Extensions 116 6.2 Attribute Extensibility 119 6.3 Attribute Syntax Extensibility 119 6.4 Operation Extensibility 120 6.5 Attribute Groups 120 6.6 Status Code Extensibility 120 6.7 Registration of MIME types/sub-types for document-formats 121 6.8 Registration of charsets for use in 'charset' attribute values121 7. Internationalization Considerations 121 8. Security Considerations 125 8.1 Security Scenarios 126 8.1.1 Client and Server in the Same Security Domain 126 8.1.2 Client and Server in Different Security Domains 126 8.1.3 Print by Reference 127 8.2 URIs for SSL3 and non-SSL3 Access 127 8.3 The "requesting-user-name" (name(MAX)) Operation Attribute 127 8.4 Restricted Queries 129 8.5 Queries on jobs submitted using non-IPP protocols 129 8.6 IPP Security Application Profile for SSL3 130 9. References 131 10. Authors' Addresses 134 11. Formats for IPP Registration Proposals 136 11.1 Type2 keyword attribute values registration 136 11.2 Type3 keyword attribute values registration 137 11.3 Type2 enum attribute values registration 137 11.4 Type3 enum attribute values registration 137 11.5 Attribute registration 138 11.6 Attribute Syntax registration 138 11.7 Operation registration 139 11.8 Attribute Group registration 139 11.9 Status code registration 139 12.APPENDIX A: Terminology 141
4.4.28 multiple-operation-time-out (integer(1:MAX)) 111 4.4.29 compression-supported (1setOf type3 keyword) 111 4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) 112 4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) 112 4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) 112 5. Conformance 112 5.1 Client Conformance Requirements 112 5.2 IPP Object Conformance Requirements 113 5.2.1 Objects 113 5.2.2 Operations 113 5.2.3 IPP Object Attributes 114 5.2.4 Extensions 114 5.2.5 Attribute Syntaxes 115 5.3 Charset and Natural Language Requirements 115 5.4 Security Conformance Requirements 115 6. IANA Considerations (registered and private extensions) 116 6.1 Typed 'keyword' and 'enum' Extensions 116 6.2 Attribute Extensibility 119 6.3 Attribute Syntax Extensibility 119 6.4 Operation Extensibility 120 6.5 Attribute Groups 120 6.6 Status Code Extensibility 120 6.7 Registration of MIME types/sub-types for document-formats 121 6.8 Registration of charsets for use in 'charset' attribute values121 7. Internationalization Considerations 121 8. Security Considerations 125 8.1 Security Scenarios 126 8.1.1 Client and Server in the Same Security Domain 126 8.1.2 Client and Server in Different Security Domains 126 8.1.3 Print by Reference 127 8.2 URIs for SSL3 and non-SSL3 Access 127 8.3 The "requesting-user-name" (name(MAX)) Operation Attribute 127 8.4 Restricted Queries 129 8.5 Queries on jobs submitted using non-IPP protocols 129 8.6 IPP Security Application Profile for SSL3 130 9. References 131 10. Authors' Addresses 134 11. Formats for IPP Registration Proposals 136 11.1 Type2 keyword attribute values registration 136 11.2 Type3 keyword attribute values registration 137 11.3 Type2 enum attribute values registration 137 11.4 Type3 enum attribute values registration 137 11.5 Attribute registration 138 11.6 Attribute Syntax registration 138 11.7 Operation registration 139 11.8 Attribute Group registration 139 11.9 Status code registration 139 12.APPENDIX A: Terminology 141
deBry, et al. Experimental [Page 6] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 6] RFC 2566 IPP/1.0: Model and Semantics April 1999
12.1 Conformance Terminology 141 12.1.1 NEED NOT 141 12.2 Model Terminology 141 12.2.1 Keyword 141 12.2.2 Attributes 141 12.2.2.1 Attribute Name 141 12.2.2.2 Attribute Group Name 142 12.2.2.3 Attribute Value 142 12.2.2.4 Attribute Syntax 142 12.2.3 Supports 142 12.2.4 print-stream page 144 12.2.5 impression 144 13.APPENDIX B: Status Codes and Suggested Status Code Messages 145 13.1 Status Codes 146 13.1.1 Informational 146 13.1.2 Successful Status Codes 146 13.1.2.1 successful-ok (0x0000) 146 13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 146 13.1.2.3 successful-ok-conflicting-attributes (0x0002) 147 13.1.3 Redirection Status Codes 147 13.1.4 Client Error Status Codes 147 13.1.4.1 client-error-bad-request (0x0400) 147 13.1.4.2 client-error-forbidden (0x0401) 147 13.1.4.3 client-error-not-authenticated (0x0402) 148 13.1.4.4 client-error-not-authorized (0x0403) 148 13.1.4.5 client-error-not-possible (0x0404) 148 13.1.4.6 client-error-timeout (0x0405) 148 13.1.4.7 client-error-not-found (0x0406) 149 13.1.4.8 client-error-gone (0x0407) 149 13.1.4.9 client-error-request-entity-too-large (0x0408) 149 13.1.4.10client-error-request-value-too-long (0x0409) 150 13.1.4.11client-error-document-format-not-supported (0x040A) 150 13.1.4.12client-error-attributes-or-values-not-supported (0x040B) 150 13.1.4.13client-error-uri-scheme-not-supported (0x040C) 151 13.1.4.14client-error-charset-not-supported (0x040D) 151 13.1.4.15client-error-conflicting-attributes (0x040E) 151 13.1.5 Server Error Status Codes 151 13.1.5.1 server-error-internal-error (0x0500) 151 13.1.5.2 server-error-operation-not-supported (0x0501) 152 13.1.5.3 server-error-service-unavailable (0x0502) 152 13.1.5.4 server-error-version-not-supported (0x0503) 152 13.1.5.5 server-error-device-error (0x0504) 152 13.1.5.6 server-error-temporary-error (0x0505) 153 13.1.5.7 server-error-not-accepting-jobs (0x0506) 153 13.1.5.8 server-error-busy (0x0507) 153 13.1.5.9 server-error-job-canceled (0x0508) 153 13.2 Status Codes for IPP Operations 153 14.APPENDIX C: "media" keyword values 155
12.1 Conformance Terminology 141 12.1.1 NEED NOT 141 12.2 Model Terminology 141 12.2.1 Keyword 141 12.2.2 Attributes 141 12.2.2.1 Attribute Name 141 12.2.2.2 Attribute Group Name 142 12.2.2.3 Attribute Value 142 12.2.2.4 Attribute Syntax 142 12.2.3 Supports 142 12.2.4 print-stream page 144 12.2.5 impression 144 13.APPENDIX B: Status Codes and Suggested Status Code Messages 145 13.1 Status Codes 146 13.1.1 Informational 146 13.1.2 Successful Status Codes 146 13.1.2.1 successful-ok (0x0000) 146 13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 146 13.1.2.3 successful-ok-conflicting-attributes (0x0002) 147 13.1.3 Redirection Status Codes 147 13.1.4 Client Error Status Codes 147 13.1.4.1 client-error-bad-request (0x0400) 147 13.1.4.2 client-error-forbidden (0x0401) 147 13.1.4.3 client-error-not-authenticated (0x0402) 148 13.1.4.4 client-error-not-authorized (0x0403) 148 13.1.4.5 client-error-not-possible (0x0404) 148 13.1.4.6 client-error-timeout (0x0405) 148 13.1.4.7 client-error-not-found (0x0406) 149 13.1.4.8 client-error-gone (0x0407) 149 13.1.4.9 client-error-request-entity-too-large (0x0408) 149 13.1.4.10client-error-request-value-too-long (0x0409) 150 13.1.4.11client-error-document-format-not-supported (0x040A) 150 13.1.4.12client-error-attributes-or-values-not-supported (0x040B) 150 13.1.4.13client-error-uri-scheme-not-supported (0x040C) 151 13.1.4.14client-error-charset-not-supported (0x040D) 151 13.1.4.15client-error-conflicting-attributes (0x040E) 151 13.1.5 Server Error Status Codes 151 13.1.5.1 server-error-internal-error (0x0500) 151 13.1.5.2 server-error-operation-not-supported (0x0501) 152 13.1.5.3 server-error-service-unavailable (0x0502) 152 13.1.5.4 server-error-version-not-supported (0x0503) 152 13.1.5.5 server-error-device-error (0x0504) 152 13.1.5.6 server-error-temporary-error (0x0505) 153 13.1.5.7 server-error-not-accepting-jobs (0x0506) 153 13.1.5.8 server-error-busy (0x0507) 153 13.1.5.9 server-error-job-canceled (0x0508) 153 13.2 Status Codes for IPP Operations 153 14.APPENDIX C: "media" keyword values 155
deBry, et al. Experimental [Page 7] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 7] RFC 2566 IPP/1.0: Model and Semantics April 1999
15.APPENDIX D: Processing IPP Attributes 160 15.1 Fidelity 160 15.2 Page Description Language (PDL) Override 161 15.3 Using Job Template Attributes During Document Processing. 163 16.APPENDIX E: Generic Directory Schema 166 17.APPENDIX F: Change History for the Model and Semantics document 168 18.FULL COPYRIGHT STATEMENT 173
15.APPENDIX D: Processing IPP Attributes 160 15.1 Fidelity 160 15.2 Page Description Language (PDL) Override 161 15.3 Using Job Template Attributes During Document Processing. 163 16.APPENDIX E: Generic Directory Schema 166 17.APPENDIX F: Change History for the Model and Semantics document 168 18.FULL COPYRIGHT STATEMENT 173
1. Introduction
1. Introduction
The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing using Internet tools and technologies. IPP version 1.0 (IPP/1.0) focuses only on end user functionality. This document is just one of a suite of documents that fully define IPP. The full set of IPP documents includes:
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.0 (IPP/1.0) focuses only on end user functionality. This document is just one of a suite of documents that fully define IPP. 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.0: Model and Semantics (this document)
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
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.0: Model and Semantics (this document) Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569]
Anyone reading these documents for the first time is strongly encouraged to read the IPP documents in the above order.
Anyone reading these documents for the first time is strongly encouraged to read the IPP documents in the above order.
This document is laid out as follows:
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.0. 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.
- 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.0. 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.
deBry, et al. Experimental [Page 8] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 8] RFC 2566 IPP/1.0: Model and Semantics April 1999
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].
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].
- 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 that provides a Change History
summarizing the clarification and changes that might affect an
implementation since the June 30, 1998 draft.
- 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 that provides a Change History summarizing the clarification and changes that might affect an implementation since the June 30, 1998 draft.
1.1 Simplified Printing Model
1.1 Simplified Printing Model
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.0). IPP/1.0 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.0 (IPP/1.0) focuses only on end user functionality.
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.0). IPP/1.0 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.0 (IPP/1.0) focuses only on end user functionality.
The IPP/1.0 model encapsulates the important components of distributed printing into two object types:
The IPP/1.0 model encapsulates the important components of distributed printing into two object types:
- Printer (Section 2.1)
- Job (Section 2.2)
- Printer (Section 2.1) - Job (Section 2.2)
deBry, et al. Experimental [Page 9] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 9] RFC 2566 IPP/1.0: Model and Semantics April 1999
Each object type has an associated set of operations (see section 3) and attributes (see section 4).
Each object type has an associated set of operations (see section 3) and attributes (see section 4).
It is important, however, to understand that in real system implementations (which lie underneath the abstracted IPP/1.0 model), there are other components of a print service which are not explicitly defined in the IPP/1.0 model. The following figure illustrates where IPP/1.0 fits with respect to these other components.
It is important, however, to understand that in real system implementations (which lie underneath the abstracted IPP/1.0 model), there are other components of a print service which are not explicitly defined in the IPP/1.0 model. The following figure illustrates where IPP/1.0 fits with respect to these other components.
+--------------+
| 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)|
+-----------------+
+--------------+ | 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)| +-----------------+
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
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
deBry, et al. Experimental [Page 10] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 10] RFC 2566 IPP/1.0: Model and Semantics April 1999
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, 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.
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, 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.
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 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.
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. End users may also cancel the print job by using the Job object's Cancel-Job operation. The notification service is out of scope for IPP/1.0, 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.
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. End users may also cancel the print job by using the Job object's Cancel-Job operation. The notification service is out of scope for IPP/1.0, 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.
2. IPP Objects
2. IPP Objects
The IPP/1.0 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 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.
The IPP/1.0 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 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.
Each attribute included in the set of attributes defining an object type is labeled as:
Each attribute included in the set of attributes defining an object type is labeled as:
deBry, et al. Experimental [Page 11] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 11] RFC 2566 IPP/1.0: Model and Semantics April 1999
- "REQUIRED": each object MUST support the attribute.
- "OPTIONAL": each object MAY support the attribute.
- "REQUIRED": each object MUST support the attribute. - "OPTIONAL": each object MAY support the attribute.
There is no such similar labeling of attribute values. However, if an implementation supports an attribute, it MUST support at least one of the possible values for that attribute.
There is no such similar labeling of attribute values. However, if an implementation supports an attribute, it MUST support at least one of the possible values for that attribute.
2.1 Printer Object
2.1 Printer Object
The major component of the IPP/1.0 model is the Printer object. A Printer object implements the server-side of the IPP/1.0 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.
The major component of the IPP/1.0 model is the Printer object. A Printer object implements the server-side of the IPP/1.0 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.
The capabilities and state of a Printer object are described by its attributes. Printer attributes are divided into two groups:
The capabilities and state of a Printer object are described by its attributes. Printer attributes are divided into two groups:
- "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)
- "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)
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.
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.
Some examples of configurations supporting a Printer object include:
Some examples of configurations supporting a Printer object include:
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) 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
deBry, et al. Experimental [Page 12] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 12] RFC 2566 IPP/1.0: Model and Semantics April 1999
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.
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.
Legend:
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.
##### 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.
any indicates any network protocol or direct
connect, including IPP
any indicates any network protocol or direct connect, including IPP
embedded printer:
output device
+---------------+
O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
+---------------+
embedded printer: output device +---------------+ O +--------+ | ########### | /|\ | client |------------IPP------------># Printer # | / \ +--------+ | # Object # | | ########### | +---------------+
hosted printer:
+---------------+
O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ # Object # | |
########### +---------------+
hosted printer: +---------------+ O +--------+ ########### | | /|\ | client |--IPP--># Printer #-any->| output device | / \ +--------+ # Object # | | ########### +---------------+
+---------------+
fan out: | |
+-->| output device |
any/ | |
O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+-->| output device |
| |
+---------------+
+---------------+ fan out: | | +-->| output device | any/ | | O +--------+ ########### / +---------------+ /|\ | client |-IPP-># Printer #--* / \ +--------+ # Object # \ +---------------+ ########### any\ | | +-->| output device | | | +---------------+
deBry, et al. Experimental [Page 13] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 13] RFC 2566 IPP/1.0: Model and Semantics April 1999
2.2 Job Object
2.2 Job Object
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.
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.
The characteristics and state of a Job object are described by its attributes. Job attributes are grouped into two groups as follows:
The characteristics and state of a Job object are described by its attributes. Job attributes are grouped into two groups as follows:
- "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)
- "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-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) - "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)
An implementation MUST support at least one document per Job object. An implementation MAY support multiple documents per Job object. A document is either:
An implementation MUST support at least one document per Job object. An implementation MAY support multiple documents per Job object. A document is either:
- 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
- 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
In IPP/1.0, 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.
In IPP/1.0, 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.
2.3 Object Relationships
2.3 Object Relationships
IPP objects have relationships that are maintained persistently along with the persistent storage of the object attributes.
IPP objects have relationships that are maintained persistently along with the persistent storage of the object attributes.
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.
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.
deBry, et al. Experimental [Page 14] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 14] RFC 2566 IPP/1.0: Model and Semantics April 1999
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).
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).
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.
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.
2.4 Object Identity
2.4 Object Identity
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. The notion of a URI is a useful concept, however, until the notion of URI is more stable (i.e., defined more completely and deployed more widely), it is expected that the URIs used for IPP objects will actually be URLs [RFC2396]. 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.
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. The notion of a URI is a useful concept, however, until the notion of URI is more stable (i.e., defined more completely and deployed more widely), it is expected that the URIs used for IPP objects will actually be URLs [RFC2396]. 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.
An administrator configures Printer objects to either support or not support authentication and/or message privacy using SSL3 [SSL] (the mechanism for security configuration is outside the scope of IPP/1.0). 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.
An administrator configures Printer objects to either support or not support authentication and/or message privacy using SSL3 [SSL] (the mechanism for security configuration is outside the scope of IPP/1.0). 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.
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
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
deBry, et al. Experimental [Page 15] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 15] RFC 2566 IPP/1.0: Model and Semantics April 1999
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 a companion attribute, the "uri-security-supported" attribute, that has 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". These two attributes are fully described in sections 4.4.1 and 4.4.2.
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 a companion attribute, the "uri-security-supported" attribute, that has 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". These two attributes are fully described in sections 4.4.1 and 4.4.2.
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.
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.
Note: IPP/1.0 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.
Note: IPP/1.0 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.
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.
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.
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.
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.
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
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
deBry, et al. Experimental [Page 16] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 16] RFC 2566 IPP/1.0: Model and Semantics April 1999
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.
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.
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 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.
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 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.
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 IPP/1.0. 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.0の範囲の外の何らかのメカニズムを通して選ばれて、管理者でセットしました。 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).
- それぞれのPrinterオブジェクトは1つ以上のURIと同一視されています。 Printerの「uriが支えたプリンタ」属性はURIを含んでいます。
deBry, et al. Experimental [Page 17] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[17ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
- 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., 'ssl3' 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.
- 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 IPP/1.0 itself. 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.
- Printerオブジェクトの「セキュリティがサポートしたuri」属性は様々なPrinterオブジェクトURI(例えば、'ssl3'か'なにも')のために構成されたかもしれない通信チャネルセキュリティプロトコルを特定します。 - それぞれのJobオブジェクトはJob URIと同一視されています。 Jobの「仕事-uri」属性はURIを含んでいます。 - また、それぞれのJobオブジェクトは32ビットの、そして、陽の整数であるJob IDと同一視されています。 Jobの「仕事イド」属性はJob IDを含んでいます。 Job IDはJobオブジェクトを作成したPrinterオブジェクトの文脈の中でユニークであるだけです。 - それぞれのJobオブジェクトには、Jobオブジェクトを作成するのに使用されたPrinterオブジェクトのURIを含む「仕事のプリンタuri」属性があります。 この属性は、JobオブジェクトのためにURIだけを与えるときJobオブジェクトを作成したPrinterオブジェクトを決定するのに使用されます。 このリンケージが、そのJobでサポートされる言語、charsets、および操作を決定するのに必要です(そのようなサポートの基礎は作成しているPrinterオブジェクトから来ます)。 - それぞれのPrinterオブジェクトには、名前(必ずユニークであるというわけではない)があります。 管理者は、IPP/1.0自身の範囲の外の何らかのメカニズムを通してこの名前を選んで、設定します。 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オブジェクト属性などのオブジェクト属性と比べて)。 各要求はそれと共にどんな操作属性も運んで、オブジェクト属性、そして/または、ドキュメントデータが操作を実行するのが必要です。 各要求はオブジェクトから応答を必要とします。 各応答は応答パラメタとしてステータスコードで操作の成否を示します。 応答は操作要求の実行の間に生成されたどんな操作属性、オブジェクト属性、そして/または、ステータスメッセージも含んでいます。
deBry, et al. Experimental [Page 18] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[18ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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操作の意味論、要求と応答の両方について説明します、各操作に関連しているパラメタ、属性、および他のデータに関して。
The IPP/1.0 Printer operations are:
IPP/1.0Printer操作は以下の通りです。
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)
印刷仕事、(3.2に、仕事を有効にして(セクション3.2.3).1)印刷URI(セクション3.2.2)を区分する、雇用を創り出して(セクション3.2.4)プリンタ属性を得てください、(セクション3.2.5)ジョブスを得ます。(セクション3.2.6)
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)
ドキュメントを発信させている(セクション3.3.1)URIを発信させている(セクション3.3.2)キャンセル仕事(セクション3.3.3)、仕事の属性を得てください。(セクション3.3.4)
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である属性。
deBry, et al. Experimental [Page 19] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[19ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
The encoding and transport document [RFC2565] 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.
コード化と運送書類[RFC2565]はこれらのパラメタのコード化のための特別な規則を定義します。 他のすべての操作要素が、属性の属性とグループにより多くのジェネリック符号化規則を使用することで表されます。
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.13). The client specifies which operation is being requested by supplying the correct "operation-id" value.
それぞれのIPP操作要求は特定「操作イド」値を含んでいます。 有効値は「操作でサポートしている」Printer属性部で定義されます(セクション4.4.13を見てください)。 クライアントは、どの操作が正しい「操作イド」値を供給することによって要求されているかを指定します。
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であるかを示す順応声明を含んでいます。
deBry, et al. Experimental [Page 20] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[20ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 section 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. Section 15 gives 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.
どの属性をサポートとクライアントが要求で供給しなければならなくて、IPPオブジェクトが応答で供給しなければならないかへのIPPオブジェクトのために。 - 仕事のテンプレート属性: これらの属性は仕事の処理に影響します。 aのクライアントOPTIONALLY供給Job Template Attributesは要求を作成します、そして、属性であるとサポートされたすべてを受けるように受信オブジェクトを準備しなければなりません。 後でJob Template属性が元々何で要求されたかを見つけるためにJobオブジェクトについて質問できる、属性がJob Object Attributesとして応答で返される要求、およびそのようなものを作成してください。 どんな仕事の種類処理能力がサポートされるか、そして、デフォルトジョブ処理の振舞いが何であるかを見つけるためにJob Template属性に関してPrinterオブジェクトについて質問できます、そのような属性はPrinter Object Attributesとして応答で返されますが。 「ipp属性信義」操作属性はすべてのクライアントによって供給されたJob Template属性の処理に影響します(「ipp属性信義」と他の属性とのその関係の余すところのない解説に関してセクション15を見てください)。 - 仕事のオブジェクト属性: これらの属性はJobオブジェクトが向けられた質問操作に対応して返されます。 - プリンタオブジェクト属性: これらの属性はPrinterオブジェクトが向けられた質問操作に対応して返されます。 - サポートされない属性: aでは、要求を作成してください、そして、クライアントは1セットのOperationとJob Template属性を供給します。 これらの属性かそれらの値のどれかがPrinterオブジェクトでサポートされないなら、Printerオブジェクトは応答におけるサポートされない属性のセットを返します。 セクション15は属性が中のaが創造するクライアントで要求を提供したJob TemplateがPrinterオブジェクトによってどのように処理されるか、そして、サポートされない属性がどのようにクライアントに返されるかに関する余すところのない解説を与えます。 伸展性のために、どんなIPP目的も新しいか未知の属性を含む要求かそれがサポートを全く持っていない値を受け取るかもしれません。 そのような場合、IPPオブジェクトは、それが処理できることを処理して、応答におけるサポートされない属性を返します。
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.
その後、このセクションでは、各操作は、各要求と応答のために属性の許容されて予想されたグループを特定することによって、正式に定義されます。 モデルは各要求か応答におけるそれぞれのグループの特定の注文を特定しますが、各グループの中の属性は順不同であるかもしれません、別の方法で指定されない場合。
Each attribute specification 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のこれらの属性構文の記述を見てください。
deBry, et al. Experimental [Page 21] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[21ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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ドキュメントです。 ドキュメントデータを含んでいる操作応答が全くありません。
Note: 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 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.
いくらかのJobとPrinter属性で、マシン理解よりむしろ人知のためにテキスト文字列である値と名前を意図します(セクション4.1の'テキスト'と'名前'属性構文記述を見てください)。 以下のセクションは「属性-charsetと属性自然言語」と呼ばれる2特別なOperation Attributesについて説明します。 いつもこれらの属性はOperation Attributesグループの一部です。 ほとんどの属性グループにおいて、グループの中の属性の注文は重要ではありません。 しかしながら、Operation Attributesグループの中のこれらの2つの属性において、オーダーは重要です。 「属性-charset」属性はグループで最初の属性であるに違いありません、そして、「属性自然言語」属性はグループで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.0 operation request:
クライアントは供給しなければならなくて、PrinterオブジェクトはあらゆるIPP/1.0操作における属性が要求する以下のREQUIRED操作をサポートしなければなりません:
deBry, et al. Experimental [Page 22] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[22ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
"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 specification 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 object MUST indicate the
charset(s) supported as the values of the "charset-supported"
Printer attribute (see Section 4.4.15), 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によってサポートしていない'ステータスコードとどんな'テキスト'か'名前'属性も返さなければなりません。 Printerオブジェクトは「charsetによってサポートしている」Printer属性の値としてサポートされたcharset(s)を示さなければなりません(セクション4.4.15を見てください)、クライアントが、どの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 or ISO-
8859-1. Then the client will have to filter 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.
クライアントimplementersに以下に注意してください。 IPPオブジェクトが、'utf-8'がcharsetであるとサポートするだけでよいので、クライアントは複数のIPPオブジェクト実装で相互運用性を最大にするために「属性-charset」操作属性で'utf-8'を供給したがっているかもしれません、クライアントは、通っているだけであり、より簡単なcharsetを寄贈できますが、米国-ASCIIやISO8859-1のように。 そして、クライアントはそれがユーザに提示できない応答で返されるそれらの(または、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.
「属性自然言語」(naturalLanguage): この操作属性はクライアントがこの要求で供給しているどんな'テキスト'と'名前'属性によっても使用される自然言語を特定します。 また、この属性はPrinterオブジェクトSHOULDがすべての'テキスト'と'名前'属性に使用する自然言語とPrinterオブジェクトがこの要求への応答で返すステータスメッセージを特定します。
deBry, et al. Experimental [Page 23] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[23ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.16).
すなわち、Printerオブジェクトがテキストを作る属性のどれか、「仕事の州のメッセージ」、「プリンタメッセージを述べる」、およびステータスメッセージ(セクション3.1.6を見る)に関しては、Printerオブジェクトはサポートしている自然言語のいずれでもこれらのテキスト文字列を生成することができなければなりません。 「クライアントがサポートされない自然言語を要求するなら、Printerオブジェクトは指定されるとしてのPrinterの「当然の言語で構成された」属性によるPrinterの構成された自然言語のメッセージであると生成されたこれらを返さなければならない」(セクション4.4.16を見てください)。
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 identified by the Printer object's "natural-language-
configured" attribute, though support of additional natural
languages for these attributes is permitted.
クライアント、認証システム、オペレータ、システム管理者、またはメーカー(すなわち、「仕事の起因するユーザ名」、「プリンタ名」(名前)、「プリンタ位置」(テキスト)、「プリンタインフォメーション」(テキスト)、および「プリンタメーカーとモデル」(テキスト)のための)によって供給された他の'テキスト'と'名前'属性において、PrinterオブジェクトはPrinterオブジェクトの「当然の言語で構成された」属性によって特定された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,
IPPオブジェクトはどんな自然言語とどんなNatural Language Overrideも受け入れなければなりません、IPPオブジェクトがその自然言語をサポートする(そして「ipp属性信義」Operation属性の値の如何にかかわらず)か否かに関係なく。 すなわち、IPPオブジェクトは値がPrinterオブジェクトの「発生して当然の言語でサポートしている」属性において何であってもすべてのクライアント供給値を受け入れます。 その「言語によって発生して自然にサポートしている」属性は発生しているメッセージに適用されるだけです。
deBry, et al. Experimental [Page 24] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[24ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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目的はすべてのクライアントによって供給された属性のためにその自然言語を覚えていなければなりません、そして、質問に対応してそれらの属性を返すとき、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-
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.
例えば、属性がaでクライアントによって供給されるかもしれない「ジョブ名」は要求を作成します。 「自然言語を結果と考えてください」という属性によって特定された自然言語、または異なるなら、この属性のためのテキスト値はそうになるでしょう、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を使用するどんな属性でも供給された自然言語に基づく要求を拒絶してはいけません。
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.
この属性と例えば、値の値の構文と意味解釈に関してセクション4.1.8における'naturalLanguage'属性構文記述を見てください。
deBry, et al. Experimental [Page 25] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[25ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 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.
どちらの場合ではも、Printerオブジェクトは見かけの不一致で要求を拒絶しません。 charsetと自然言語の潜在的両立しない組み合わせはグローバルなオペレーションレベルにおいて、または、属性ごとのNatural Language Overrideレベルにおいて起こることができます。 さらに、応答がいつも明白な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.0 operation response:
Printerオブジェクトは供給しなければならなくて、クライアントはあらゆるIPP/1.0操作応答における以下の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
「属性-charset」(charset): この操作属性はPrinterオブジェクトがこの応答で返しているどんな'テキスト'と'名前'属性によっても使用されるcharsetを特定します。 この応答における値は要求でクライアントによって供給された「属性-charset」操作属性と同じ値でなければなりません。 これが可能でないなら
deBry, et al. Experimental [Page 26] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[26ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
(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が、要求した)、要求は拒絶されたでしょう。 セクション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の日本人の漢字から変換されるかもしれません、実装によって。
Note: 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
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.
「属性自然言語」(naturalLanguage): この操作属性はIPPオブジェクトがこの応答で返しているどんな'テキスト'と'名前'属性によっても使用される自然言語を特定します。 「属性-charset」操作属性と異なって、IPPオブジェクトは要求でクライアントによるそんなに供給されるのと同じ値を返す必要はありません。 IPPオブジェクトはクライアントによって供給された自然言語よりむしろPrinterオブジェクトの「構成された自然な言語」属性によって特定されるようにJobオブジェクトかPrinterの構成された自然言語の自然言語を返すかもしれません。 そして、異なった自然言語にはある応答におけるどんな'テキスト'か'名前'属性やステータスメッセージにも、IPPオブジェクトが値が「属性自然言語」操作属性で返したよりNatural Language Overrideメカニズムを使用しなければならない、(セクション4.1.1を見てください、.2、4.1 .2 .2) 各属性では、値は戻りました。 IPPオブジェクトは冗長にNatural Language Overrideメカニズムを使用するかもしれません、すなわち、操作が結果と考える応答の「属性自然言語」で供給された値と同じ自然言語に値がありさえするときにはそれを使用してください。
deBry, et al. Experimental [Page 27] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[27ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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を使用することで操作に向けられるなら、クライアントは余分な「仕事イド」操作属性を入れてはいけません。
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番目の属性であるに違いありません。
deBry, et al. Experimental [Page 28] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[28ページ]RFC2566IPP/1.0: モデルと意味論1999年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 [RFC2565] shows a mapping of IPP onto HTTP/1.1 and defines a new default port number for using IPP over HTTP/1.1.
以下に注意してください。 IPPコード化と運送書類[RFC2565]は、HTTP/1.1にIPPに関するマッピングを示していて、IPPを使用するために新しいデフォルトポートナンバーにHTTP/1.1以上を定義します。
3.1.6 Operation Status Codes and Messages
3.1.6 操作ステータスコードとメッセージ
Every operation response includes a REQUIRED "status-code" parameter and an OPTIONAL "status-message" operation attribute. The "status- code" provides information on the processing of a request. A "status-message" attribute provides a short textual description of the status of the operation. The status code is intended for use by automata, and 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 message, however it SHOULD do so in some implementation specific manner.
あらゆる操作応答がREQUIRED「ステータスコード」パラメタとOPTIONAL「ステータスメッセージ」操作属性を含んでいます。 「状態コード」は要求の処理の情報を提供します。 「ステータスメッセージ」属性は操作の状態の短い原文の記述を提供します。 ステータスコードは使用のためにオートマトンで意図します、そして、ステータスメッセージは人間のエンドユーザのために意図します。 応答が「ステータスメッセージ」属性を含んでいるなら、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. The "status-message" attribute's syntax is "text(255)". A client implementation of IPP SHOULD convert status code values into any localized message that has semantic meaning to the end user.
「ステータスコード」値は意味意味がある数値です。 値が0×0000だけから0x7FFFまで及ぶことができるのを除いて、「ステータスコード」構文は"type2 enum"(「属性構文」のセクション4.1を見る)と同様です。 セクション13は、ステータスコードについて説明して、数値を割り当てて、各ステータスコードのための対応するステータスメッセージを示します。 「ステータスメッセージ」属性の構文は「テキスト(255)」です。 いずれへのIPP SHOULD転向者状態コード値のクライアント実装は意味意味をエンドユーザに持っているメッセージをローカライズしました。
deBry, et al. Experimental [Page 29] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[29ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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). 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. 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オブジェクトが「ステータスメッセージ」操作属性をサポートするなら、PrinterオブジェクトはPrinterオブジェクトの「サポートされた発生している自然な言語」属性によって特定された自然言語のどれかのこのメッセージを生成することができなければなりません(操作属性がセクション3.1.4で指定した「属性自然言語」.1を見てください)。 このメッセージを生成するための選択があればどんな返された'テキスト'のための.1も結果と考えるセクション3.1.4で説明されるように、Printerオブジェクトはサポートされるならクライアント要求における、「属性自然言語」の値によって示された自然言語を使用します。さもなければ、PrinterオブジェクトはPrinterオブジェクトの自己の「構成された自然な言語」属性に値を使用します。 Printerであるなら、オブジェクトは「ステータスメッセージ」操作属性をサポートして、それはREQUIRED'utf-8'が以下の誤りステータスコードのためのステータスメッセージを返すためにcharsetするSHOULD使用(セクション13を見る)です: 'クライアント誤り悪い要求'の'charsetがサポートしなかったクライアント誤り'、'サーバ誤り内部エラー'、'操作がサポートしなかったサーバ誤り'、および'誤りバージョンがサポートしなかったサーバ'。 この場合、それは誤り応答で「属性-charset」操作属性の値を'utf-8'に設定しなければなりません。
3.1.7 Versions
3.1.7 バージョン
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. If the IPP object does not support that version, the object responds 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).
各操作要求と応答はそれと共に「バージョン番号」パラメタを運びます。 「バージョン番号」の各値がXがメジャーバージョン番号であり、Yがマイナーバージョン番号であるフォーム「X.Y」にあります。 クライアント要求にバージョン番号を含んでいることによって、クライアントは、それでIPPのどのバージョンを使用するかをそれが関心がある特定できます。 セクション13.1を見てください。IPPオブジェクトがそのバージョンをサポートしないなら、オブジェクトが'サーバ誤りバージョンでサポートされないこと'のサポートされる中で最も近いバージョン番号と共にステータスコードで応じる、(.5 .4)。
There is no version negotiation per se. However, if after receiving a 'server-error-version-not-supported' status code from an IPP object, there is nothing that prevents a client from trying again with a different version number. In order to conform to IPP/1.0, an implementation MUST support at least version '1.0'.
バージョン交渉が全くそういうものとしてありません。 しかしながら、IPPオブジェクトから'誤りバージョンがサポートしなかったサーバ'ステータスコードを受け取った後に何もクライアントが異なった見解番号で再試行するのを防ぐものがありません。 IPP/1.0に従うために、実装は少なくともバージョン'1.0'をサポートしなければなりません。
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 [RFC2566] or a new version of the Encoding and Transport document [RFC2565].
IPP ModelとIPPプロトコル変化の両方をカバーする「バージョン番号」の1つの概念しかありません。 ModelとSemanticsドキュメントの新しいバージョン[RFC2566]かEncodingとTransportドキュメントの新しいバージョン[RFC2565]を紹介するとき、したがって、バージョン番号は変化しなければなりません。
Changes to the major version number indicate structural or syntactic changes that make it impossible for older version of IPP clients and Printer objects to correctly parse and process the new or changed attributes, operations and responses. If the major version number
メジャーバージョン番号への変化はIPPクライアントとPrinterオブジェクトの旧式のバージョンが正しく新しいか変えられた属性、操作、および応答を分析して、処理するのを不可能にする構造的であるか構文の変化を示します。 メジャーバージョン番号です。
deBry, et al. Experimental [Page 30] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[30ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
changes, the minor version numbers is set to zero. As an example, adding the "ipp-attribute-fidelity" attribute (if it had not been part of version '1.0'), would have required a change to the major version number. Items that might affect the changing of the major version number include any changes to the Model and Semantics document [RFC2566] or the Encoding and Transport [RFC2565] itself, such as:
変化であり、マイナーバージョン番号はゼロに設定されます。 「ipp属性信義」属性を加えて(それがバージョン'1.0'の一部でなかったなら)、例がメジャーバージョン番号への変化を必要としただろうというとき。 メジャーバージョン番号の変化に影響するかもしれない項目がModelとSemanticsドキュメント[RFC2566]へのどんな変化かEncodingと以下などのTransport[RFC2565]自身も含んでいます。
- reordering of ordered attributes or attribute sets
- changes to the syntax of existing attributes
- changing Operation or Job Template attributes from OPTIONAL to
REQUIRED and vice versa
- adding REQUIRED (for an IPP object to support) operation
attributes
- adding REQUIRED (for an IPP object to support) operation
attribute groups
- adding values to existing operation attributes
- adding REQUIRED operations
- 属性セット--既存の属性の構文への変化--命令された属性を再命令するか、またはREQUIRED操作を加えて、既存の操作属性に価値を高めて、REQUIRED(IPPオブジェクトがサポートする)操作属性グループを加えて、REQUIRED(IPPオブジェクトがサポートする)操作属性を加えて、逆もまた同様にOperationかJob Template属性をOPTIONALからREQUIREDに変えること。
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 [RFC2565] (except adding attribute syntaxes). Examples of such changes are:
マイナーバージョン番号への変化はすべてのIPPオブジェクトに解釈されないかもしれませんが、無視するか、または理解できる新機能、属性、および属性値の追加を示します。 マイナーバージョン番号の変化に影響するかもしれない項目がコード化と輸送規則[RFC2565]ではなく、モデルオブジェクトと属性(属性構文を加えるのを除いた)へのどんな変化も含んでいます。 そのような変化に関する例は以下の通りです。
- 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.
- OPTIONALを加えて、OPTIONAL(IPPオブジェクトがサポートする)操作属性(すなわち、IPPオブジェクトがクライアントを混乱させないで無視できるそれらの属性)を加えて、新しいオブジェクト属性を加えて、新しい属性値を加えて、旧バージョンで新しいバージョンに含められなかったすべての拡大を分類します; (IPPオブジェクトがサポートする) 操作属性グループ(すなわち、IPPオブジェクトがクライアントを混乱させないで無視できるそれらの属性)--新しい状態で加えて、Job記述属性かPrinter記述属性をOPTIONALからREQUIREDに変えて、OPTIONAL操作を加えて、構文を結果と考えなさいか、逆もまた同様です。
The encoding of the "operation-id", the "version-number", the "status-code", and the "request-id" MUST NOT change over any version number (either major or minor). This rule guarantees that all future versions will be backwards compatible with all previous versions (at least for checking the "operation-id", the "version-number", and the "request-id"). In addition, any protocol elements (attributes, error
「操作イド」、「バージョン番号」、「ステータスコード」、および「要求イド」のコード化はどんなバージョン番号(主要であるか小さい方の)の上変化してはいけません。 これは、すべての将来のバージョンが後方にそうであるという保証がすべての旧バージョン(少なくとも「操作イド」、「バージョン番号」、および「要求イド」をチェックするための)と互換性があると裁決します。 さらに、いずれも要素について議定書の中で述べる、(属性、誤り
deBry, et al. Experimental [Page 31] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[31ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 major version NEED NOT support ALL previous versions. As each new major version is defined (through the release of a new specification), that major version will specify which previous major versions MUST be supported in compliant implementations.
ある主要なバージョンをサポートする実装はすべての旧バージョンをサポートしなければならないというわけではありません。 それぞれの新しい主要なバージョンが定義されるとき(新しい仕様のリリースで)、その主要なバージョンは、対応する実装でどの前の主要なバージョンをサポートしなければならないかを指定するでしょう。
3.1.8 Job Creation Operations
3.1.8 雇用創出操作
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 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操作の特殊活字の数字がこの操作のあとに続いている、(それぞれ別のドキュメントを作成する、新たにJobオブジェクトを作成してください、) Send-ドキュメント操作は要求にドキュメントデータを含んでいます、そして、(クライアントはドキュメントデータをプリンタに「押す」)Send-URI操作は要求におけるドキュメントデータのURI指示するものだけを含んでいます(Printerは参照をつけられた位置からドキュメントデータを「引きます」)。 これが最後の要求であることを示しながら、与えられたJobオブジェクトを求める最後のSend-ドキュメントかSend-URI要求が「最後のドキュメント」操作属性セットを'本当に'含んでいます。
Throughout this model specification, the term "create request" is used to refer to any of these three operation requests.
このモデル仕様中では、「要求を作成する」という用語は、これらの3つの操作要求のどれかを示すのに使用されます。
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
1つのSend-ドキュメント操作だけがあとに続いたCreate-仕事の操作がPrint-仕事の操作に意味的に同等である、しかしながら、性能理由のために、クライアントSHOULDはPrint-仕事の操作を使用します。
deBry, et al. Experimental [Page 32] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[32ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
すべてのシングルには、仕事を記録してください。 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' or 'pending-held' state. Later, the Printer object begins processing the print job. At this point in time, 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オブジェクトの初期状態は'未定'の、または、'未定に保持された'状態です。 その後、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.2.1.2 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.2を見てください。.1 .2 詳細のために。 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 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:
ジョブ依頼時に、これらの追加ジョブ処理時間合法化チェックは本質的には役に立ちません、それらを実際にドキュメントデータを分析して、解釈するのが必要であり、100%正確になるように保証されないで、再びまだ終わらなければならないので、ジョブ処理時に。 また、ジョブ依頼時に有用性がないかどうかURIの場合でチェックするのはジョブ処理時に有用性を保証しません。 Printerオブジェクトがジョブ処理時にそうするかもしれない追加では、以下のジョブ依頼時に検出可能でなかった条件のどれかを発見してください:
- runtime errors in the document data,
- nested document data that is in an unsupported format,
- ドキュメントデータにおけるランタイム・エラー--サポートされない形式にはある入れ子にされたドキュメントデータ
deBry, et al. Experimental [Page 33] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[33ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
- 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 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-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 IPP/1.0.
以下に注意してください。 IPP/1.0の範囲の外にイベントの非同期な通知があります。
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.23 and 4.3.24.
自然言語と文字コード: セクション3.1.4で.1に説明される「属性-charset」と「属性自然言語」属性 Printerオブジェクトはセクション4.3.23と4.3で.24に説明された対応する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)操作属性。
deBry, et al. Experimental [Page 34] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[34ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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を見てください)。
"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.0 does not
support the concept of document level attributes.
「ドキュメント名」(名前(最大)): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それはクライアントの供給されたドキュメント名を含んでいます。 ドキュメント名はJob名と異なっているかもしれません。 通常、クライアントソフトウェアは、エンドユーザを代表してファイル名か名前であることが作られたアプリケーションを使用することによって、ドキュメント名前を自動的に提供します。 この属性を供給するなら、各実装によって定義された方法で値を使用できます。 例は: 印刷されて、(仕事のスタートシート、ページ装飾品など)がドキュメントとして会計かリソースの追跡管理ツールで使用したか、またはドキュメントと共に保存さえしたJobと共に、属性を平らにしてください。 IPP/1.0はドキュメントの概念に平らな属性をサポートしません。
deBry, et al. Experimental [Page 35] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[35ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
"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. 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. 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.
「ドキュメント・フォーマット」(mimeMediaType): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 この属性の値は供給されたドキュメントデータの形式を特定します。 クライアントがこの属性を供給しないなら、Printerオブジェクトは、Printerオブジェクトの「ドキュメント形式デフォルト」属性によって定義された書式にはドキュメントデータがあると仮定します。 クライアントがこの属性を供給しますが、値がPrinterオブジェクトによってサポートされないで、またすなわち、値がPrinterオブジェクトの「形式が支えたドキュメント」属性の値の1つでないなら、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オブジェクトに必要であるどんな特定の値もありません。
"compression" (type3 keyword)
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "compression-
supported" attribute (see section 4.4.29). The client supplied
"compression" operation attribute identifies the compression
algorithm used on the document data. If the client omits this
attribute, the Printer object MUST assume that the data is not
compressed. If the client supplies the attribute and the
Printer object supports the attribute, the Printer object uses
the corresponding decompression algorithm on the document data.
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 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.
クライアントOPTIONALLYがこの属性を供給する「圧縮。」(type3キーワード) PrinterオブジェクトOPTIONALLYはこの属性と「サポートされた圧縮」属性をサポートします(セクション4.4.29を見てください)。 クライアントの供給された「圧縮」操作属性はドキュメントデータで使用される圧縮アルゴリズムを特定します。 クライアントがこの属性を省略するなら、Printerオブジェクトは、データが圧縮されないと仮定しなければなりません。 クライアントが属性を供給して、Printerオブジェクトが属性をサポートするなら、Printerオブジェクトはドキュメントデータで対応する減圧アルゴリズムを使用します。 または、Printerオブジェクトがクライアントがこの属性を供給しますが、値がPrinterオブジェクトによってサポートされないで、またすなわち、値がPrinterオブジェクトの「圧縮でサポートしている」属性の値の1つでないなら、Unsupported Attributes応答グループに属性とその値をコピーして、要求を拒絶して、'クライアント誤り属性を返さなければならない、-、-、値でサポートしていない'ステータスコード。
"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.30). 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 for the complete semantics). If the client supplies the
クライアントOPTIONALLYがこの属性を供給する「仕事のk八重奏。」(整数(0: MAX)) PrinterオブジェクトOPTIONALLYはこの属性と「仕事k八重奏でサポートされた」属性をサポートします(セクション4.4.30を見てください)。 クライアントの供給された「仕事のk八重奏」操作属性は提出されるK八重奏における、ドキュメントの総サイズを特定します(完全な意味論に関してセクション4.3.17を見てください)。 クライアント供給です。
deBry, et al. Experimental [Page 36] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[36ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
属性とPrinterオブジェクトは属性をサポートして、属性の値は、Jobオブジェクトの「仕事のk八重奏」Job記述属性に居住するのに使用されます。
Note: 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オブジェクト属性に居住するのを選ぶかもしれなくて、計算するか、または裁量できます。
"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.31). 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.18 for the complete semantics).
クライアントOPTIONALLYがこの属性を供給するという「仕事印象。」(整数(0: MAX)) そして、PrinterオブジェクトOPTIONALLYがこの属性をサポートする、「仕事は」 属性を印象でサポートしました(セクション4.4.31を見てください)。 クライアントは操作属性が提出されるドキュメントの印象の数における総サイズを特定するという(完全な意味論に関してセクション4.3.18を見てください)「仕事印象」を供給しました。
See note 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.32). 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.19 for the complete semantics).
クライアントOPTIONALLYがこの属性を供給する「仕事のメディアシート。」(整数(0: MAX)) PrinterオブジェクトOPTIONALLYはこの属性と「シートで仕事メディアによってサポートしている」属性をサポートします(セクション4.4.32を見てください)。 クライアントの供給された「仕事のメディアシート」操作属性は、この仕事のために生産されるためにメディアシートの総数を特定します(完全な意味論に関してセクション4.3.19を見てください)。
See note under "job-k-octets".
「仕事のk八重奏」で注意を見てください。
deBry, et al. Experimental [Page 37] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[37ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
クライアントは、処理されるためにドキュメントデータを提供しなければなりません。
Note: 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
- 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.
- 自然言語の「ジョブ名」属性における発生しているJob名を保存して、charsetに要求されていて、新しいJobオブジェクト(Jobオブジェクトはただ一つのドキュメントを含んでいる)を作成する、(見る、セクション3.1 .4 .1) (そうでなければ、Printerオブジェクトのデフォルトの自然言語とcharsetを使用して、ものがサポートされるなら); そして、--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) operation attribute as described in sections 14 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はセクション14と3.1.6で説明されるように「ステータスメッセージ」(テキスト)操作属性を含んでいます。 クライアントがサポートされないか闘争しているJob Templateに属性か値を供給するなら、Printerオブジェクトは、「ipp信義を結果と考えている」操作属性のためにクライアントが'本当さ'を供給したか、そして、'誤り'値に依存するPrint-仕事の要求を、拒絶しなければならないか、または受け入れなければなりません。 aを処理するための提案されたステップの完全な記述のためのImplementerのガイド[ipp-iig]が要求を作成するのを見てください。
deBry, et al. Experimental [Page 38] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[38ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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: サポートされない属性
This is a set of Operation and Job Template attributes supplied
by the client (in the request) that are not supported by the
Printer object or that conflict with one another (see the
Implementer's Guide [ipp-iig]). 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オブジェクトかお互いとのその闘争でサポートされないクライアント(要求における)によって供給された1セットのOperationとJob Template属性(Implementerのガイド[ipp-iig]を見る)です。 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).
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).
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.
1. Printerオブジェクトは供給された属性をサポートしません(属性構文か値が何であっても)。 2. Printerオブジェクトは、属性をサポートしますが、クライアントによって供給された特定の属性構文か値のいくつかかすべてはサポートしません(すなわち、Printerオブジェクトには、対応する「xxxによってサポートしている」属性におけるそれらの属性構文か値がありません)。 3. Printerオブジェクトは供給された属性と値をサポートしますが、特定の値はお互いとの闘争中です、規制に違反するので、透明をとめることができないのなどように。
In the case of an unsupported attribute name, the Printer object
returns the client-supplied attribute with a substituted "out-
of-band" value of 'unsupported' indicating no support for the
attribute itself (see the beginning of section 4.1).
サポートされない属性名の場合では、Printerオブジェクトは'サポートされない'表示「バンド」の代入された値があるクライアントによって供給された属性に属性自体のサポートを全く返しません(セクション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 MUST return only those attribute
syntaxes or values that are unsupported.
1つ以上のサポートされない属性構文か値があるサポートしている属性の場合では、クライアントによって供給されるようにPrinterオブジェクトは単にサポートされない属性構文か値があるクライアントによって供給された属性を返します。 属性のサポートを示しますが、これはその特定の属性構文か値のどんなサポートも示しません。 クライアントがマルチ評価された属性に1つ以上の値を供給して、Printerオブジェクトが属性をサポートしますが、クライアントによって供給された属性構文か値の部分集合をサポートするだけであるなら、Printerオブジェクトはそれらのサポートされない属性構文か値だけを返さなければなりません。
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
お互いとの闘争中であることの属性値であることが支えられた2(さらに)に関するケース、(それぞれが独自にサポートされますが、一緒に要求されると、値は闘争します。
deBry, et al. Experimental [Page 39] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[39ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 it is still using. The choice
for exactly how to resolve the conflict is implementation
dependent. See The Implementer's Guide [ipp-iig] for an
example.
中、同じ仕事)、Printerオブジェクトはそれが対立を解決しますが、いくらか対立を解決するというわけではないために無視するか、または代入するそれがまだ使用している値のすべての値を返さなければなりません。 ちょうどどう対立を解決するかためには選択は実装に依存しています。 例に関してImplementerのガイド[ipp-iig]を見てください。
In these three cases, the value of the "ipp-attribute-fidelity"
supplied by the client does not affect what the Printer object
returns. 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.
これらの3つの場合では、クライアントによって供給された「ipp属性信義」の値はPrinterオブジェクトが返すものに影響しません。 「ipp属性信義」の値は、Print-仕事の操作を受け入れるか、または拒絶するかに影響するだけです。 仕事を受け入れるなら、クライアントが返されたサポートされない属性を要求するGet仕事属性操作を使用することで仕事について質問するかもしれない、応答を作成して、どの属性が無視されたか、そして、(Jobオブジェクトの上に保存されません)どの属性が他の(代入します)値で保存されたか確認してください。
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":
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.
「仕事状態」: PrinterオブジェクトはJobオブジェクトのREQUIRED「仕事の状態」属性を返さなければなりません。 時間内に(定義された実装)、Printer目的がPrint-仕事のRequestを受ける時、Printerオブジェクトが応答を返すときに時何らかの重要なポイントで新しいJobオブジェクトの「スナップ」からこの属性(次の属性「仕事の州の理由」の値に伴う)の値を取ります。
deBry, et al. Experimental [Page 40] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[40ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
"job-state-reasons":
The Printer object OPTIONALLY returns the Job object's OPTIONAL
"job-state-reasons" 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-reasons" attribute is not supported
and will not be returned in a subsequent Job object query.
「仕事の状態は推論します」: PrinterオブジェクトOPTIONALLYはJobオブジェクトのOPTIONAL「仕事の州の理由」属性を返します。 Printerオブジェクトがこの属性をサポートするなら、応答でそれを返さなければなりません。 この属性が応答で返されないなら、クライアントは、「仕事の州の理由」属性がサポートされないで、またその後のJobオブジェクト質問で返されないと仮定できます。
"job-state-message":
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":
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
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.
「介入している仕事の数」: PrinterオブジェクトOPTIONALLYはJobオブジェクトのOPTIONAL「介入している仕事の数」属性を返します。 Printerオブジェクトがこの属性をサポートするなら、応答でそれを返さなければなりません。 この属性が応答で返されないなら、クライアントは、「介入している仕事の数」属性がサポートされないで、またその後の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" 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
クライアントがドキュメントデータ自体を含んでいるよりむしろ、「ドキュメント-uri」(uri)操作属性(Group1の)を使用することでURI参照をドキュメントデータに供給するのを除いて、このOPTIONAL操作はPrint-仕事の操作(セクション3.2.1)と同じです。 応答を返すPrinterがそれを有効にしなければならない前に、Printerは検索がURIによって含意されたメソッド(例えば、http、ftpなど)であるとサポートして、有効なURI構文がないかどうかチェックしなければなりません。 クライアントによって供給されたURI体系がサポートされないなら、すなわち、値がPrinterオブジェクトの「サポートされた参照をつけられたuri体系」属性にありません、Printer
deBry, et al. Experimental [Page 41] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[41ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
object MUST reject the request and return the 'client-error-uri- scheme-not-supported' status code. See The Implementer's Guide [ipp-iig] for suggested additional checks. The Printer NEED NOT follow the reference and validate the contents of the reference.
オブジェクトは、要求を拒絶して、'サポートされなかったクライアント誤り-uri体系'ステータスコードを返さなければなりません。 提案された追加チェックのためのImplementerのガイド[ipp-iig]を見てください。 Printerは参照に続いて、参照のコンテンツを有効にする必要はありません。
If the Printer object supports this operation, it MUST support the "reference-uri-schemes-supported" Printer attribute (see section 4.4.24).
Printerオブジェクトがこの操作をサポートするなら、それは「uri体系がサポートした参照」Printer属性をサポートしなければなりません(セクション4.4.24を見てください)。
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オブジェクトセキュリティ必要条件を満たすことができるのをチェックできるように。
Note: 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
クライアントがCreate-仕事の要求でドキュメントデータか少しの参照もドキュメントデータに供給しないのを除いて、このOPTIONAL操作はPrint-仕事の操作(セクション3.2.1)と同様です。 また、クライアントは「ドキュメント名」、「ドキュメント形式」、「圧縮」、または「ドキュメント自然言語」操作属性のいずれも供給しません。 1通以上のSend-ドキュメントかSend-URI操作はこの操作のあとに続いています。 それぞれのそれらの操作要求で
deBry, et al. Experimental [Page 42] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[42ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
client OPTIONALLY supplies the "document-name", "document-format", and "document-natural-language" attributes for each document in the multi-document Job object.
クライアントOPTIONALLYは「ドキュメント名」、「ドキュメント・フォーマット」、および「ドキュメント自然言語」属性をマルチドキュメントJobオブジェクトの各ドキュメントに供給します。
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.28).
Printerオブジェクトがこの操作をサポートするなら、それは「複数の操作タイムアウト」Printer属性をサポートしなければなりません(セクション4.4.28を見てください)。
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': all of the Job Template attributes that apply to
a Printer object (the last two columns of the table in Section
4.2).
- 'printer-description': the attributes specified in Section 4.4.
- 'all': the special group 'all' that includes all supported
attributes.
- '仕事テンプレート': Printerに適用されるJob Template属性のすべてが反対します(セクション4.2における、テーブルに関する最後の2つのコラム)。 - 'プリンタ記述': 属性はセクション4.4で指定しました。 - 'すべて': すべてを含んでいる特別なグループ'すべて'は属性をサポートしました。
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です。
deBry, et al. Experimental [Page 43] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[43ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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:
attributes-charset" and "attributes-natural-language" butes as
described in section 3.1.4.1.
自然言語と文字コード: セクション3.1.4で.1に説明される「属性-charset」と「属性自然言語」butes
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 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
「ドキュメント・フォーマット」(mimeMediaType): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 Printer目的が要求されたドキュメント・フォーマットに関連するサポートしている属性値のセットを決定するように、この属性は役に立ちます。 Printerオブジェクトは属性と仕事を有効にするそれが使用するaが作成する値かこのドキュメント・フォーマットが供給されるValidate-仕事の操作を返さなければなりません。 PrinterオブジェクトSHOULDは(1) 指定された形式のためにサポートされるそれらの属性と(2) 指定されたドキュメント・フォーマットのためにサポートされる属性値だけを返します。 ドキュメント・フォーマットを指定することによって、クライアントはPrinterオブジェクトに特定のドキュメント・フォーマットのためにサポートされない属性と値を排除させることができます。 例えば、Printerオブジェクトには、両方が'アプリケーション/追伸'(ポストスクリプトのための)と'テキスト/明瞭な'(テキストのための)ドキュメントであるとサポートする複数のインタプリタがあるかもしれません。 しかしながら、それらのインタプリタの唯一の1において、Printerオブジェクトは'1'、'2'、および'4'の値に従った「上に数」をサポートすることができるかもしれませんか? もう片方のインタプリタに関しては、それは'1'の値に従った「上に数」をサポートすることができるだけであるかもしれません。 その結果、a
deBry, et al. Experimental [Page 44] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[44ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
クライアントは属性を得るのに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:
そして、中で仕事を有効にするとき、Printerオブジェクトがそれぞれの異なったドキュメント・フォーマットのために異なったサポートしている値を見分けない、作成、Validate-仕事の操作、それはGetプリンタ属性操作における異なったドキュメント・フォーマットを見分けてはいけません。 Printerオブジェクトがクライアントによって指定されたそれぞれの異なったドキュメント・フォーマットのために異なったサポートしている値を見分けるなら、この専門化は以下のPrinterオブジェクト属性だけに適用されます:
- 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"
- そして、「八重奏がサポートした仕事k」という「オーバーライドがサポートしたpdl」という(「xxxデフォルトとしてください」という「xxxによってサポートしてい」て、セクションでTableで「xxx準備ができる」4.2)が「圧縮してサポートした」Job Template属性であるプリンタ属性、「印象がサポートした仕事--「シートがサポートした仕事のメディア」--「プリンタドライバーインストーラ」--「色で、サポートされる」、--、「参照uriはサポートされた状態で計画する」」
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).
他のすべてのPrinterオブジェクト属性(「形式が支えたドキュメント」を含んでいる)の値はクライアントの供給されたドキュメント・フォーマット(セクション6.2に従った登録されるとしての新しいPrinter記述属性を除いた)に関して不変なままで残っています。
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-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.
クライアントがこの「ドキュメント・フォーマット」操作属性を省略するなら、PrinterオブジェクトはまるでPrinterオブジェクトの「ドキュメント形式デフォルト」属性の値を属性に供給したかのように応じなければなりません。 クライアントがいつも「ドキュメント・フォーマット」に値を供給するのが、お勧めである、Printerオブジェクトの「ドキュメント形式デフォルト」が'アプリケーション/八重奏ストリーム'であるかもしれないので、その場合、返された属性と値はPrinterが自動的に感じることができるドキュメント・フォーマットの組合のためのものです。 その他の詳細に関しては、セクション4.1.9における、'mimeMediaType'属性構文の記述を見てください。
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.
クライアントが「ドキュメント・フォーマット」に値を供給するなら、すなわちPrinterがサポートされないOperation属性は「ドキュメントは形式でサポートした」オブジェクトのPrinterものの値の中では、属性、Printerオブジェクトが操作を拒絶しなければならないということでなく、リターンは'クライアント誤りドキュメント形式でサポートしていない'ステータスコードです。
deBry, et al. Experimental [Page 45] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[45ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
3.2.5.2 Get-Printer-Attributes Response
3.2.5.2 プリンタ属性を得ている応答
The Printer object returns the following sets of attributes as part of the Get-Printer-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) operation attribute as described in section 3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて、応答OPTIONALLYはセクション3.1.6で説明されるように「ステータスメッセージ」(テキスト)操作属性を含んでいます。
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: サポートされない属性
This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or
that conflict with one another (see sections 3.2.1.2 and 16).
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 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.
セクション3.2を見てください。これがPrinterオブジェクトかお互いとのその闘争でサポートされないクライアント(要求における)によって供給された1セットのOperation属性である、(.1 .2と16)。 応答はクライアントによって要求されましたが、IPPオブジェクトによってサポートされない少しの供給値(属性キーワード)がある「要求された属性」操作属性も含む必要はありません。 Printerオブジェクトが応答で少しのUnsupported Attributesも返していないなら、PrinterオブジェクトSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、クライアントは空のグループを受け入れることができなければなりません。
Group 3: Printer Object Attributes
グループ3: プリンタオブジェクト属性
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.
これは要求された属性とそれらの現行価値のセットです。 Printerオブジェクトが無視する、(応じない、)、いずれもサポートされない属性を要求しました。 Printerオブジェクトはサポートしている属性と値の部分集合で応じるかもしれません、大挙して安全保障政策によって。 しかしながら、PrinterオブジェクトはPrinter目的が値を知らないどんなサポートしている属性(すべてのREQUIRED属性を含んでいる)のためにも'未知'の値で応じなければなりません。 また、Printerオブジェクトはシステム管理者が値を構成していないどんなサポートしている属性(すべてのREQUIRED属性を含んでいる)のためにも'値がありません'で応じなければなりません。 初めに「バンドの外」というセクション4.1の値の記述を見てください。
deBry, et al. Experimental [Page 46] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[46ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
3.2.6 Get-Jobs Operation
3.2.6 ジョブスを得ている操作
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.
このREQUIRED操作で、クライアントは目標Printerオブジェクトに属すJobオブジェクトのリストを検索できます。 また、クライアントはJob属性名、そして/または、属性グループ名のリストを提供するかもしれません。 返されるそれぞれのJobオブジェクトのためにJobオブジェクト属性のグループを返すでしょう。
This operation is similar to the Get-Job-Attributes operation, except that this Get-Jobs operation returns attributes from possibly more than one object (see the description of Job attribute group names in section 3.3.4).
この操作はGet仕事の属性操作と同様です、このGet-ジョブス操作がことによると1個以上のオブジェクトから属性を返すのを除いて(セクション3.3.4における、Job属性グループ名の記述を見てください)。
3.2.6.1 Get-Jobs Request
3.2.6.1 ジョブスを得ている要求
The client submits the Get-Jobs request to a Printer object.
クライアントはGet-ジョブス要求をPrinterオブジェクトに提出します。
The following groups of attributes are part of the Get-Jobs 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でクライアントによって供給されてください。
"limit" (integer(1:MAX)):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It is an integer value that
indicates a limit to the number of Job objects 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.
「限界」(整数(1: 最大)): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それはJobオブジェクトの数への限界が戻ったのを示す整数値です。 ''クライアントによって供給された値が限界であるなら、限界はそれの「状態がない限界」です、そして、次に、Get-ジョブスResponseで'1番目と仕事だけを返します。 '次々と'1番目と次の'M'仕事を考慮するために、メカニズムは全くありません。 クライアントがこの属性を供給しないなら、Printerオブジェクトはすべての適切な仕事で応じます。
"requested-attributes" (1setOf 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
「要求された属性」(1setOfキーワード): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それは1セットのJob属性名です、そして、属性は値で名前を分類します。
deBry, et al. Experimental [Page 47] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[47ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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'.
リクエスタは興味を持っています。 このセットの属性は返されるそれぞれのJobオブジェクトのために返されます。 許容属性グループ名はGet-仕事で属性操作をセクション3.3.4で定義しているそれらと同じです。 クライアントがこの属性を供給しないなら、まるでクライアントが2つの値をこの属性に供給したかのようにPrinterは応じなければなりません: '仕事-uri'と'仕事イド'。
"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:
「どれ、-、仕事、」 (type2キーワード): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それは、PrinterオブジェクトでどのJobオブジェクトを返さなければならないかを示します。 この属性のための値は以下の通りです。
'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'.
'完成する': これは状態が'完成される'か、'取り消される'か、または'中止される'どんなJobオブジェクトも含んでいます。 '完成しない': または、これが状態が'未定で'、'処理'で、'処理で止まられる'どんなJobオブジェクトも含んでいる、'、未定である、成立、'
A Printer object MUST support both values. However, if the
mentation does not keep jobs in the 'completed', 'canceled', '
aborted' states, then it returns no jobs when the 'completed'
value is supplied.
Printerオブジェクトは両方の値をサポートしなければなりません。 しかしながら、精神作用が'完成し'て、'取り消され'て、'中止になっている'州に仕事を保たないなら、'完成した'値を供給するとき、それは仕事を全く返しません。
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.
クライアントがある他の値を供給するなら、Printerオブジェクトは、Unsupported Attributes応答グループに属性とサポートされない値をコピーして、要求を拒絶して、'属性か値がサポートしなかったクライアント誤り'ステータスコードを返さなければなりません。
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'.
クライアントがこの属性を供給しないなら、まるでクライアントが'完成しない'値を属性に供給したかのようにPrinterオブジェクトは応じなければなりません。
"my-jobs" (boolean):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. It indicates whether all
jobs or just the jobs submitted by the requesting user of this
request MUST 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., all jobs. The means for authenticating the
requesting user and matching the jobs is described in section 8.
「私、-、仕事、」 (論理演算子): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 それは、Printerオブジェクトですべての仕事かまさしくこの要求の要求しているユーザによって提出された仕事を返さなければならないかどうかを示します。 クライアントがこの属性を供給しないなら、まるでクライアントが'誤ること'の値(すなわちすべての仕事)と共に属性を供給したかのようにPrinterオブジェクトは応じなければなりません。 要求しているユーザを認証して、仕事に合うための手段はセクション8で説明されます。
deBry, et al. Experimental [Page 48] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[48ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
3.2.6.2 Get-Jobs Response
3.2.6.2 ジョブスを得ている応答
The Printer object returns all of the Job objects 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.
Printerオブジェクトは要求でクライアントによって供給された属性値によって定義されるように評価基準に合っているJobオブジェクトのすべてを返します。 Jobオブジェクトが全くPrinterに文字通りないかもしれないのでJobオブジェクトを全く返さないのが可能であるか、またはクライアントによって供給された評価基準に合っているJobオブジェクトが全くないかもしれません。 クライアントが何か全くJob属性を要求するなら、それぞれのJobオブジェクトのために返されたJob Object Attributesの1セットがあります。
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) operation attribute as described in sections 14 and
3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて、応答OPTIONALLYはセクション14と3.1.6で説明されるように「ステータスメッセージ」(テキスト)操作属性を含んでいます。
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: サポートされない属性
This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or
that conflict with one another (see sections 3.2.1.2 and the
Implementer's Guide [ipp-iig]). 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
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.
セクション3.2を見てください。これがPrinterオブジェクトかお互いとのその闘争でサポートされないクライアント(要求における)によって供給された1セットのOperation属性である、(.1 .2とImplementerのガイド[ipp-iig。) 応答はクライアントによって要求されましたが、IPPオブジェクトによってサポートされない少しの供給値(属性キーワード)がある「要求された属性」操作属性も含む必要はありません。 Printerオブジェクトが応答で少しのUnsupported Attributesも返していないなら、PrinterオブジェクトSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、クライアントは空のグループを受け入れることができなければなりません。
Groups 3 to N: Job Object Attributes
グループ3〜N: 仕事のオブジェクト属性
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
Printerオブジェクトはそれぞれの返されたJobオブジェクトのためにJob Object Attributesの1セットで応じます。 Printerオブジェクトが無視する、(応じない、)、いずれもサポートされないか、または安全保障政策によって大挙して制限される属性か値を要求しました、要求しているユーザが仕事(賃仕事の起因しているユーザ)を提出したユーザであるかどうかを含んでいて(セクション8を見てください)。 しかしながら、PrinterオブジェクトはPrinter目的が知らないどんなサポートしている属性(すべてのREQUIRED属性を含んでいる)のためにも'未知'の値で応じなければなりません。
deBry, et al. Experimental [Page 49] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[49ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
値安全保障政策に違反しないなら。 初めに「バンドの外」というセクション4.1の値の記述を見てください。
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).
- クライアント要求がすべて、ジョブス('完成した'か、'中止になった'か、'取り消された'州のジョブス)を'完成した'なら、最も古さに(実際の完成時間に関する)最も新しい状態でジョブスを返します--クライアントが、すべてが'完成しなかった'よう要求するなら、完成する(Printerオブジェクトのために構成されるどんなスケジューリングアルゴリズムにも基づいています)予想された時間の相対的な年代順にジョブス('未定で'、'処理'で、'未定に保持にされる'、および'処理は止まった'という州のジョブス)、当時のジョブスを返します。
3.3 Job Operations
3.3 仕事の操作
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.
JobオブジェクトはすべてのJob操作に向けられます。 クライアントはいつも操作の正しい目標を特定するためにJobオブジェクトを特定するいくつかの手段を供給しなければなりません。 その職務識別は、Job IDへのただ一つのJob URIかPrinter URIの組み合わせのどちらかであるかもしれません。 IPPオブジェクト実装はあらゆる仕事のための両方の形式の識別をサポートしなければなりません。
3.3.1 Send-Document Operation
3.3.1 ドキュメントを発信させている操作
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.
このOPTIONAL操作で、クライアントは初めは「空」の(ドキュメントを全く含んでいません)マルチドキュメントJobオブジェクトを作成できます。 Create-仕事の応答では、PrinterオブジェクトはJobオブジェクトのURI(「仕事-uri」属性)とJobオブジェクトの32ビットの識別子(「仕事イド」属性)を返します。 クライアントが加えることを望んでいるそれぞれの新しいドキュメントのために、クライアントはSend-ドキュメント操作を使用します。 それぞれのSendドキュメントRequestはデータが個人的には記録するドキュメントの全体のストリームを含んでいます。
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 multiple document jobs, the Printer object MUST support the "multiple-operation-time-out" attribute (see section 4.4.28). This attribute indicates the minimum number of seconds the Printer object will wait for the next send operation before taking some recovery action.
操作(ドキュメントを発信させるか、Send URI操作)を送ってください。そして、Create-仕事、尾行が特定の仕事のための時間の任意に長い期間にわたって起こることができて、クライアントが別のものを送らなければならないのが仕事を求める前の要求の領収書の後の間隔に最小の時間定義されたIPP Printerの中で操作を送ります。 Printerオブジェクトが、複数のドキュメントが仕事であるとサポートするなら、Printerオブジェクトは「複数の操作タイムアウト」属性をサポートしなければなりません(セクション4.4.28を見てください)。 この属性は、何らかの回復行動を取る前に待っているPrinterが次を反対させる秒の最小の数が操作を送るのを示します。
deBry, et al. Experimental [Page 50] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[50ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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), if supported, 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), if supported.
This action allows the user or an operator to determine whether
to continue processing the Job by moving it back to the '
pending' state or to cancel the job.
1. Jobが無効の仕事であると仮定してください、そして、'中止になっ'て、サポートされるなら仕事の「仕事の州の理由」属性(セクション4.3.8を見る)に'システムによって中止されて'価値を高めて、Jobに関連しているすべてのリソースをきれいにするために仕事の状態を変えるプロセスを始めてください。 操作を送ってください。別のものが発信するならこの場合最終的に操作を受けて、Printerが「クライアント誤り可能でない」かいつの周りでJobオブジェクトがスチール写真であるかどうかによる「誤りが当たらなかったクライアント」と共に応じる、最終的に、到着します。 2. 事実上、最終が受けられた操作を送るのが、最後のドキュメント(まるで「最後のドキュメント」旗が'本当に'設定されたかのように)であり、Jobが近くでは、反対して、それを処理しかける(すなわち、Jobの状態を'未定に'動かす)と仮定してください。 3. 事実上、最終が受けられた操作を送るのが、最後のドキュメントでしたが、Jobを閉じますが、それを'未定に保持'に動かすように仮定してください、そして、仕事の「仕事の州理由」属性に'服従で中断している'価値を高めてください(セクション4.3.8を見てください)、サポートされるなら。 この動作で、ユーザかオペレータが、'未定'の状態にそれを戻らせることによってJobを処理し続けているかどうかと決心しているか、または仕事を中止します。
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オブジェクトが既にいくつかのメディアシートページが印刷されたというポイントに処理されたのは、可能です。
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」と「属性自然言語」属性
deBry, et al. Experimental [Page 51] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[51ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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:
"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における、「ドキュメント名」操作属性の記述を見てください、(これに関する詳しい情報のための.1が)結果と考えるセクション3.2.1
"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. 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. 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.
「ドキュメント・フォーマット」(mimeMediaType): クライアントOPTIONALLYはこの属性を供給します。 Printerオブジェクトはこの属性をサポートしなければなりません。 この属性の値は供給されたドキュメントデータの形式を特定します。 クライアントがこの属性を供給しないなら、Printerオブジェクトは、Printerオブジェクトの「ドキュメント形式デフォルト」属性によって定義された書式にはドキュメントデータがあると仮定します。 クライアントがこの属性を供給しますが、値がPrinterオブジェクトによってサポートされないで、またすなわち、値がPrinterオブジェクトの「形式が支えたドキュメント」属性の値の1つでないなら、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オブジェクトに必要であるどんな特定の値もありません。
"compression" (type3 keyword)
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "compression-
supported" attribute (see section 4.4.29). The client supplied
クライアントOPTIONALLYがこの属性を供給する「圧縮。」(type3キーワード) PrinterオブジェクトOPTIONALLYはこの属性と「サポートされた圧縮」属性をサポートします(セクション4.4.29を見てください)。 供給されたクライアント
deBry, et al. Experimental [Page 52] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[52ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
"compression" operation attribute identifies the compression
algorithm used on the document data. If the client omits this
attribute, the Printer object MUST assume that the data is not
compressed. If the client supplies the attribute and the
Printer object supports the attribute, the Printer object MUST
use the corresponding decompression algorithm on the document
data. 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 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.
「圧縮」操作属性はドキュメントデータで使用される圧縮アルゴリズムを特定します。 クライアントがこの属性を省略するなら、Printerオブジェクトは、データが圧縮されないと仮定しなければなりません。 クライアントが属性を供給して、Printerオブジェクトが属性をサポートするなら、Printerオブジェクトはドキュメントデータで対応する減圧アルゴリズムを使用しなければなりません。 または、Printerオブジェクトがクライアントがこの属性を供給しますが、値がPrinterオブジェクトによってサポートされないで、またすなわち、値がPrinterオブジェクトの「圧縮でサポートしている」属性の値の1つでないなら、Unsupported Attributes応答グループに属性とその値をコピーして、要求を拒絶して、'クライアント誤り属性を返さなければならない、-、-、値でサポートしていない'ステータスコード。
"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.
「最後のドキュメント」旗が'誤っていること'に設定されるなら、クライアントはドキュメントデータを提供しなければなりません。 しかしながら、クライアントが、Send-ドキュメント(または、Send URI)操作と共に送られた前のドキュメントが最後のドキュメントであったのを知らないかもしれないので(すなわち、「最後のドキュメント」属性は'誤っていること'に設定されました)、'本当に'「最後のドキュメント」旗が設定されるドキュメントデータのないSend資料請求を送るのは法的です。 そのような要求はJobオブジェクトの「ドキュメントの数」属性の値を増加してはいけません、どんな本当のドキュメントも仕事に加えられなかったので。
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) operation attribute as described in sections 14 and
3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて、応答OPTIONALLYはセクション14と3.1.6で説明されるように「ステータスメッセージ」(テキスト)操作属性を含んでいます。
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」と「属性自然言語」属性
deBry, et al. Experimental [Page 53] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[53ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Group 2: Unsupported Attributes
グループ2: サポートされない属性
This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or
that conflict with one another (see sections 3.2.1.2 and the
Implementer's Guide [ipp-iig]). 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.
セクション3.2を見てください。これがPrinterオブジェクトかお互いとのその闘争でサポートされないクライアント(要求における)によって供給された1セットのOperation属性である、(.1 .2とImplementerのガイド[ipp-iig。) Printerオブジェクトが応答で少しのUnsupported Attributesも返していないなら、PrinterオブジェクトSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、クライアントは空のグループを受け入れることができなければなりません。
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)。
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.
応答を返す前にPrinterオブジェクトは供給されたURIの構文とURI体系を有効にしなければなりません、ちょうどPrint-URI操作のように。
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が既に印刷しているかもしれないので、仕事が実際に終えられる前に、いくつかのメディアシートページが印刷されるかもしれません。
3.3.3.1 Cancel-Job Request
3.3.3.1 キャンセル仕事の要求
The following groups of attributes are part of the Cancel-Job Request:
属性の以下のグループはキャンセル仕事のRequestの一部です:
deBry, et al. Experimental [Page 54] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[54ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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でクライアントによって供給されてください。
"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) operation attribute as described in sections 14 and
3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて、応答OPTIONALLYはセクション14と3.1.6で説明されるように「ステータスメッセージ」(テキスト)操作属性を含んでいます。
If the job is already in the 'completed', 'aborted', or '
canceled' state, or the 'process-to-stop-point' value is set in
the Job's "job-state-reasons" attribute, the Printer object MUST
reject the request and return the 'client-error-not-possible'
error status code.
仕事が'完成した'か、'中止になった'か、'取り消された'状態に既にあるか、または'プロセスから停止ポイント'値がJobの「仕事の州の理由」属性で設定されるなら、Printerオブジェクトは、要求を拒絶して、'可能でないクライアント誤り'誤りステータスコードを返さなければなりません。
deBry, et al. Experimental [Page 55] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[55ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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: サポートされない属性
This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or
that conflict with one another (see section 3.2.1.2 and the
Implementer's Guide [ipp-iig]). 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.
セクション3.2を見てください。これがPrinterオブジェクトかお互いとのその闘争でサポートされないクライアント(要求における)によって供給された1セットのOperation属性である、(.1 .2とImplementerのガイド[ipp-iig。) Printerオブジェクトが応答で少しのUnsupported Attributesも返していないなら、PrinterオブジェクトSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、クライアントは空のグループを受け入れることができなければなりません。
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' 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が結局'取り消された'状態で終わるのを保証します。 受け入れられて、仕事に入るとき、キャンセル仕事の操作の時間の間に、'取り消された'仕事状態(セクション4.3.7を見る)、属性SHOULDが'処理からポイントを止めている'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': all of the Job Template attributes that apply to a
Job object (the first column of the table in Section 4.2).
- 'job-description': all of the Job Description attributes specified
in Section 4.3.
- 'all': the special group 'all' that includes all supported
attributes.
- '仕事テンプレート': Jobに適用されるJob Template属性のすべてが反対します(セクション4.2における、テーブルの最初のコラム)。 - '職務記述書': Job記述属性のすべてがセクション4.3で指定しました。 - 'すべて': すべてを含んでいる特別なグループ'すべて'は属性をサポートしました。
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
特定の属性であり、グループと命名されて、ある可能性があるというクライアント5月の要求以来、或るものは重なります。 例えば、クライアントが、'ジョブ名'と'職務記述書'よう要求するなら、クライアントは実際に「ジョブ名」属性を明らかに、そして、'職務記述書'グループでの包含による一度それを命名するのによる一度要求しています。 そのような場合で
deBry, et al. Experimental [Page 56] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[56ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
それが複数の回要求されても、プリンタオブジェクトは応答で属性を一度だけ返す必要はありません。 クライアント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 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の一部です:
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の一部として以下のセットの属性を返します:
deBry, et al. Experimental [Page 57] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[57ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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) operation attribute as described in sections 14 and
3.1.6.
ステータスメッセージ: あらゆる応答で返されたREQUIREDステータスコードに加えて、応答OPTIONALLYはセクション14と3.1.6で説明されるように「ステータスメッセージ」(テキスト)操作属性を含んでいます。
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: サポートされない属性
This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or
that conflict with one another (see sections 3.2.1.2 and the
Implementer's Guide [ipp-iig]). 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
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.
セクション3.2を見てください。これがPrinterオブジェクトかお互いとのその闘争でサポートされないクライアント(要求における)によって供給された1セットのOperation属性である、(.1 .2とImplementerのガイド[ipp-iig。) 応答はクライアントによって要求されましたが、IPPオブジェクトによってサポートされない少しの供給値(属性キーワード)がある「要求された属性」操作属性も含む必要はありません。 Printerオブジェクトが応答で少しのUnsupported Attributesも返していないなら、PrinterオブジェクトSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、クライアントは空のグループを受け入れることができなければなりません。
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 RED butes) for which the IPP object
does not know the value, s it would violate the security policy.
See the description e "out-of-band" values in the beginning of
Section 4.1.
これは要求された属性とそれらの現行価値のセットです。 IPPオブジェクトが無視する、(応じない、)、いずれもサポートされないか、または安全保障政策によって大挙して制限される属性か値を要求しました、要求しているユーザが仕事(賃仕事の起因しているユーザ)を提出したユーザであるかどうかを含んでいて(セクション8を見てください)。 しかしながら、IPPオブジェクトはIPP目的が値を知らないどんなサポートしている属性(すべてのRED butesを含んでいる)のためにも'未知'の値で応じなければなりません、s。それは安全保障政策に違反するでしょう。 「バンドの外」がセクション4.1の始めに評価する記述eを見てください。
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 specifications:
このセクションはそれらの対応する属性構文とIPPモデルの一部である値で属性について説明します。 下のセクションは、どれがこのプロトコルの範囲の中に含まれているかをオブジェクトとそれらの関連属性に示します。 他の関連仕様からこれらの属性の多くを得ます:
deBry, et al. Experimental [Page 58] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[58ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
- 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 request) MAY be one of the "out-of-band" values. Standard "out-of-band" values are:
属性構文は以下の小区分で指定されます、小区分見出しがシングル・クォーテション・マークにおける属性構文のキーワード名であるところで。 操作要求と応答では、属性構文の1つが小区分見出しで指定したように属性のために各属性値を表さなければなりません。 さらに、応答(しかし、どんな要求でも、そうしない)における、属性の値は「バンドの外」という値の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 system administrator has not yet configured a value.
'未知': 属性はIPPオブジェクトによってサポートされますが、IPPオブジェクトにおいて、値はある理由で未知です。 'サポートされない': 属性はIPPオブジェクトでサポートされないです。 単にUnsupported Attributes Groupの属性の値としてこの値を返さなければなりません。 '値がありません': 属性はPrinterオブジェクトによってサポートされますが、システム管理者はまだ値を構成していません。
The Encoding and Transport specification [RFC2565] defines mechanisms for passing "out-of-band" values. 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. All attribute 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.
EncodingとTransport仕様[RFC2565]は、「バンドの外」という値を通過するためにメカニズムを定義します。 要求におけるすべての属性に、1つ以上の値がセクション4.2〜4.4で定義されるようになければなりません。 したがって、クライアントは「バンドの外」がある属性値を供給してはいけません。 応答におけるすべての属性に、セクション4.2〜4.4で定義される1つ以上の値か「バンドの外」というただ一つの値がなければなりません。
deBry, et al. Experimental [Page 59] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[59ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 specification, 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 specification using the 'text' attribute syntax, all IPP objects and clients MUST support both the 'textWithoutLanguage' and ' textWithLanguage' attribute syntaxes. However, in actual usage and protocol execution, objects and clients accept and return only one of the two syntax per attribute. The syntax 'text' never appears "on- the-wire".
この仕様では、すべてのテキスト属性が、'テキスト'構文を使用することで定義されます。 しかしながら、'テキスト'は簡潔さにだけ使用されます。 'テキスト'の正式な解釈は以下の通りです。 'textWithoutLanguage'| 'textWithLanguage'。 すなわち、この仕様に基づき'テキスト'属性構文を使用することで定義されたどんな属性のためにも、すべてのIPPオブジェクトとクライアントは、両方が'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.24, 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
'textWithoutLanguage'と'textWithLanguage'の両方が、本当の世界が人間のコミュニケーションの基礎として異なった自然言語を使用するサイトとシステムの間の相互運用性の必要性であるとサポートするのに必要です。 一般に、1つの自然言語が与えられた要求か応答におけるすべてのテキスト属性に適用されます。 言語はセクション4.3.24で定義されたセクション3.1.4か「属性自然言語」仕事の属性で定義された「属性自然言語」操作属性によって示されます、そして、値ごとのベースの各テキスト文字列のために自然言語を特定する必要は全くありません。 これらの場合では、属性構文'textWithoutLanguage'はテキスト属性に使用されます。 または他のケース、供給するクライアント必要である。
deBry, et al. Experimental [Page 60] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[60ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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).
プリンタオブジェクトは、要求か応答における、テキスト値の残りと異なった自然言語のテキスト値を返す必要があります。 これらの場合では、クライアントか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. 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 specification of the 'charset' attribute syntax, including restricted semantics and examples of charsets.
'textWithoutLanguage'構文はゼロの系列か、より多くのキャラクタである値を示します。 テキスト文字列は、いくらかの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 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 attribute, but the 'naturalLanguage' part is always limited to 63 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.
'textWithLanguage'属性構文は2つの部品から成る複合属性構文です: 'textWithoutLanguage'部分と大挙して自然言語をくつがえす追加'naturalLanguage'(セクション4.1.8を見る)部分。 'naturalLanguage'部分は明らかに単独でその値とその価値のテキスト一部分に適用される自然言語を特定します。 いずれもテキスト属性を与えますが、'textWithoutLanguage'部分がその属性のために定義された最大の長さに制限されますが、'naturalLanguage'部分がいつも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
aでは、要求を作成してください、とPrinterオブジェクトは受け入れなければなりません、そして、Jobオブジェクトで「属性当然の言語」の操作属性におけるあらゆる自然言語を保存してください、Printerオブジェクトがその自然言語をサポートするか否かに関係なく。 その上、Printerオブジェクトは、どんな'textWithLanguage'属性値も受け入れて、保存しなければなりません。
deBry, et al. Experimental [Page 61] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[61ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
プリンタオブジェクトはその自然言語をサポートします。 これらの要件はクライアントが供給するかもしれない「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 [RFC2565] for a detailed example of the 'textWithLanguage' attribute syntax.
'textWithLanguage'属性構文の詳細な例に関してEncodingとTransportドキュメント[RFC2565]を見てください。
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 protocol execution, objects and clients accept and return only one of the two syntax per attribute. The syntax 'name' never appears "on- the-wire".
'テキスト'のようにも、'名前'は本当に'nameWithoutLanguage'か'nameWithLanguage'のどちらかのための省略表記法です。 すなわちすべてのIPPオブジェクトとクライアントは、両方が'nameWithoutLanguage'と'nameWithLanguage'属性構文であるとサポートしなければなりません。 しかしながら、実際の用法とプロトコル実行では、オブジェクトとクライアントは、1属性あたりの2構文の1つだけを受け入れて、返します。 構文'名前'が決して現れない、「オンである、-配線してください、」
Note: 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 so that its encoded form does not exceed MAX octets.
'nameWithoutLanguage'構文がゼロの系列か、より多くのキャラクタである値を示すので、コード化されたフォームはMAX八重奏を超えていません。
deBry, et al. Experimental [Page 62] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[62ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 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.
'nameWithLanguage'属性構文は2つの部品から成る複合属性構文です: 'nameWithoutLanguage'部分と大挙して自然言語をくつがえす追加'naturalLanguage'(セクション4.1.8を見る)部分。 'naturalLanguage'部分は明らかに単独でその名前値とその名前値に適用される自然言語を特定します。
The 'nameWithLanguage' attribute syntax behaves the same as the ' textWithLanguage' syntax. If a name is in a language that is different than the rest of the object or operation, then this ' nameWithLanguage' syntax is used rather than the generic ' nameWithoutLanguage' syntax.
'nameWithLanguage'属性構文は'textWithLanguage'構文として同じように振る舞います。 オブジェクトか操作の残りと異なった言語に名前があるなら、この'nameWithLanguage'構文はジェネリック'nameWithoutLanguage'構文よりむしろ使用されます。
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名
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. 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'.
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
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
deBry, et al. Experimental [Page 63] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 63] RFC 2566 IPP/1.0: Model and Semantics April 1999
matches neither 'fr' nor 'e'.
matches neither 'fr' nor 'e'.
4.1.3 'keyword'
4.1.3 'keyword'
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.
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.
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.
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.
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.
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.
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:
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:
"job-name"
"attributes-charset"
"job-name" "attributes-charset"
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).
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).
deBry, et al. Experimental [Page 64] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 64] RFC 2566 IPP/1.0: Model and Semantics April 1999
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 specification are also used for corresponding attributes in other standards [RFC1759]. This syntax type is not used for attributes to which the system administrator may assign values. Section 6.1 describes how the protocol can be extended with new enum values.
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 specification are also used for corresponding attributes in other standards [RFC1759]. This syntax type is not used for attributes to which the system administrator may assign values. Section 6.1 describes how the protocol can be extended with new enum values.
Enum values are for use in the protocol. A user interface will provide a mapping between protocol enum values and displayable user- friendly words and phrases 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 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.
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'.
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'.
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).
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).
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].
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].
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
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
deBry, et al. Experimental [Page 65] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 65] RFC 2566 IPP/1.0: Model and Semantics April 1999
all lower case values in IPP attributes to simplify comparing by IPP clients and Printer objects. Standard values for this syntax type are the following keywords:
all lower case values in IPP attributes to simplify comparing by IPP clients and Printer objects. Standard values for this syntax type are the following keywords:
'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:...")
'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:...")
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.
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.
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, 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.
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, 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.
The maximum length of 'charset' values used to represent IPP attribute values is 63 octets.
The maximum length of 'charset' values used to represent IPP attribute values is 63 octets.
Some examples are:
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
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.
'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 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.
deBry, et al. Experimental [Page 66] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 66] RFC 2566 IPP/1.0: Model and Semantics April 1999
'iso-10646-ucs-2': ISO 10646 Universal Multiple-Octet Coded
Character Set (UCS) represented as two octets (UCS-2), with the
high order octet of each pair coming first (so-called Big Endian
integer).
'iso-10646-ucs-2': ISO 10646 Universal Multiple-Octet Coded Character Set (UCS) represented as two octets (UCS-2), with the high order octet of each pair coming first (so-called Big Endian integer).
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.
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.
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, IPP requires all lower case to simplify comparing by IPP clients and Printer objects. Examples include:
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, IPP requires all lower case to simplify comparing by IPP clients and Printer objects. Examples include:
'en': for English
'en-us': for US English
'fr': for French
'de': for German
'en': for English 'en-us': for US English 'fr': for French 'de': for German
The maximum length of 'naturalLanguage' values used to represent IPP attribute values is 63 octets.
The maximum length of 'naturalLanguage' values used to represent IPP attribute values is 63 octets.
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 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.
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 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.
Examples are:
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].
'text/plain; charset=ISO-8859-1': A plain text document in ISO
8859-1 (Latin 1) [ISO8859-1].
'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]. 'text/plain; charset=ISO-8859-1': A plain text document in ISO 8859-1 (Latin 1) [ISO8859-1].
deBry, et al. Experimental [Page 67] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 67] RFC 2566 IPP/1.0: Model and Semantics April 1999
'text/plain; charset=utf-8': A plain text document in ISO 10646
represented as UTF-8 [RFC2279]
'text/plain, charset=iso-10646-ucs-2': A plain text document in
ISO 10646 represented in two octets (UCS-2) [ISO10646-1]
'application/postscript': A PostScript document [RFC2046]
'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape
sequence embedded in the document data)
'application/octet-stream': Auto-sense - see below
'text/plain; charset=utf-8': A plain text document in ISO 10646 represented as UTF-8 [RFC2279] 'text/plain, charset=iso-10646-ucs-2': A plain text document in ISO 10646 represented in two octets (UCS-2) [ISO10646-1] 'application/postscript': A PostScript document [RFC2046] 'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape sequence embedded in the document data) 'application/octet-stream': Auto-sense - see below
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. 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:
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. 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:
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
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.
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 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.
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.
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.
The maximum length of a 'mimeMediaType' value to represent IPP attribute values is 255 octets.
The maximum length of a 'mimeMediaType' value to represent IPP attribute values is 255 octets.
deBry, et al. Experimental [Page 68] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 68] RFC 2566 IPP/1.0: Model and Semantics April 1999
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.
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.
4.1.11 'boolean'
4.1.11 'boolean'
The 'boolean' attribute syntax has only two values: 'true' and ' false'.
The 'boolean' attribute syntax has only two values: 'true' and ' false'.
4.1.12 'integer'
4.1.12 'integer'
The 'integer' attribute syntax is an integer value that is in the range from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual attribute 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.
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.
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.
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.
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.
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.
4.1.15 'resolution'
4.1.15 'resolution'
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
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
deBry, et al. Experimental [Page 69] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 69] RFC 2566 IPP/1.0: Model and Semantics April 1999
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).
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).
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 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.
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 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.
4.2 Job Template Attributes
4.2 Job Template Attributes
Job Template attributes describe job processing behavior. Support for Job Template attributes by a Printer object is OPTIONAL (see section 13.2.3 for a description of support for OPTIONAL attributes). Also, clients OPTIONALLY supply Job Template attributes in create requests.
Job Template attributes describe job processing behavior. Support for Job Template attributes by a Printer object is OPTIONAL (see section 13.2.3 for a description of support for OPTIONAL attributes). Also, clients OPTIONALLY supply Job Template attributes in create requests.
Job Template attributes conform to the following rules. For each Job Template attribute called "xxx":
Job Template attributes conform to the following rules. For each Job Template attribute called "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. 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').
deBry, et al. Experimental [Page 70] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 70] RFC 2566 IPP/1.0: Model and Semantics April 1999
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" 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.
Note: 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.
Note: 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.
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. 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.
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".
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".
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. 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).
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).
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).
deBry, et al. Experimental [Page 71] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 71] RFC 2566 IPP/1.0: Model and Semantics April 1999
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.2.1.2.
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.2.1.2.
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") shows the name and syntax for each Job Template attribute in the Printer object (the default value attribute and the 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.
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") shows the name and syntax for each Job Template attribute in the Printer object (the default value attribute and the 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.
+===================+======================+======================+
| 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)|
+-------------------+----------------------+----------------------+
+===================+======================+======================+ | 仕事の属性|プリンタ: デフォルト値| プリンタ: サポートされます。| | | 属性| 属性を評価します。| +===================+======================+======================+ | ジョブ優先順位| 仕事の優先権デフォルト|優先権がサポートした仕事| | (整数1: 100) | (整数1: 100) |(整数1: 100) | +-------------------+----------------------+----------------------+ | 仕事の保持| 仕事保持、-、-|仕事保持、-、-| | (type3キーワード| | デフォルト| サポートされます|、|、名前) | (type3キーワード| | (1setOf| | | 名前)| type3キーワード| 名前)| +-------------------+----------------------+----------------------+ | 仕事シート| 仕事のシートデフォルト|シートがサポートした仕事| | (type3キーワード| | (type3キーワード| | (1setOf| | 名前)| 名前)| type3キーワード| 名前)| +-------------------+----------------------+----------------------+ |複数のドキュメント、-|複数のドキュメント、-|複数のドキュメント、-| | 取り扱い| 取り扱いデフォルト|取り扱いで、サポートされます。| | (type2キーワード) | (type2キーワード) |(1setOf type2キーワード)| +-------------------+----------------------+----------------------+
deBry, et al. Experimental [Page 72] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[72ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
+===================+======================+======================+
| Job Attribute |Printer: Default Value| Printer: Supported |
| | Attribute | Values Attribute |
+===================+======================+======================+
| 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)) |
+-------------------+----------------------+----------------------+
| 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) |
+-------------------+----------------------+----------------------+
+===================+======================+======================+ | 仕事の属性|プリンタ: デフォルト値| プリンタ: サポートされます。| | | 属性| 属性を評価します。| +===================+======================+======================+ | コピー| コピーでデフォルトとしてください。| コピーで、サポートされます。| | (整数(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: MAX)| | | | | rangeOfInteger|、|、|、|、(1: MAX)) | +-------------------+----------------------+----------------------+ | オリエンテーション|オリエンテーションで要求される、-|オリエンテーションで要求される、-| | 要求されています。| デフォルト| サポートされます。| | (type2 enum) | (type2 enum) | (1setOf type2 enum) | +-------------------+----------------------+----------------------+ | メディア| メディアデフォルト| メディアによってサポートされます。| | (type3キーワード| | (type3キーワード| | (1setOf| | 名前)| 名前)| type3キーワード| 名前)| | | | | | | | メディア準備ができています。| | | |(1setOf| | | | type3キーワード| 名前)| +-------------------+----------------------+----------------------+ | プリンタ解決| プリンタ解決、-| プリンタ解決、-| | (解決) | デフォルト| サポートされます。| | | (解決) |(1setOf解決) | +-------------------+----------------------+----------------------+ | 印刷品質| 上質のデフォルトを印刷してください。| 印刷品質、-| | (type2 enum) | (type2 enum) | サポートされます。| | | |(1setOf type2 enum) | +-------------------+----------------------+----------------------+
deBry, et al. Experimental [Page 73] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[73ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.0, they MUST have priorities higher than 100, rather than restricting the range available to end-users.
Printerオブジェクトがこの属性をサポートするなら、それは、いつも最大限の範囲が1〜100であるとサポートしなければなりません。 管理上の制約は全く受入れられません。 このように、エンドユーザはどんなPrinterオブジェクトがある全体の範囲も完全にいつも利用できます。 特権がある仕事がIPP/1.0の外で実装されるなら、それらで、プライオリティはむしろ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 values that are evenly distributed over the range from 1 to 100 using the formula:
また、「優先権がサポートした仕事」のための構文は整数(1:100)です。 このただ一つの整数値は、優先順位の数がサポートしたのを示します。 Printerオブジェクトは、クライアントによって供給された値を取って、次々にの1〜100までの範囲で均等に公式を使用することで分配されるn整数値の最も近い整数にそれを写像しなければなりません:
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に写像するなら、などです。
deBry, et al. Experimental [Page 74] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[74ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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
'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)
'成立しないでください': 仕事の'昼間'を保持する他の理由がすぐになければ: 以下を'平等にする'1日の間 晩の'夜': 夜の'週末': 週末の'2番目のシフト': '3番目のシフト'を2番目に、移行させてください(業務の完了の後に): 3番目に移行してください。(0時過ぎ)
An administrator MUST associate allowable print times with a named time period (by means outside IPP/1.0). 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.0の外の手段による)に許容できる印刷時間を関連づけなければなりません。 管理者が期間のタイプを示す名前を選ぶよう奨励されます。 '名前'か'キーワード'属性構文を使用して、実装によって、管理者は加算値を定義するかもしれません。
If the value of this attribute specifies a time period that is in the future, the Printer MUST add the 'job-hold-until-specified' value to the job's "job-state-reasons" attribute, move the job to the ' 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 and, 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は仕事の「仕事の州の理由」属性から'指定されるまでの仕事の保持'値を移さなければなりません、そして、'未定に保持された'状態に仕事を保つ他の仕事の州の理由が全くなければ、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.
この属性は、仕事でもしあればどの仕事の始め/端壁板を印刷しなければならないかを決定します。
deBry, et al. Experimental [Page 75] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[75ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
'名前'か'キーワード'属性構文を使用して、実装によって、管理者は加算値を定義するかもしれません。
Note: 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. 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 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(*)".
仕事が2通以上のドキュメントから成る場合にだけ、この属性は関連しています。 1印刷ストリームページ以上の印象とメディアシートへの操作とプレースメントを終える属性コントロール。 また、「コピー」属性の値が1を超えていると、それは結果として生じるコピーが文書を処理するので生産されるオーダーを制御します。 この説明の目的のために、“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(*), ..., and the Printer object MUST force each
copy (a(*),b(*)) to 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
'ただ一つのドキュメント': Jobオブジェクトに複数のドキュメントがあるなら、たとえば、ドキュメントデータはaとbと呼ばれます、次に、すべてのドキュメントデータ(aと次に、b)を処理するという結果を操作を終えるためのメディアシートのただ一つの系列として扱わなければなりません。 すなわち、仕上げは系列(*)、b(*)の連結に実行されるでしょう。 Printerオブジェクトは、それぞれのドキュメントインスタンスにおけるデータが新しい印刷ストリームページにフォーマットされて、新たな印象をニューメディアシートに始めるのを強制してはいけません。 処理からのメディアシートのセットの注文が結果として生じて、コピー1部をする以上なら、ドキュメントデータは(*)であるに違いありません、b(*)、(*)、b(*)…, そして、Printerオブジェクトによって、各コピー((*)、b(*))はやむを得ずニューメディアシートを始動しなければなりません。 '別々のドキュメントはコピーを非照合しました': Jobオブジェクトに複数のドキュメントがあるなら、たとえば、ドキュメントデータはaとbと呼ばれます、次に、操作を終えるためのメディアシートのただ一つの系列としてそれぞれのドキュメントインスタンスにおけるデータを処理するという結果を扱わなければなりません。 すなわち、セット(*)とb(*)は別々にそれぞれ終わっているでしょう。 Printerオブジェクトによって、ただ一つのドキュメントのデータを処理するという結果の各コピーはやむを得ずニューメディアシートを始動しなければなりません。 コピー複数の部が作られるなら
deBry, et al. Experimental [Page 76] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[76ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
メディアシートのセットが結果として生じるのを注文するのは、(*)、ドキュメントデータを処理するのからの(*)であるに違いありません…, b(*)、b(*)… . '別々のドキュメントはコピーを照合しました': Jobオブジェクトに複数のドキュメントがあるなら、たとえば、ドキュメントデータはaとbと呼ばれます、次に、操作を終えるためのメディアシートのただ一つの系列としてそれぞれのドキュメントインスタンスにおけるデータを処理するという結果を扱わなければなりません。 すなわち、セット(*)とb(*)は別々にそれぞれ終わっているでしょう。 Printerオブジェクトによって、ただ一つのドキュメントのデータを処理するという結果の各コピーはやむを得ずニューメディアシートを始動しなければなりません。 処理からのメディアシートのセットの注文が結果として生じて、コピー1部をする以上なら、ドキュメントデータは(*)であるに違いありません、b(*)、(*)、b(*)… . '単一のドキュメント新しいシート': 'ただ一つのドキュメント'と同じです、Printerオブジェクトが確実にしなければならないのを除いて、仕事における、それぞれのドキュメントインスタンスの第一印象がニューメディアシートに置かれるのを確実にしてください。 この値は、複数のドキュメントが各ドキュメントが新しいシートを始動する単一の主要部分と共にとめられるのを許容します。
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
多くのデバイスで、照合されたコピーのサポートしている数は、デバイスで物的生産量容器の数によって限られて、そうすることができる非照合されたコピーの数と異なっているかもしれません。
deBry, et al. Experimental [Page 77] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[77ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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のそれぞれの印刷された記録の各コピーに使用する仕上げの操作を特定します。 複数のドキュメントをもっているジョブスに関しては、「複数のドキュメント処理」属性は、何が仕上げの目的のために「コピー」を構成するかを決定します。
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."
'3''なにも': どんな仕上げの'4''主要部分'も実行しないでください: 1個以上の主要部分でドキュメントを縛ってください。 主要部分のはっきりした数とプレースメントはサイトで定義されています。 '5''パンチしてください': この値は、穴が完成ドキュメントで必要であることを示します。 穴のはっきりした数とプレースメントは、仕様が穴をあけることによって満たされているか(サイトと実装の特定の方法で)、またはパンチしているかもしれないパンチをサイトで定義するか、またはあらかじめ穴をあけられたメディアを代入することです。 '6''カバー': ドキュメントのために非印刷された(または、前印刷される)カバーを選択するのが必要であると、この値は指定されています。 これはドキュメント自体で印刷されたカバー(カバーストック媒体の)の仕様に取って代わりません。 '7''付いてください': この値は、結合がドキュメントに適用されることであることを示します。 「結合のタイプとプレースメントはサイトで定義されています。」
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で説明されます。
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).
クライアントが値のいかなる他の組み合わせに伴う'なにも'の値も供給するなら、まるで値のその他の組み合わせだけを供給したかのように(すなわち、'なにも'値は効き目がありません)同じです。
deBry, et al. Experimental [Page 78] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[78ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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オブジェクトは一度それぞれの供給されたページ範囲を印刷ストリームページの連結に適用しなければなりません。 例えば、それぞれ10ページの8通のドキュメントがあれば、ただ一つのドキュメントと他のドキュメントのページのいずれも印刷されないとき、ページ範囲'41: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まで異なるかもしれません。 「ページ範囲はデフォルトとする」という属性が全くありません。 「ページ範囲」属性がクライアントによって供給されないと、ドキュメントのすべてのページが印刷されるでしょう。
deBry, et al. Experimental [Page 79] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[79ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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:
この属性は、選択された媒体のインスタンスただ一つ側にでしゃばるために印刷ストリームページの数を指定します。 値が例えばそうなら:
deBry, et al. Experimental [Page 80] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[80ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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オブジェクトがサポートしているドキュメントの部分集合だけのために「オリエンテーションで要求された」形式を非常にサポートしそうであるので、ここで特記をします。
deBry, et al. Experimental [Page 81] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[81ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
「メディア」のための値が中型の名前、中型、入力トレー、および電子申込書を含んでいるので、1つの属性がメディアを指定します。
deBry, et al. Experimental [Page 82] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[82ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
If a Printer object supports a medium name as a value of this 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オブジェクトがこの属性の値として電子申込書をサポートするなら、そのような電子申込書はそれとなく順番にそれとなく電子申込書によって指定された媒体を含む入力トレーを選択する中型の名前を選択します。 また、電子申込書はそれとなく、Printerが各ページ単位で印刷としてドキュメントデータに合併しなければならないイメージを選択します。
Standard keyword values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation.
標準のキーワード値は、あって(ISO DPAとPrinter MIBから、取ります)、セクション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''高値'の正常であるか中間的な品質: プリンタで利用可能な最も高い品質
deBry, et al. Experimental [Page 83] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[83ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 | | +----------------------------+----------------------+----------------+ | job-state-message | text (MAX) | | +----------------------------+----------------------+----------------+ | number-of-documents | integer (0:MAX) | | +----------------------------+----------------------+----------------+ | output-device-assigned | name (127) | | +----------------------------+----------------------+----------------+ | time-at-creation | integer (0:MAX) | | +----------------------------+----------------------+----------------+ | time-at-processing | integer (0:MAX) | | +----------------------------+----------------------+----------------+ | time-at-completed | integer (0:MAX) | | +----------------------------+----------------------+----------------+ | number-of-intervening-jobs | integer (0:MAX) | | +----------------------------+----------------------+----------------+ | job-message-from-operator | text (127) | | +----------------------------+----------------------+----------------+ | job-k-octets | integer (0:MAX) | | +----------------------------+----------------------+----------------+ | job-impressions | integer (0:MAX) | | +----------------------------+----------------------+----------------+
+----------------------------+----------------------+----------------+ | 属性| 構文| 必要ですか? | +----------------------------+----------------------+----------------+ | 仕事-uri| uri| 必要です。| +----------------------------+----------------------+----------------+ | 仕事イド| 整数(1: 最大)| 必要です。| +----------------------------+----------------------+----------------+ | 仕事のプリンタuri| uri| 必要です。| +----------------------------+----------------------+----------------+ | 仕事詳しい情報| uri| | +----------------------------+----------------------+----------------+ | ジョブ名| 名前(MAX)| 必要です。| +----------------------------+----------------------+----------------+ | 仕事の起因するユーザ名| 名前(MAX)| 必要です。| +----------------------------+----------------------+----------------+ | 仕事状態| type1 enum| 必要です。| +----------------------------+----------------------+----------------+ | 仕事の州の理由| 1setOf type2キーワード| | +----------------------------+----------------------+----------------+ | 仕事の州のメッセージ| テキスト(MAX)| | +----------------------------+----------------------+----------------+ | ドキュメントの数| 整数(0: MAX)| | +----------------------------+----------------------+----------------+ | 割り当てられた出力デバイス| 名前(127)| | +----------------------------+----------------------+----------------+ | 作成における時間| 整数(0: MAX)| | +----------------------------+----------------------+----------------+ | 処理における時間| 整数(0: MAX)| | +----------------------------+----------------------+----------------+ | 完成されて、調節します。| 整数(0: MAX)| | +----------------------------+----------------------+----------------+ | 介入している仕事の数| 整数(0: MAX)| | +----------------------------+----------------------+----------------+ | オペレータからの仕事のメッセージ| テキスト(127)| | +----------------------------+----------------------+----------------+ | 仕事のk八重奏| 整数(0: MAX)| | +----------------------------+----------------------+----------------+ | 仕事印象| 整数(0: MAX)| | +----------------------------+----------------------+----------------+
deBry, et al. Experimental [Page 84] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[84ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
+----------------------------+----------------------+----------------+ | Attribute | Syntax | REQUIRED? | +----------------------------+----------------------+----------------+ | 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 | +----------------------------+----------------------+----------------+
+----------------------------+----------------------+----------------+ | 属性| 構文| 必要ですか? | +----------------------------+----------------------+----------------+ | 仕事のメディアシート| 整数(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の議論を見てください。
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インデックス値との互換性を考慮するために含まれていません。
deBry, et al. Experimental [Page 85] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[85ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 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.
このREQUIRED属性は仕事の名前です。 それは「仕事-uri」属性値よりユーザフレンドリーな名前です。 それはジョブスの間で特有である必要はありません。 セクション3.2を見てください。Jobの「ジョブ名」属性が「ジョブ名」操作属性におけるクライアントによって中に供給された値へのセットである、要求を作成してください、(.1 .1)。 しかしながら、「ジョブ名」操作属性がクライアントによって中に供給されない、Jobの作成では、要求を作成してください、そして、Printerオブジェクトは名前を生成しなければなりません。 プリンタSHOULDは以下のソースの1番目からの値を生産するJobの「ジョブ名」属性の値を生成します: 1) 最初(単に)のドキュメントの「ドキュメント名」操作属性、最初(単に)のドキュメント、または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.
このREQUIRED属性は印刷仕事を提出したエンドユーザの名前を含んでいます。 PrinterオブジェクトはIPP操作が受けられた認証サービスから得ることができる中で最も認証された印刷可能な名前にこの属性を設定します。
deBry, et al. Experimental [Page 86] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[86ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 Section 8).
そのようなものが単に利用可能でなく、オブジェクトが「要求しているユーザ名」操作属性におけるクライアントによって供給された値を使用するPrinterをする、操作を作成してください(セクション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 operation.
以下に注意してください。 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 eight values for job states, 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プロトコルは8つの値を仕事の州と定義しますが、実装は、それらの特定の実装に、適切な州をサポートする必要があるだけです。 言い換えれば、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''未定に保持される': 仕事は、いろいろな理由のための処理の候補ではありませんが、理由がもう存在していないとすぐに、'未定'の状態に戻るでしょう。 仕事の「仕事の州の理由」属性は、仕事がなぜもう処理の候補でないかを示さなければなりません。
'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
1. 仕事が使用である、使用する試み、1または、より純粋に分析であるソフトウェア処理である、PDL、など、2を作成するか、または解釈すると、仕事が使用、媒体の上でマークを作って、PDLを解釈している1個以上のハードウェアデバイス、そして/または、3 とめなどのようなPrinterオブジェクトを終える実行に使用するか、または試みている仕事は印刷のために用意されましたが、出力装置はまだそれを印刷していません、仕事が出力に達していないので
deBry, et al. Experimental [Page 87] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[87ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
device or because the job is queued in the output
device or some other spooler, awaiting the output
device to print it.
または、デバイス、それを印刷するために出力装置を待って、仕事が出力装置かある他のスプーラで列に並ばせられるので。
When the job is in the 'processing' state, the entire
job state includes the detailed status represented in
the printer's "printer-state", "printer-state-
reasons", and "printer-state-message" attributes.
仕事が'処理'状態にあるとき、仕事全体州はプリンタの「プリンタ状態」に表された詳細な状態、「プリンタ理由を述べる」、および「プリンタ州のメッセージ」属性を含めます。
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 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.
'7'は'取り消されました': 仕事はキャンセル仕事の操作で中止されました、そして、Printerオブジェクトは、仕事を中止するのを完成しました、そして、すべての地位の属性が仕事のためのそれらの検査値に達しました。 Printerオブジェクトが仕事を中止している間、仕事は現状のときに残っていますが、仕事の「仕事の理由を述べている」属性SHOULDはポイントを止めている'ユーザによって取り消されて'、'オペレータによって取り消される'か、または'デバイスでは、取り消され'て価値の'値と'処理から1つを含んでいます。
deBry, et al. Experimental [Page 88] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[88ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
仕事が'取り消された'状態に移行するとき、存在しているなら、'ポイントを止めるために処理する'値を取り除かなければなりませんが、存在しているなら、'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.
この属性のための検査値が1でなければならない、: Printerが全体で仕事を取り除く前に、'完成される'か、'取り消される'か、または'中止されます'。 仕事が'取り消され'て、'中止になっ'て、'完成した'州に残る時間の長さは実装に依存します。
The following figure shows the normal job state transitions.
以下の図は通常の仕事の状態遷移を示しています。
+----> canceled
/
+----> pending --------> processing ---------+------> completed
| ^ ^ \
--->+ | | +----> aborted
| v v /
+----> pending-held processing-stopped ---+
+---->は/+を取り消しました。----未定の>。-------->処理---------+------完成した>。| ^ ^ \ --->+| | +---->は中止になりました。| v/+に対して---->、未定に保持される、処理で止まられる。---+
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.
通常、仕事は左から右まで進歩をします。 他の状態遷移は、ありそうもないのですが、禁じられません。 示されていないのは、'未定'の''未定の保持された'処理で止まる'州からの'取り消された'状態への変遷です。
deBry, et al. Experimental [Page 89] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[89ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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つに達します: 仕事がアウトプット・メディアを積み重ねるのを含むすべての活動を終了した後に、仕事がすべての活動を終了して、すべての地位の属性が仕事のためのそれらの検査値に達した後に、'完成される'か、'取り消される'か、または'中止されます'。
Note: As with all other IPP attributes, if the implementation can not 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 that does not provide detailed status about the print job, the IPP Job object's state might literally be 'unknown'.
以下に注意してください。 実装がそうすることができないなら、この属性のために他のすべてのIPP属性のように正しい値を決定してください、それ。SHOULDは何らかのことによると不正確な値を推測して、間違った印象をエンドユーザに与えようとするよりバンドで出かけている値の'未知'(セクション4.1を見る)でJobオブジェクトの状態に関してむしろ応じます。 例えば、IPP Jobオブジェクトの状態は実装がただ印刷仕事に関する詳細な状態を提供しない何らかの印刷システムへのゲートウェイであるなら、文字通り'未知であるかもしれません'。
4.3.8 job-state-reasons (1setOf type2 keyword)
4.3.8 仕事の州の理由(1setOf type2キーワード)
This attribute provides additional information about the job's current state, i.e., information that augments the value of the job's "job-state" attribute.
この属性は仕事の現状(すなわち、仕事の「仕事状態」属性の値を増大させる情報)に関する追加情報を提供します。
Implementation of these values is OPTIONAL, i.e., a Printer NEED NOT implement them, even if (1) the output device supports the functionality represented by the reason and (2) is available to the Printer object implementation. These values MAY be used with any job state or states for which the reason makes sense. 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である、すなわち、Printerはそれらを実装する必要はありません、(1) 出力装置が理由によって表された機能性をサポートし、(2)がPrinterオブジェクト実装に利用可能であっても。 これらの値は理由が理解できるどんな仕事の州や州と共にも使用されるかもしれません。 その上、実装されると、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.
以下に注意してください。 受信「仕事状態」値で行動を取る配布しているクライアントに影響を与えないで、'仕事状態'属性に値を加えることができませんが、それは意図ですクライアントであると配布されたそのようなものに影響を与えながら追加「仕事の理由を述べている」値を定義して、示すことができる。 言い換えれば、「仕事の州の理由」属性が広げることができることを意図します。
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.
'job-incoming': The Create-Job operation has been accepted by the
Printer, but the Printer is expecting additional Send-Document
'なにも': 仕事の現状の理由が全くありません。 '仕事入来': Create-仕事の操作はPrinterによって受け入れられましたが、Printerは追加Send-ドキュメントを予想しています。
deBry, et al. Experimental [Page 90] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[90ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
and/or Send-URI operations and/or is accessing/accepting
document data.
'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.28.
'job-outgoing': The Printer is transmitting the job to the output
device.
'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.
'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-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.
'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.
Send-URI操作、ドキュメントデータをアクセスするか、または受け入れるのが、そうです。 '服従で中断される': 以下などの何らかの予期しない理由で完全に仕事を提出したというわけではありません。 (1) (2) 仕事がクライアントによって終えられる前にPrinterはダウンして、Printerかドキュメント転写法が(3) ドキュメントデータをPrinterに完全に移す前に、クライアントがダウンしたか、またはタイムアウトの期間の前に仕事を終えなかった何らかの非回復可能な方法でダウンしました。 セクション4.4.28を見てください。 '仕事の送信する': Printerは仕事を出力装置に伝えています。 '指定されるまでの仕事の保持': 仕事して成立してください。仕事のものの値、「-まだ未来に、」 属性が期間で指定されるまで、それはいます。 この理由が取り除かれて、仕事を持つ他の理由が全くないまで、仕事は処理の候補であるはずがありません。 'リソースは準備ができていません': 少なくとも仕事で必要であるメディア、フォント、リソースオブジェクトなどのリソースの1つは仕事が候補である物理的なプリンタのもののいずれでも準備ができていません。 この状態は、仕事が未定である間、次に仕事を受け入れると検出していて、処理されているかもしれません、実装によって。 仕事は、現状のときに残っているか、または'未定に保持された'状態に動かされるかもしれません、実装、そして/または、ジョブスケジューリング方針によって。 'プリンタは一部止まりました': Printerの「プリンタ州理由」属性の値は'-一部止められた'値を含んでいます。 'プリンタで止まる': Printerの「プリンタ状態」属性の値は'止められます'。 '仕事を解釈しています': 仕事が'処理'状態にありますが、より明確に、Printerはドキュメントデータを解釈しています。 '仕事で列に並ばせられる': 仕事が'処理'状態にありますが、より明確に、Printerはドキュメントデータを列に並ばせました。 '仕事を変えます': 仕事が'処理'状態にありますが、Printerは、より明確に、ドキュメントデータを解釈して、別の電子表現を作成しています。 '端物印刷': 出力装置はメディアにマークしています。 仕事が'処理'州に残っている間、取り消されるか、または中止されることの途中に仕事があるとき、この値が(1)を処理するマークでないのがナウい多くの時間を過ごして、次にマークが現在ナウいのを示したがっているPrintersか(2)の役に立ちますが、マークがまだ止まっていないので、印象かシートカウントが仕事のためにまだ大きくなっています。 '仕事はユーザに中止しました': 仕事はすなわち、認証されたアイデンティティがJobオブジェクトを作成した起因しているユーザの値と同じであるユーザ、またはある他の認可されたエンドユーザによるキャンセル仕事の要求を使用することで仕事の所有者によって中止されました、仕事の所有者のセキュリティグループのメンバーのように。
deBry, et al. Experimental [Page 91] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[91ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
'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.
'job-canceled-at-device': The job was canceled by an unidentified
local user, i.e., a user at a console at the device.
'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.
'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.
'仕事はオペレータに中止しました': 仕事はキャンセル仕事の要求を使用することでオペレータによって中止されました、すなわち、オペレータ特権を持っていると認証されたユーザで(地方である、またはリモートであることにかかわらず)。 仕事の所有者を除いて、仕事で取り消されるとき、安全保障政策がだれでも仕事を中止するのを許容することであるなら、この値は使用されるかもしれません。 事実上、そのような安全保障政策のために、IPPとの仕事を中止するのに関する限り、皆はオペレータです。 '仕事はデバイスで中止しました': 仕事はすなわち、未確認の地元のユーザ、デバイスのコンソールのユーザによって中止されました。 'システムで、中止されます': 中止されることの途中に仕事(1)があって、(2)がシステムによって中止されて、'中止になっている'状態に置かれたか、(3)はシステムで中止されて、'未定に保持された'状態に置かれました、ユーザかオペレータが再び手動で仕事を試みることができるように。 '止まるために処理して、指してください': リクエスタがキャンセル仕事の操作を発行したか、Printerオブジェクトは、仕事を中止しましたが、指定された停止ポイントが起こるか、または仕事の終了/クリーンアップが完成するまで、まだ仕事へのいくつかの動作を実行しています。
This reason is recommended to be used in conjunction with the '
processing' job state to indicate that the Printer object is
still performing some actions on the job while the job remains
in the 'processing' 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.
仕事が'処理'州に残っている間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.
'job-completed-with-warnings': The job completed with warnings.
'job-completed-with-errors': The job completed with errors (and
possibly warnings too).
'オフラインサービス': Printerはオフラインであり、仕事を全く受け入れていません。 '未定に保持された'状態にすべての'未定'の仕事を入れます。 サービスかドキュメント変換の入力が損なわれるか、または知らせられるなら、この状況は本当であるかもしれません。 '首尾よく完了する仕事': 首尾よく完了する仕事。 '警告で完了する仕事': 警告で完了する仕事。 '誤りで完了する仕事': 誤り(そして、ことによると警告も)で完了する仕事。
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を見てください)。
deBry, et al. Experimental [Page 92] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[92ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Note: 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, a new attribute with keyword values, needs to be developed and registered.
以下に注意してください。 値のSHOULD NOTは「仕事状態」と「仕事は理由を述べる」という属性の値に含まれなかった追加情報を含んでいます、インタプリタエラー情報などのように。 さもなければ、アプリケーション・プログラムが、分析するのを試みるかもしれない、(テキストであるとローカライズされます。) そのような追加情報のために、アプリケーション・プログラム消費のためのインタプリタ誤りとしてのそのようなもの(キーワード値がある新しい属性)は、開発されて、登録される必要があります。
4.3.10 number-of-documents (integer(0:MAX))
4.3.10 ドキュメントの数(整数(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.11 output-device-assigned (name(127))
4.3.11 割り当てられた出力デバイス((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 support multiple devices (so called "fan-out").
この属性はPrinterオブジェクトがこの仕事を割り当てた出力装置を特定します。 出力装置が埋め込まれたPrinterオブジェクトを実装するなら、Printerオブジェクトはこの属性を設定する必要はありません。 プリント・サーバがPrinterオブジェクトを実装するなら、Printerオブジェクトが出力装置を仕事に割り当てるまで、値は、空(ゼロ長ストリング)か返されないかもしれません。 ただ一つのPrinterオブジェクトサポート複数のデバイス(したがって、「四方八方に広がってください」と呼ばれる)であるときに、この属性は特に役に立ちます。
4.3.12 time-at-creation (integer(0:MAX))
4.3.12作成における時間(整数(0: 最大))
This attribute indicates the point in time at which the Job object was created. In order to populate this attribute, the Printer object uses the value in its "printer-up-time" attribute at the time the Job object is created.
この属性は時間内にのJobオブジェクトが作成されたポイントを示します。 Jobオブジェクトが作成されるとき、この属性に居住するために、Printerオブジェクトは「プリンタ動作可能時間」属性に値を使用します。
4.3.13 time-at-processing (integer(0:MAX))
4.3.13処理における時間(整数(0: 最大))
This attribute indicates the point in time at which the Job object began processing. In order to populate this attribute, the Printer object uses the value in its "printer-up-time" attribute at the time the Job object is moved into the 'processing' state for the first time.
この属性は時間内にのJobオブジェクトが処理し始めたポイントを示します。 Job物体が初めて'処理'状態に動かされるとき、この属性に居住するために、Printerオブジェクトは「プリンタ動作可能時間」属性に値を使用します。
deBry, et al. Experimental [Page 93] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[93ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
4.3.14 time-at-completed (integer(0:MAX))
4.3.14、完成されて、調節します。(整数(0: 最大))
This attribute indicates the point in time at which the Job object completed (or was cancelled or aborted). In order to populate this attribute, the Printer object uses the value in its "printer-up-time" attribute at the time the Job object is moved into the 'completed' or 'canceled' or 'aborted' state.
この属性は時間内にのJobが完成していた状態で(または、取り消されたか、または中止されました)反対するポイントを示します。 Job物体が'完成した'か'取り消された'か'中止になっている'状態に動かされるとき、この属性に居住するために、Printerオブジェクトは「プリンタ動作可能時間」属性に値を使用します。
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-k-octets (integer(0:MAX))
4.3.17 仕事の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.
また、この値は指示がドキュメントデータに埋め込んだコピーのため倍数因子を含んではいけません。 ドキュメントデータが実際にドキュメントデータの模写を含んでいると、この値はそのような模写を含むでしょう。 言い換えれば、いつもこの値はハードコピー出力が起こされる測定よりむしろソースドキュメントデータのサイズです。
deBry, et al. Experimental [Page 94] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[94ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Note: This attribute and the following two attributes ("job-
impressions" and "job-media-sheets") are not intended to be counters;
they are intended to be useful routing and scheduling information if
known. For these three 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 three attributes either right
at job submission time or at any later point in time.
以下に注意してください。 この属性と以下の2つの属性(「仕事の印象」と「仕事のメディアシート」)はカウンタであることを意図しません。 知られているなら、彼らは役に立つルーティングと情報の計画をすることを意図します。 それが中に供給されないならこれらの3つの属性のために、Printer目的が値を計算しようとするかもしれない、要求を作成してください。 クライアントが中でこれらの3つの属性に値を供給する、要求を作成してください、そして、Printerオブジェクトがクライアントが値を供給したより正確なa値を計算できるなら、Printerオブジェクトは、値を変えるのを選んでもよいです。 Printerオブジェクトは時間内に、ちょうどジョブ依頼時、または、任意な後の点のこれらの3つの属性のために正しい値を決定できるかもしれません。
4.3.18 job-impressions (integer(0:MAX))
4.3.18 仕事印象(整数(0: 最大))
This attribute specifies the total size in number of impressions of the document(s) being submitted (see the definition of impression in section 13.2.5).
この属性は提出されるドキュメントの印象の数における総サイズを指定します(セクション13.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八重奏」なら、また、この値は指示がドキュメントデータに埋め込んだコピーのため倍数因子を含んではいけません。 ドキュメントデータが実際にドキュメントデータの模写を含んでいると、この値はそのような模写を含むでしょう。 言い換えれば、いつもこの値は印象の数が仕事で生産される測定よりむしろソースドキュメントデータにおける印象の数です。
See the Note in the "job-k-octets" attribute that also applies to this attribute.
また、この属性に適用される「仕事のk八重奏」属性でNoteを見てください。
4.3.19 job-media-sheets (integer(0:MAX))
4.3.19 仕事のメディアシート(整数(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
「仕事のk八重奏」と属性、この値が乗法的を含まなければならないという「仕事印象」と異なって、「コピー」属性によって指定されたコピーの数と指示がドキュメントデータに埋め込んだ'コピーの数'に従って、要素はもしあれば貢献しました。 そしてシステム管理者がこの違いから、より低く制御できる。
deBry, et al. Experimental [Page 95] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[95ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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".
「シートがサポートした仕事のメディア」がある(1) 「仕事k八重奏でサポートされること」があるドキュメントのサイズと「印象がサポートした仕事」と(2) 仕事のサイズの両方の上限。
See the Note in the "job-k-octets" attribute that also applies to this attribute.
また、この属性に適用される「仕事のk八重奏」属性でNoteを見てください。
4.3.20 job-k-octets-processed (integer(0:MAX))
4.3.20 仕事の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八重奏」属性の価値の倍数でなければなりません。
Note: This attribute and the following two attributes ("job-
impressions-completed" and "job-sheets-completed") 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.
以下に注意してください。 この属性と以下の2つの属性、(「」 仕事の印象で完成した「シートが完了した仕事」、)、カウンタであることを意図します。 すなわち、処理し始めていない仕事のための値は0でなければなりません。 仕事の「仕事状態」が'処理する'か'処理で止まります'、この値が属性が要求される時まで処理された仕事の量を含むことを意図するということであるときに。
4.3.21 job-impressions-completed (integer(0:MAX))
4.3.21 印象が完了した仕事(整数(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.
この仕事の属性は今までのところ仕事のために終了している印象の数を指定します。 印刷デバイスに関しては、終了する印象は、出力を解釈して、マークして、積み重ねるのを含んでいます。
See the note in "job-k-octets-processed" which also applies to this attribute.
「仕事のk八重奏は処理したところ」のまた、この属性に適用される注意を見てください。
4.3.22 job-media-sheets-completed (integer(0:MAX))
4.3.22 シートが完成した仕事のメディア(整数(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.
それらのシートが半面の上、または、両方の上で処理されたか否かに関係なく、この仕事の属性は今までのところ、仕事全体のための完成したメディアシートマークと積み重ねを指定します。
See the note in "job-k-octets-processed" which also applies to this attribute.
「仕事のk八重奏は処理したところ」のまた、この属性に適用される注意を見てください。
deBry, et al. Experimental [Page 96] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[96ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
4.3.23 attributes-charset (charset)
4.3.23 属性-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.24 attributes-natural-language (naturalLanguage)
4.3.24 属性自然言語(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 specification.
以下に注意してください。 この仕様の範囲の外にこれらの属性がAdministratorによってどう設定されるかがあります。
deBry, et al. Experimental [Page 97] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[97ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
+----------------------------+----------------------+----------------+ | Attribute | Syntax | REQUIRED? | +----------------------------+----------------------+----------------+ | printer-uri-supported | 1setOf uri | REQUIRED | +----------------------------+----------------------+----------------+ | uri-security-supported | 1setOf type2 keyword | REQUIRED | +----------------------------+----------------------+----------------+ | 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 | | +----------------------------+----------------------+----------------+ | printer-state-message | text (MAX) | | +----------------------------+----------------------+----------------+ | operations-supported | 1setOf type2 enum | REQUIRED | +----------------------------+----------------------+----------------+ | charset-configured | charset | REQUIRED | +----------------------------+----------------------+----------------+ | charset-supported | 1setOf charset | REQUIRED | +----------------------------+----------------------+----------------+ | natural-language-configured| naturalLanguage | REQUIRED | +----------------------------+----------------------+----------------+ | generated-natural-language-| 1setOf | REQUIRED | | supported | naturalLanguage | | +----------------------------+----------------------+----------------+ | document-format-default | mimeMediaType | REQUIRED | +----------------------------+----------------------+----------------+ | document-format- | 1setOf | REQUIRED | | supported | mimeMediaType | | +----------------------------+----------------------+----------------+ | printer-is-accepting-jobs | boolean | REQUIRED | +----------------------------+----------------------+----------------+ | queued-job-count | integer (0:MAX) | RECOMMENDED | +----------------------------+----------------------+----------------+
+----------------------------+----------------------+----------------+ | 属性| 構文| 必要ですか? | +----------------------------+----------------------+----------------+ | uriが支えたプリンタ| 1setOf uri| 必要です。| +----------------------------+----------------------+----------------+ | セキュリティがサポートしたuri| 1setOf type2キーワード| 必要です。| +----------------------------+----------------------+----------------+ | プリンタ名| 名前(127)| 必要です。| +----------------------------+----------------------+----------------+ | プリンタ位置| テキスト(127)| | +----------------------------+----------------------+----------------+ | プリンタインフォメーション| テキスト(127)| | +----------------------------+----------------------+----------------+ | プリンタ詳しい情報| uri| | +----------------------------+----------------------+----------------+ | プリンタドライバーインストーラ| uri| | +----------------------------+----------------------+----------------+ | プリンタメーカーとモデル| テキスト(127)| | +----------------------------+----------------------+----------------+ | よりプリンタ多くのインフォメーション、-| uri| | | メーカー| | | +----------------------------+----------------------+----------------+ | プリンタ状態| type1 enum| 必要です。| +----------------------------+----------------------+----------------+ | プリンタ州の理由| 1setOf type2キーワード| | +----------------------------+----------------------+----------------+ | プリンタ州のメッセージ| テキスト(MAX)| | +----------------------------+----------------------+----------------+ | 操作で、サポートされます。| 1setOf type2 enum| 必要です。| +----------------------------+----------------------+----------------+ | charsetによって構成されています。| charset| 必要です。| +----------------------------+----------------------+----------------+ | charsetによってサポートされます。| 1setOf charset| 必要です。| +----------------------------+----------------------+----------------+ | 構成された自然な言語| naturalLanguage| 必要です。| +----------------------------+----------------------+----------------+ | 発生して当然の言語、-| 1setOf| 必要です。| | サポートされます。| naturalLanguage| | +----------------------------+----------------------+----------------+ | ドキュメント形式デフォルト| mimeMediaType| 必要です。| +----------------------------+----------------------+----------------+ | ドキュメント形式、-| 1setOf| 必要です。| | サポートされます。| mimeMediaType| | +----------------------------+----------------------+----------------+ | プリンタは仕事を受け入れています。| 論理演算子| 必要です。| +----------------------------+----------------------+----------------+ | 列に並ばせられた仕事のカウント| 整数(0: MAX)| 推薦されます。| +----------------------------+----------------------+----------------+
deBry, et al. Experimental [Page 98] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[98ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
+----------------------------+----------------------+----------------+ | Attribute | Syntax | 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 | | +----------------------------+----------------------+----------------+ | job-k-octets-supported | rangeOfInteger | | | | (0:MAX) | | +----------------------------+----------------------+----------------+ | job-impressions-supported | rangeOfInteger | | | | (0:MAX) | | +----------------------------+----------------------+----------------+ | job-media-sheets-supported | rangeOfInteger | | | | (0:MAX) | | +----------------------------+----------------------+----------------+
+----------------------------+----------------------+----------------+ | 属性| 構文| 必要ですか? | +----------------------------+----------------------+----------------+ | プリンタメッセージ、-、-| テキスト(127)| | | オペレータ| | | +----------------------------+----------------------+----------------+ | 色で、サポートされます。| 論理演算子| | +----------------------------+----------------------+----------------+ | 参照-uri体系、-| 1setOf uriScheme| | | サポートされます。| | | +----------------------------+----------------------+----------------+ | オーバーライドがサポートしたpdl| type2キーワード| 必要です。| +----------------------------+----------------------+----------------+ | プリンタ動作可能時間| 整数(1: MAX)| 必要です。| +----------------------------+----------------------+----------------+ | プリンタ電流時間| dateTime| | +----------------------------+----------------------+----------------+ | 複数の操作タイムアウト| 整数(1: MAX)| | +----------------------------+----------------------+----------------+ | 圧縮で、サポートされます。| 1setOf type3キーワード| | +----------------------------+----------------------+----------------+ | 八重奏がサポートした仕事k| rangeOfInteger| | | | (0: マックス) | | +----------------------------+----------------------+----------------+ | 印象がサポートした仕事| rangeOfInteger| | | | (0: マックス) | | +----------------------------+----------------------+----------------+ | シートがサポートした仕事のメディア| rangeOfInteger| | | | (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 IPP/1.0. The precise format of this URI is implementation dependent and depends on the protocol. See the next section for a description "uri-security-supported" which is the REQUIRED companion attribute 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.
このREQUIRED Printer属性はPrinterオブジェクトのための少なくとも1つのURIを含んでいます。 それ、OPTIONALLYはPrinterオブジェクトのための1つ以上のURIを含んでいます。 管理者は、どうでもIPP/1.0の範囲の外にそれらのURIを保管するためにPrinterオブジェクトのURIを決定して、この属性を構成します。 このURIの正確な形式は、実装に依存していて、プロトコルに依存します。 記述のためのREQUIRED仲間属性である「セキュリティがサポートしたuri」という次のセクションをこの「uriが支えたプリンタ」属性に見てください。 詳しい情報に関してPrinterオブジェクトのアイデンティティのセクション2.4とセキュリティとURIのセクション8.2を見てください。
deBry, et al. Experimental [Page 99] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[99ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
4.4.2 uri-security-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 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. The following standard values are defined:
このREQUIRED Printer属性に、「uriが支えたプリンタ」属性として同じ基数がなければなりません(同じ数の値を含んでいます)。 この属性は「uriが支えたプリンタ」属性で記載された各URIに使用されるセキュリティー対策を特定します。 「i、」 「セキュリティがサポートしたuri」の値が第対応している、「i、」 「uriが支えたプリンタ」とそれの値はそのURIでPrinterオブジェクトにアクセスするのに使用されるセキュリティー対策について第説明します。 以下の基準値は定義されます:
'none': There are no secure communication channel protocols in use
for the given URI.
'なにも': 与えられたURIに、使用中のどんな安全な通信チャネルプロトコルもありません。
'ssl3': SSL3 [SSL] is the secure communications channel protocol in
use for the given URI.
'ssl3': SSL3[SSL]は与えられたURIの使用での安全なコミュニケーションチャンネルプロトコルです。
Consider the following example. For a single Printer object, an administrator configures the "printer-uri-supported" and "uri- security-supported" attributes as follows:
以下の例を考えてください。 単一のPrinterオブジェクトに関しては、管理者は以下の「uriが支えたプリンタ」と「uriにセキュリティでサポートしている」属性を構成します:
"printer-uri-supported": 'http://acme.com/open-use-printer', '
http://acme.com/restricted-use-printer', '
http://acme.com/private-printer'
"uri-security-supported": 'none', 'none', 'ssl3'
「uriが支えたプリンタ」: ' http://acme.com/open-use-printer '、' http://acme.com/restricted-use-printer '' http://acme.com/private-printer '「セキュリティがサポートしたuri」: 'なにも'、'なにも'、'ssl3'
In this case, one Printer object has three URIs.
この場合、1個のPrinterオブジェクトには、3つのURIがあります。
- For the first URI, 'http://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 name
implies that there is no Basic or Digest authentication being
used, but it is up to the client to determine that while using
HTTP underneath the IPP application protocol.
- For the second URI, 'http://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. In
this case, although the name does imply that there is some sort
of Basic or Digest authentication being used within HTTP, it is
up to the client to determine that while using HTTP and by
processing any '401 Unauthorized' HTTP error messages.
- For the third URI, 'http://acme.com/private-printer', the value '
ssl3' in "uri-security-supported" indicates that SSL3 is being
used to secure the channel. The client SHOULD be prepared to
use SSL3 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 'ssl3' value in
- 最初のURIのために、' http://acme.com/open-use-printer '、「セキュリティがサポートしたuri」の値の'なにも'は、HTTPで実行されるために構成されたどんな安全なチャンネルプロトコルもないのを示します。 名前は、使用されるどんなBasicもDigest認証もないのを含意しますが、IPPアプリケーション・プロトコルの下にHTTPを使用している間、それを決定するのは、クライアント次第です。 - 第2URIのために、' http://acme.com/restricted-use-printer '、「セキュリティがサポートしたuri」の値の'なにも'は、HTTPで実行されるために構成されたどんな安全なチャンネルプロトコルもないのを示します。 この場合、名前は、HTTPの中で使用されるある種のBasicかDigest認証があるのを含意しますが、それは、HTTPを使用している間にそれを決定するクライアントとどんな'401Unauthorized'HTTPエラーメッセージも処理することによって、あります。 - 第3URIのために、' http://acme.com/private-printer '、「セキュリティがサポートしたuri」の値の'ssl3'は、SSL3がチャンネルを固定するのに使用されているのを示します。 クライアントSHOULD、Printerオブジェクトで交信している間、許容できるciphersuiteを交渉するSSL3縁どりを使用に使用するように用意してください。 この場合、名前は安全なコミュニケーションチャンネルの使用を含意しますが、'ssl3'価値の存在によって、中で事実によって明白になられます。
deBry, et al. Experimental [Page 100] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[100ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
"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.
「セキュリティがサポートしたuri。」 クライアントはそれがどのセキュリティー対策が含意されるかを決定するのに命名規則に続くか、またはURIを分析することによってどのセキュリティを使用しなければならないかという理解に頼る必要はありません。
It is expected that many IPP Printer objects will be configured to support only one channel (either configured to use SSL3 access or not), and will therefore only ever 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.
多くのIPP Printerオブジェクトが(SSL3アクセスを使用するために、構成されています)の1個のチャンネルだけを支えるために構成されて、したがって、「uriが支えたプリンタ」属性で記載された1つのURIしか持たないと予想されます。 Printerオブジェクト(それに1つのURIか1つ以上のURIしかないか否かに関係なく)の構成、クライアントが目標「プリンタ-uri」操作属性における1つのURIだけを供給しなければならないのは、問題ではありません。
4.4.3 printer-name (name(127))
4.4.3 プリンタ名((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.
このREQUIRED Printer属性はPrinterオブジェクトの名前を含んでいます。 それはURIよりさらに多くのエンドユーザ好意的な名前です。 管理者は、プリンタの名前を決定して、その名前にこの属性を設定します。 この名前はプリンタのURIの最後の部分であるかもしれませんかそれが関係ないかもしれません。 非米国の英語現場では、名前がURIで許容されていないキャラクタを保管するかもしれません。
4.4.4 printer-location (text(127))
4.4.4 プリンタ位置(テキスト(127))
This Printer attribute identifies the location of the device. This could include things like: "in Room 123A, second floor of building XYZ".
このPrinter属性はデバイスの位置を特定します。 これは以下のようなものを含むかもしれません。 「Room 123A、ビルXYZの2階。」
4.4.5 printer-info (text(127))
4.4.5 プリンタインフォメーション(テキスト(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".
このPrinter属性はこのPrinterオブジェクトに関する記述的な情報を特定します。 これは以下のようなものを含むかもしれません。 好意から他のもののために、このプリンタで(1-5ページ)の小さい仕事だけを印刷してください。または、「HRプレゼンテーションのために色の透明を印刷するのにこのプリンタを使用できる」、「」 「このプリンタは1997年7月1日に遠ざかって、新しいプリンタを見つけてください。」さえ
4.4.6 printer-more-info (uri)
4.4.6 プリンタ詳しい情報(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.
このPrinter属性はこの特定のPrinterオブジェクトに関する詳しい情報を得るのに使用されるURIを含んでいます。 例えば、これは1HTML形式のページにウェブBrowserにアクセスしやすい状態で参照をつけるHTTPタイプURIであるかもしれません。 このURIから得られた情報はエンドユーザ消費で意図します。 このURIからIPPの範囲の外の特徴にアクセスできます。 具体的に言うと、情報はこのプリンタインスタンスとサイト詳細サービス(例えば、賃仕事の価格設定、提供されたサービス、エンドユーザ支援)に意図します。 装置製造業者は初めは、この属性に居住するかもしれません。
deBry, et al. Experimental [Page 101] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[101ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
4.4.7 printer-driver-installer (uri)
4.4.7 プリンタドライバーインストーラ(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 IPP. The device manufacturer may initially populate this attribute.
このPrinter属性はこのPrinterオブジェクトのためのドライバーインストーラの場所を見つけるのに使用するURIを含んでいます。 この属性は消費でオートマトンで意図します。 印刷ドライバー施設の整備士はIPPの範囲の外にいます。 装置製造業者は初めは、この属性に居住するかもしれません。
4.4.8 printer-make-and-model (text(127))
4.4.8 プリンタメーカーとモデル(テキスト(127))
This Printer attribute identifies the make and model of the device. The device manufacturer may initially populate this attribute.
このPrinter属性はデバイスのメーカーとモデルを特定します。 装置製造業者は初めは、この属性に居住するかもしれません。
4.4.9 printer-more-info-manufacturer (uri)
4.4.9、プリンタ、 より多くのインフォメーションメーカー(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.
このPrinter属性はこのタイプのデバイスに関して詳しい情報を得るのに使用されるURIを含んでいます。 このURIから得られた情報はエンドユーザ消費で意図します。 このURIからIPPの範囲の外の特徴にアクセスできます(例えば、最新のファームウェア、アップグレードはドライバーを印刷します、利用可能な任意の特徴、色のサポートに関する詳細)。 情報がサイトの特定の変更かサービスへの尊敬なしでこのプリンタに適切であることを意図します。 装置製造業者は初めは、この属性に居住するかもしれません。
4.4.10 printer-state (type1 enum)
4.4.10 プリンタ状態(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.
このREQUIRED Printer属性はデバイスの現状を特定します。 「プリンタ州の理由」属性は、与えられたプリンタ状態でPrinterの、より詳細な情報を教えるために「プリンタ状態」属性を増大させます。
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.0. A Printer NEED NOT implement all values if they are not applicable to a given implementation.
Printerオブジェクトは属性を要求する操作に応じる前に、この属性をアップデートするだけでよいです。 Printerオブジェクトは、非同期的なイベント通知がIPP/1.0の一部でないので、絶えずこの属性をアップデートする必要はありません。 それらが与えられた実装に適切でないなら、Printerはすべての値を実装しなければならないというわけではありません。
The following standard enum values are defined:
以下の標準のenum値は定義されます:
Value Symbolic Name and Description
英字名と記述を評価してください。
'3' 'idle': If a Printer receives a job (whose required
resources are ready) while in this state, such a job
MUST transit into the 'processing' state immediately.
If the "printer-state-reasons" attribute contains any
reasons, they MUST be reasons that would not prevent a
job from transiting into the 'processing' state
immediately, e.g., 'toner-low'. Note: if a Printer
'3''怠けます': Printerがこの状態にある間、仕事(必要なリソースは準備ができている)を受けるなら、そのような仕事は状態のすぐに'処理'であることへのトランジットを受けなければなりません。 「プリンタ州の理由」属性が何か理由を含んでいるなら、それらは仕事がすぐに'処理'状態に通過するのを防がない理由、例えば、'トナー安値'であるに違いありません。 以下に注意してください。 プリンタです。
deBry, et al. Experimental [Page 102] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[102ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
controls more than one output device, the above
definition implies that a Printer is 'idle' if at
least one output device is idle.
制御1以上出力装置、上の定義は少なくとも1個の出力装置が使用されていないならPrinterが'活動していません'を含意します。
'4' 'processing': If a Printer receives a job (whose required
resources are ready) while in this state, such a job
MUST transit into the 'pending' state immediately.
Such a job MUST transit into the 'processing' state
only after jobs ahead of it complete. If the
"printer-state-reasons" attribute contains any
reasons, they MUST be reasons that do not prevent the
current job from printing, e.g. 'toner-low'. Note:
if a Printer controls more than one output device, the
above definition implies that a Printer is '
processing' if at least one output device is
processing, and none is idle.
'4''処理': Printerが仕事(必要なリソースは準備ができている)を受けるなら、中でこの状態をゆったり過ごしてください、仕事がすぐに'未定'の状態に通過しなければならないそのようなもの。 そのような仕事は状態のそれの前に単に仕事の後に完全な状態で'処理'であることへのトランジットがそうしなければなりません。 「プリンタ州の理由」属性が何か理由を含んでいるなら、それらは印刷から現在の仕事を防がない理由、例えば、'トナー安値'であるに違いありません。 以下に注意してください。 Printerが1個以上の出力装置を制御するなら、上の定義は少なくとも1個の出力装置が処理であるならPrinterが'処理'であり、なにも活動していなくないのを含意します。
'5' 'stopped': If a Printer receives a job (whose required
resources are ready) while in this state, such a job
MUST transit into the 'pending' state immediately.
Such a job MUST transit into the 'processing' state
only after some human fixes the problem that stopped
the printer and after jobs ahead of it complete
processing. If supported, the "printer-state-reasons"
attribute MUST contain at least one reason, e.g. '
media-jam', which prevents it from either processing
the current job or transitioning a 'pending' job to
the 'processing' state.
'5'は'止まりました': Printerが仕事(必要なリソースは準備ができている)を受けるなら、中でこの状態をゆったり過ごしてください、仕事がすぐに'未定'の状態に通過しなければならないそのようなもの。 そのような仕事は人間がプリンタを止めた問題を修正した後とだけそれの前の仕事が、処理するのを完了した後に'処理'状態へのトランジットがそうしなければなりません。 サポートされるなら、「プリンタ州の理由」属性は少なくとも1つの理由、例えば、それが現在の仕事を処理するか、または移行するのを防ぐ'メディアジャム'の'未定'仕事を'処理'状態に含まなければなりません。
Note: if a Printer controls more than one output
device, the above definition implies that a Printer is
'stopped' only if all output devices are stopped.
Also, it is tempting to define 'stopped' as when a
sufficient number of output devices are stopped and
leave it to an implementation to define the sufficient
number. But such a rule complicates the definition of
'stopped' and 'processing'. For example, with this
alternate definition of 'stopped', a job can move from
'pending' to 'processing' without human intervention,
even though the Printer is stopped.
以下に注意してください。 Printerが1個以上の出力装置を制御するなら、上の定義は、すべての出力装置が止められる場合にだけPrinterが'止められること'を含意します。 また、定義する誘惑が十分な数の出力装置が止められて、十分な数を定義するように実装に任せる時として'止まった'ということです。 規則が'止められ'て、'処理し'ながら定義を複雑にするそのようなもの。 例えば、'止まること'のこの代替の定義で、仕事は人間の介入のない'未定の''処理'から移行できます、Printerは止められますが。
4.4.11 printer-state-reasons (1setOf type2 keyword)
4.4.11 プリンタ州の理由(1setOf type2キーワード)
This Printer attribute supplies additional detail about the device's state.
このPrinter属性はデバイスの状態に関する追加詳細を提供します。
deBry, et al. Experimental [Page 103] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[103ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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).
それぞれのキーワード値には、厳しさのレベルを示す接尾語があるかもしれません。 3つのレベルは以下の通りです。 レポート(最も厳しくない)、警告、および誤り(最も厳しい)。
- '-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.
- '-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.
- '-報告してください': この接尾語は、理由が「レポート」であると示します。 実装は、いくつかかすべてのレポートを省略するのを選ぶかもしれません。 いくつかのレポートがプリンタ状態に関して、よりすばらしい粒状を指定します。 他のものは先駆として警告に役目を果たします。 レポートはプリント出力に影響できた何も含んではいけません。 - '警告': この接尾語は、理由が「警告」であると示します。 実装は、いくつかかすべての警告を省略するのを選ぶかもしれません。 警告は先駆として誤りに機能します。 警告はそれが、仕事が完成するのを防ぐ何も含んではいけません、出力がいくつかの場合やや劣る品質のものであるかもしれませんが。 - '誤り': この接尾語は、理由が「誤り」であると示します。 実装はすべての誤りを含まなければなりません。 この属性が1つ以上の誤りを含んでいるなら、プリンタが止まっている状態にあるに違いありません。
If the implementation does not add any one of the three suffixes, all parties MUST assume that the reason is an "error".
実装が3つの接尾語のいずれも加えないなら、すべてのパーティーが、理由が「誤り」であると仮定しなければなりません。
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.
Printerオブジェクトが1個以上の出力装置を制御するなら、この属性の各値は出力装置の1つ以上に適用されるかもしれません。 全体の5月としてPrinterオブジェクトを止めない1個の出力装置における誤りはPrinterの「プリンタ州の理由属性」における警告として生じます。 そのようなPrinterのための「プリンタ状態」に'止まること'の値があるなら、値の中に誤り理由が「プリンタ州の理由」属性にあるに違いありません。
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.
'media-needed': A tray has run out of media.
'media-jam': The device has a media jam.
'paused': Someone has paused the Printer object. 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.
'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
unless the Printer object is realized by a print server that is
'他': デバイスは本書では記載されたもの以外の誤りを検出しました。 'なにも': 理由がありません。 この州の理由は少しも値なしで「プリンタ州の理由」に意味的に同等です。 'メディアによって必要': トレーはメディアを使い果たしました。 'メディアジャム': デバイスはメディアジャムを食べます。 'ポーズされる': だれかがPrinterオブジェクトをポーズしました。 この状態では、Printerはプリント出力を起こしてはいけませんが、それはクライアントによって要求された他の操作を実行しなければなりません。 Printerがポーズされたとき、Printerが仕事を印刷し続けていたなら、PrinterはPrinterがもうポーズされないとき、その仕事を印刷するのを再開して、そのようなくぎりのプリント出力における証拠を全く出てはいけません。 '閉鎖': だれかがサービスからPrinterオブジェクトを取り除いて、デバイスは、パワーダウンされるか、または物理的に取り外されるかもしれません。 この状態では、Printerオブジェクトはプリント出力を起こしてはいけません、そして、Printerオブジェクトがプリント・サーバによって実感されない場合、それがいます。
deBry, et al. Experimental [Page 104] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[104ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
'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.
'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)
まだアクティブであることで、Printerオブジェクトはこの値を返すのを含むクライアントによって要求されなかった他の操作を全く実行しなければなりません。 それが閉鎖であったときに、Printerオブジェクトが仕事を印刷し続けていたなら、Printerは、Printerがもう閉鎖でないときに、その仕事を印刷するのを再開する必要はありません。 Printerが、そのような仕事を印刷するのを再開するなら、そのような閉鎖(例えば閉鎖が閉鎖の後にもう一度印刷されるかもしれない前に印刷された部分)のプリント出力における証拠は残っているかもしれません。 以下は'デバイスとの接続'です。 Printerオブジェクトは、出力装置で仕事の計画をして、共用回線網出力装置に接続することの途中にあります(そして、実際にネットワークの他のサーバで出力装置の使用法によって、任意に長い時間仕事を印刷し始めることができないかもしれません)。 '調節されて出かける': サーバは、出力装置(または、いつも接続される)に接続できましたが、出力装置から返事をもらうことができませんでした。 '止まります': Printerオブジェクトは、デバイスを止めることの途中にあって、しばらく立ち寄るでしょう。 デバイスが止められるとき、PrinterオブジェクトはPrinterオブジェクトの状態を'止まること'に変えるでしょう。 '停止警告'理由は決して単一の出力装置があるPrinterさえのための誤りではありません。 出力装置が、仕事を受け入れるのをやめるとき、出力装置が、印刷するのを完成している間、Printerには、この理由があるでしょう。 '-一部止められます': Printerオブジェクトが1個以上の出力装置を制御すると、この理由は、1個以上の出力装置が止められるのを示します。 理由がレポートであるなら、出力装置の半分未満は止められます。 理由が出力装置のすべてが止められるより少ない警告であるなら。 'トナー安値': デバイスはトナーで低いです。 'トナー空': デバイスはトナーを使い果たしました。 '領域をいっぱいにスプールしてください': スプールするために割り当てられる永続的なストレージの限界に達しました。 '開いているカバー': デバイスの上の1個以上のカバーが開いています。 '開いているインタロック': プリンタの上の1台以上のインタロックデバイスの錠は開いています。 'ドア戸外': デバイスの上の1個以上のドアが開いています。 '入力トレーの取り逃がすこと': 1個以上の入力トレーがデバイスにありません。 'メディア安値': 少なくとも1個の入力トレーがメディアで低いです。 'メディア空': 少なくとも1個の入力トレーが空です。 '出力トレーの取り逃がすこと': 1個以上の出力トレーがデバイスに'いっぱいに領域をほとんど出力していた'状態でありません: 1つ以上の出力領域がほぼいっぱいです(例えば、トレー、スタッカ、照合者)。 '領域をいっぱいに出力してください': 1つ以上の出力領域が完全です。 (例えば、トレー、スタッカ、照合者) 'マーカー供給安値': デバイスは少なくとも1つのマーカー供給のときに低いです。 (例えば、トナー、インク、リボン)
deBry, et al. Experimental [Page 105] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[105ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
'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)
'マーカー供給は空になります' デバイスは少なくとも1つのマーカー供給から脱しています。 (例えば、トナー、インク、リボン) 'マーカーはいっぱいにほとんどむだになります': デバイスマーカー供給汚物容器はほとんど完全です。 'マーカーはいっぱいにむだになります': デバイスマーカー供給汚物容器は完全です。 'fuser過剰臨時': fuser温度は標準を超えています。 '臨時の下におけるfuser': fuser温度が標準の下にあります。 'eolの近くのopc': 寿命末期頃に、光学感光体があります。 '、寿命をopcする、'、: 光学感光体はもう機能していません。 '開発者安値': デバイスは開発者に低いです。 '開発者と同じくらい空になってください' デバイスは開発者を使い果たしました。 '入手できないインタプリタリソース': インタプリタリソースは入手できません。(すなわち、フォント、フォーム)
4.4.12 printer-state-message (text(MAX))
4.4.12 プリンタ州のメッセージ(テキスト(最大))
This Printer attribute specifies the additional information about the printer state and printer state reasons 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オブジェクトはPrinterの「サポートされた発生している自然な言語」属性によって特定された自然言語のどれかのこのメッセージを生成することができなければなりません(操作属性がセクション3.1.4で指定した「属性自然言語」.1を見てください)。
4.4.13 operations-supported (1setOf type2 enum)
4.4.13 操作で、サポートされます。(1setOf type2 enum)
This REQUIRED Printer attribute specifies the set of supported operations for this Printer object and contained Job objects. All 32-bit enum values for this attribute MUST NOT exceed 0x8FFF, since these values are passed in two octets in each Protocol request [RFC2565].
このREQUIRED Printer属性はこのPrinterオブジェクトと含まれたJobオブジェクトのためのサポートしている操作のセットを指定します。 この属性のためのすべての32ビットのenum値が0x8FFFを超えてはいけません、これらの値がそれぞれのプロトコル要求[RFC2565]における2つの八重奏で通過されるので。
The following standard enum and "operation-id" (see section 3.1.2) values are defined:
以下の標準のenumと「操作イド」(セクション3.1.2を見る)値は定義されます:
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
0×0000 予約されていて、0×0002Print-仕事の0×0003Print-URI0×0004Validate-仕事の0×0005Create-仕事の0×0006を使用するのではなく、予約されたどんな中古の0×0001も0×0007Send-URIをSend記録しません。
deBry, et al. Experimental [Page 106] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[106ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
0x0008 Cancel-Job
0x0009 Get-Job-Attributes
0x000A Get-Jobs
0x000B Get-Printer-Attributes
0x000C-0x3FFF reserved for future operations
0x4000-0x8FFF reserved for private extensions
0×0008 0x000A Get-ジョブス0x000B Getプリンタ属性0x000C-0x3FFFが個人的な拡大のために予約された操作の将来の0×4000 0x8FFFのために予約したキャンセル仕事の0×0009のGet仕事の属性
This allows for certain vendors to implement private extensions that are guaranteed to not conflict with future registered extensions. However, there is no guarantee that two or more private extensions will not conflict.
これは、あるベンダーが今後の登録された拡大と衝突しないように保証される個人的な拡大を実装するのを許容します。 しかしながら、2つ以上の個人的な拡大が闘争しないという保証が全くありません。
4.4.14 charset-configured (charset)
4.4.14 charsetによって構成されています。(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.
そして、このREQUIRED Printer属性はPrinterがオペレータ、システム管理者、またはメーカーによって設定される'テキスト'と'名前'Printer属性を表すために構成されたのを反対させるcharsetを特定します、すなわち、「プリンタ名」(名前)のために、「プリンタ位置」(テキスト)、「プリンタインフォメーション」(テキスト)、「プリンタ作成、-、-モデル化してください、」 (テキスト。) したがって、また、Printerオブジェクトの「charsetによってサポートしている」属性の値の中にPrinterオブジェクトの「charsetによって構成された」属性の値があるに違いありません。
4.4.15 charset-supported (1setOf charset)
4.4.15 charsetによってサポートされます。(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.
このREQUIRED Printer属性はPrinterと含まれたJobオブジェクトが属性構文'テキスト'と'名前'で属性でサポートするcharsetsのセットを特定します。 IPPオブジェクトが、UTF-8[RFC2279]がcharsetであるとサポートしなければならないので、少なくとも値の'utf-8'は存在していなければなりません。 Printerオブジェクトがcharsetをサポートするなら、それは必要であることで、構文'テキスト'とIPPオブジェクトがそうしなければならない'名前'(1)の属性が要求にcharsetを認めて、応答におけるcharsetを返すすべてためにそれを意味します。
If more charsets than UTF-8 are supported, the IPP object MUST perform charset conversion between the charsets as described in Section 3.2.1.2.
UTF-8より多くのcharsetsがサポートされるなら、IPPオブジェクトはセクション3.2.1で.2に説明されるようにcharsetsの間のcharset変換を実行しなければなりません。
4.4.16 natural-language-configured (naturalLanguage)
4.4.16 構成された自然な言語(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
そして、このREQUIRED Printer属性はPrinterがオペレータ、システム管理者、またはメーカーによって設定される'テキスト'と'名前'Printer属性を表すために構成されたのを反対させる自然言語を特定します、すなわち、「プリンタ名」(名前)のために、「プリンタ位置」(テキスト)、「プリンタインフォメーション」(テキスト)、「プリンタ作成、-、-モデル化してください、」 (テキスト。) これらのPrinter属性を返すとき、Printerオブジェクトはこの属性によって指定された構成された自然言語でそれらを返すかもしれません、自然言語の代わりに
deBry, et al. Experimental [Page 107] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[107ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
「属性自然言語」操作属性でクライアントによって要求されています。 OPTIONAL複数の自然言語の仕様のための.1がサポートするセクション3.1.4を見てください。 したがって、また、Printerオブジェクトの「発生して自然に言語でサポートしている」属性の値の中にPrinterオブジェクトの「構成された自然な言語」属性の値があるに違いありません。
4.4.17 generated-natural-language-supported (1setOf naturalLanguage)
4.4.17 サポートされた発生している自然な言語(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.
このREQUIRED Printer属性はPrinterオブジェクトと含まれたJobオブジェクトが属性構文'テキスト'と'名前'で属性でサポートする自然言語を特定します。 (s)がサポートした自然言語は実装、そして/または、構成に依存します。 charsetsと異なって、自然言語がサポートされるか否かに関係なく、IPPオブジェクトはどんな自然言語かどんなNatural Language Overrideとの要求も受け入れなければなりません。
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 generate messages in any of the Printer's supported natural languages. See section 3.1.4 for the specification of 'text' and ' name' attributes in operation requests and responses.
Printerオブジェクトが自然言語をサポートするなら、それは、すなわち、PrinterかJobオブジェクトがメッセージを生成する属性のどれか、操作応答における「仕事の州のメッセージ」、「プリンタメッセージを述べている」属性、およびOperation Messages(セクション3.1.5を見る)に関して、PrinterとJobオブジェクトがPrinterのサポートしている自然言語のどれかのメッセージを生成することができなければならないことを意味します。 操作要求と応答における'テキスト'と'名前'属性の仕様に関してセクション3.1.4を見てください。
Note: A Printer object that supports multiple natural languages, often has separate catalogs of messages, one for each natural language supported.
以下に注意してください。 それで複数の自然言語をサポートして、しばしばメッセージのカタログ、サポートされた各自然言語あたり1つを切り離すPrinterオブジェクト。
4.4.18 document-format-default (mimeMediaType)
4.4.18 ドキュメント形式デフォルト(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.
クライアントが操作要求のどれかにおける「ドキュメント・フォーマット」操作属性にその供給ドキュメントデータを提供しないなら、このREQUIRED Printer属性はPrinterオブジェクトが仮定するために構成されたドキュメント・フォーマットを特定します。 この属性のための基準値はインターネットメディアタイプ(時々MIMEの種類と呼ばれる)です。 さらに詳しい明細についてはセクション4.1.9における、'mimeMediaType'属性構文の記述を見てください。
4.4.19 document-format-supported (1setOf mimeMediaType)
4.4.19 形式が支えたドキュメント(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.
このREQUIRED Printer属性はPrinterオブジェクトと含まれたJobオブジェクトがサポートすることができるドキュメント・フォーマットのセットを特定します。 さらに詳しい明細についてはセクション4.1.9における、'mimeMediaType'属性構文の記述を見てください。
4.4.20 printer-is-accepting-jobs (boolean)
4.4.20 プリンタは仕事を受け入れています。(論理演算子)
deBry, et al. Experimental [Page 108] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[108ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
このREQUIRED Printer属性は、すなわち、プリンタが現在仕事を受け入れることができるかどうかがPrint-仕事、Print URI、およびCreate-仕事の要求を受け入れているのを示します。 値が'本当である'なら、プリンタは仕事を受け入れています。 値が'誤っている'なら、Printerオブジェクトは現在、それに提出されたどんな仕事も拒絶しています。 この場合、Printerオブジェクトは'仕事を受け入れないサーバ誤り'ステータスコードを返します。
Note: 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 may cause the Printer to reject jobs when the "printer-state" is 'idle' or it may cause the Printer object to accepts jobs when the "printer-state" is 'stopped'.
以下に注意してください。 値が現在の仕事に影響しないので、この値は「プリンタ状態」と「プリンタ州理由」属性から独立しています。 むしろそれは今後の仕事に影響します。 Printerはこの属性で「プリンタ状態」がいつ'活動していませんか'、そして、それがPrinterオブジェクトを引き起こすかもしれない仕事を拒絶するかもしれません。「プリンタ状態」が'止められる'仕事を受け入れます。
4.4.21 queued-job-count (integer(0:MAX))
4.4.21 列に並ばせられた仕事のカウント(整数(0: 最大))
This RECOMMENDED 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.
このRECOMMENDED Printer属性は、'未定'の、または、'処理している'か、'未定に保持された'か、'処理で止まっている'仕事の数のカウントを含んでいて、Printerオブジェクトによって設定されます。
4.4.22 printer-message-from-operator (text(127))
4.4.22 オペレータからのプリンタメッセージ(テキスト(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.
このPrinter属性はプリンタのエンドユーザ情報か状態まで示すオペレータ、システム管理者または「知的な」プロセスからメッセージを提供します、それがなぜ入手できないか、そして、またはいつ利用可能であると予想されるのなどように。
4.4.23 color-supported (boolean)
4.4.23 色で、サポートされます。(論理演算子)
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.0).
このPrinter属性は、ハイライト色を含んでいて、デバイスが何かタイプのカラー印刷がいったいできるかどうか特定します。 色と関係があるすべてのドキュメント指示がドキュメントPDLの中で埋め込まれています(なにもはIPP/1.0の外部のIPP属性です)。
Note: end-users are able to determine the nature and details of the color support by querying the "printer-more-info-manufacturer" Printer attribute.
以下に注意してください。 エンドユーザが質問することによって色のサポートの自然と詳細を決定できる、「プリンタ、 より多くのインフォメーションメーカー、」 Printer属性。
4.4.24 reference-uri-schemes-supported (1setOf uriScheme)
4.4.24 uri体系がサポートした参照(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:
このPrinter属性は、どのURI体系がPrint-URIかSend-URI操作の「ドキュメント-uri」操作属性における使用のためにサポートされるかを指定します。 Printerオブジェクトが、これらが任意の操作であるとサポートするなら、少なくとも以下の計画されたURI値で「uri体系がサポートした参照」Printer属性をサポートしなければなりません:
'ftp': The Printer object will use an FTP 'get' operation as
'ftp': オブジェクトがFTP'得'操作を使用するPrinter
deBry, et al. Experimental [Page 109] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[109ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
defined in RFC 2228 [RFC2228] using FTP URLs as defined by
[RFC2396] and[RFC2316].
RFC2228[RFC2228]では、[RFC2396]と[RFC2316]によって定義されるようにFTP URLを使用することで、定義されます。
The Printer object MAY OPTIONALLY support other URI schemes (see section 4.1.6).
PrinterオブジェクトMAY OPTIONALLYは、他のURIが体系であるとサポートします(セクション4.1.6を見てください)。
4.4.25 pdl-override-supported (type2 keyword)
4.4.25 オーバーライドがサポートしたpdl(type2キーワード)
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.
このREQUIRED Printer属性は特定のPrinter実装がIPP属性でドキュメントデータ指示をくつがえすのを試みる能力を言い表します。
This attribute takes on the following 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.
- '試みられる': この値は、Printerオブジェクトが、IPP属性値がドキュメントデータにおける埋め込まれた指示の上で優先させるのを試みるのを示して、しかしながら、保証が全くありません。
- '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.
- '試みられない': この値は、PrinterオブジェクトがIPP属性値に先行を引き継がせる試みを全くドキュメントデータにおける埋め込まれた指示にしないのを示します。
Section 15 contains a full description of how this attribute interacts with and affects other IPP attributes, especially the "ipp-attribute-fidelity" attribute.
セクション15はこの属性がどう他のIPP属性と対話して、影響するかに関する余すところのない解説を含みます、特に「ipp属性信義」属性。
4.4.26 printer-up-time (integer(1:MAX))
4.4.26 プリンタ動作可能時間(整数(1: 最大))
This REQUIRED Printer attribute indicates the amount of time (in seconds) that this instance of this Printer implementation has been up and running. This value is used to populate the Job attributes "time-at-creation", "time-at-processing", and "time-at-completed". These time values are all measured in seconds and all have meaning only relative to this attribute, "printer-up-time". The value is a monotonically increasing value starting from 1 when the Printer object is started-up (initialized, booted, etc.).
このREQUIRED Printer属性はこのPrinter実装のこのインスタンスが活動していることの時間(秒の)を示します。 そして、この値がJob属性「作成における時間」、「処理における時間」に居住するのに使用される、「完成されて、調節する、」 これらの時間的価値はすべて、秒にすべて測定されて、単にこの属性、「プリンタ動作可能時間」に比例して意味を持っています。 値はPrinterオブジェクトが立ち上げられているとき1から始める単調に増加する値(初期化していて、起動させられたなど)です。
If the Printer object goes down at some value 'n', and comes back up, the implementation MAY:
'Printerオブジェクトが何らかの値で落ちる、'、上、実装を支持しに来る、5月:
1. Know how long it has been down, and resume at some value greater
than 'n', or
2. Restart from 1.
1. '何らかの値で、よりすばらしい状態でそれがどれくらい長いかを知って、再開してください、'2 1から、再開してください。
In the first case, the Printer SHOULD not tweak any existing related
Job attributes ("time-at-creation", "time-at-processing", and "time-
at-completed"). In the second case, the Printer object SHOULD reset
そして、前者の場合、Printer SHOULDがどんな既存の関連するJob属性もひねらない、(「作成における時間」、「処理における時間」、「時間、-、完成、」、) 2番目のケース、SHOULDがリセットしたPrinterオブジェクトで
deBry, et al. Experimental [Page 110] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[110ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
those attributes to 0. If a client queries a time-related Job attribute and finds the value to be 0, the client MUST assume that the Job was submitted in some life other than the Printer's current life.
0へのそれらの属性。 クライアントが、時間関連のJob属性について質問して、値が0であることがわかるなら、クライアントは、Printerの現在の寿命以外の何らかの寿命でJobを提出したと仮定しなければなりません。
4.4.27 printer-current-time (dateTime)
4.4.27プリンタ電流時間(dateTime)
This Printer attribute indicates the current absolute wall-clock time. If an implementation supports this attribute, then a client could calculate the absolute wall-clock time each Job's "time-at- creation", "time-at-processing", and "time-at-completed" attributes by using both "printer-up-time" and this attribute, "printer- current-time". If an implementation does not support this attribute, a client can only calculate the relative time of certain events based on the REQUIRED "printer-up-time" attribute.
このPrinter属性は現在の絶対柱時計時間を示します。 そして、実装がこの属性をサポートするならクライアントがそれぞれ絶対柱時計時間について計算するかもしれない、Jobのもの、「時間、-、作成、」 「処理では、調節している」、「完成されて、調節する、」 「プリンタ動作可能時間」とこの属性、「プリンタ現在の時間」の両方を使用するのによる属性。 実装がこの属性をサポートしないなら、クライアントはREQUIRED「プリンタ動作可能時間」属性に基づくあるイベントの相対的な時間について計算できるだけです。
4.4.28 multiple-operation-time-out (integer(1:MAX))
4.4.28 複数の操作タイムアウト(整数(1: 最大))
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 multi-document Job object before taking any recovery actions, such as the ones indicated in section 3.3.1.
このPrinter属性はPrinterオブジェクトが、どんな回復行動も取る前に追加Send-ドキュメントかSend-URI操作がまだ開いているマルチドキュメントJobオブジェクトに続くのを待つ最小の時間(秒の)を特定します、セクション3.3.1で示されたものなどのように。
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. If so, the system administrator MAY be able to set values outside this range.
ベンダーが60〜240秒であるこの属性に値を供給するのは、RECOMMENDEDです。 実装で、システム管理者はこの属性を設定できるかもしれません。 そうだとすれば、システム管理者はこの範囲の外に値を設定できるかもしれません。
4.4.29 compression-supported (1setOf type3 keyword)
4.4.29 圧縮で、サポートされます。(1setOf type3キーワード)
This 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.
このPrinter属性はドキュメントデータのためにサポートしている圧縮アルゴリズムのセットを特定します。 圧縮はドキュメントデータに適用されるだけです。 圧縮はIPP操作自体のコード化に適用されません。 サポートしている値は、Print-仕事、Send-ドキュメント、およびSend-URI要求におけるクライアントの供給された「圧縮」操作属性を有効にするのに使用されます。
Standard values are :
基準値は以下の通りです。
'none': no compression is used.
'deflate': ZIP public domain inflate/deflate) compression
technology
'gzip' GNU zip compression technology described in RFC 1952
[RFC1952].
'compress': UNIX compression technology
'なにも': どんな圧縮も使用されていません。 '空気を抜きます': 公共の場がふくらませるか、または空気を抜かせるZIP) 圧縮技術'gzip'GNUはRFC1952[RFC1952]で説明された圧縮技術をファスナーで閉めます。 '湿布': UNIX圧縮技術
4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX))
4.4.30 八重奏がサポートした仕事k(rangeOfInteger(0: 最大))
deBry, et al. Experimental [Page 111] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[111ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
このPrinter属性はK八重奏における、仕事の総サイズの上下の領域を指定します、すなわち、1024の八重奏のユニットで。 サポートしている値は、操作属性が中に作成するクライアントの供給された「賃仕事のk-八重奏」要求を有効にするのに使用されます。 対応する職務記述書属性「仕事のk八重奏」はセクション4.3.17で定義されます。
4.4.31 job-impressions-supported (rangeOfInteger(0:MAX))
4.4.31 印象がサポートした仕事(rangeOfInteger(0: 最大))
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.18.
このPrinter属性は1仕事あたりの印象の数に上下の領域を指定します。 使用されるクライアントの供給された「仕事印象」操作属性を有効にするサポートしている値は要求を作成します。 対応する職務記述書属性「仕事印象」はセクション4.3.18で定義されます。
4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX))
4.4.32 シートがサポートした仕事のメディア(rangeOfInteger(0: 最大))
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.19.
このPrinter属性は1仕事あたりのメディアシートの数に上下の領域を指定します。 使用されるクライアントの供給された「仕事のメディアシート」操作属性を有効にするサポートしている値は要求を作成します。 「賃仕事のメディアのシート」が定義される対応するJob属性は4.3に.19を区分します。
5. Conformance
5. 順応
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 クライアント順応要件
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 registered extensions and/or private extensions in an operation request, as long as they meet the requirements in Section 6.
従っているクライアントは本書では定義されるようにすべてのREQUIRED操作をサポートしなければなりません。 操作要求に各属性を含むように、従っているクライアントは構文がセクション3と4の指定されるとしてのModelドキュメントの要件にタイプと値を従わせる値を供給しなければなりません。 従っているクライアントは操作要求におけるどんな登録された拡大、そして/または、個人的な拡大も供給するかもしれません、セクション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.
さもなければ、どんなIPPクライアントによって提供されたユーザインタフェースに置かれた順応要件も彼らの利用もありません。 例えば、エンドユーザは1つのアプリケーションで複数の1仕事あたりのドキュメントを提出できないかもしれませんが、別のものはそうします。 1つのアプリケーションが最初に、グラフィカルユーザーインターフェース(GUI)ダイアログボックスにサポートされるのとデフォルト値を供給するためにPrinterオブジェクトについて質問するかもしれませんが、異なった実装は質問しないかもしれません。
deBry, et al. Experimental [Page 112] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[112ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
When sending a request, an IPP client NEED NOT supply any attributes that are indicated as OPTIONALLY supplied by the client.
要求を送るとき、IPPクライアントはクライアントによって供給されたOPTIONALLYとして示されるどんな属性も供給する必要はありません。
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.
クライアントはそれらの最大限の範囲を含む応答でPrinterオブジェクトからそれに返されるかもしれないセクション4.1で定義された属性構文のいずれも受け入れることができなければなりません。 属性構文が'テキスト'であるクライアントサポート、クライアントは'textWithoutLanguage'と'textWithLanguage'という両方のフォームを受け入れて、処理しなければなりません。特に各属性のために、クライアントが属性構文であるとサポートする各属性が'名前'であるのでクライアントが同様に、'nameWithoutLanguage'と'nameWithLanguage'の両方を受け入れて、処理しなければならないのは形成されます。プレゼンテーション目的のために、長い属性値のトランケーションは推薦されません。 お勧めのアプローチはユーザが長い属性値を通してクライアント実装でスクロールすることであることができるでしょう。
A query response may contain attribute groups, attributes, and values 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 extended registered or private attributes and/or attribute values that conform to Section 6. Clients may choose to ignore any parameters, attributes, or values that they do not understand.
質問応答はクライアントが予想しない属性グループ、属性、および値を含むかもしれません。 したがって、クライアント実装は、優雅にそのような応答を扱って、戻っている拡張登録されたか個人的な属性、そして/または、セクション6に従う属性値である従うPrinterと共に共同利用するのを拒否してはいけません。 クライアントが、どんなパラメタ、属性も無視するのを選ぶかもしれませんか、またはそれらがする値は分かりません。
5.2 IPP Object Conformance Requirements
5.2 IPPオブジェクト順応要件
This section specifies the conformance requirements for conforming implementations with respect to objects, operations, and attributes.
このセクションはオブジェクト、操作、および属性に関して実装を従わせるための順応要件を指定します。
5.2.1 Objects
5.2.1 オブジェクト
Conforming implementations MUST implement all of the model objects as defined in this specification in the indicated sections:
実装を従わせると、モデルオブジェクトのすべてが示されたセクションのこの仕様に基づき定義されるように実装しなければなりません:
Section 2.1 - Printer Object
Section 2.2 - Job Object
セクション2.1--プリンタオブジェクト部分2.2--仕事のオブジェクト
5.2.2 Operations
5.2.2 操作
Conforming IPP object implementations MUST implement all of the REQUIRED model operations, including REQUIRED responses, as defined in this specification in the indicated sections:
IPPオブジェクト実装を従わせると、REQUIREDモデル操作のすべてが実装しなければなりません、REQUIRED応答を含んでいて、示されたセクションのこの仕様に基づき定義されるように:
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
Printerに関しては、反対してください: 印刷仕事、任意の状態で印刷URI(セクション3.2.2)を必要とする、(セクション3.2.1)仕事を有効にして(セクション3.2.3)雇用を創り出して(セクション3.2.4)、任意の状態で必要です。
deBry, et al. Experimental [Page 113] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[113ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Get-Printer-Attributes (section 3.2.5) REQUIRED
Get-Jobs (section 3.2.6) REQUIRED
プリンタ属性を得てください、ジョブスを得て(セクション3.2.6)必要である(セクション3.2.5)が必要です。
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
Jobに関しては、反対してください: 仕事の属性を得た状態で必要であるURIを発信させている(セクション3.3.2)ドキュメントを発信させている(セクション3.3.1)任意の任意のキャンセル仕事(セクション3.3.3)(セクション3.3.4)が必要です。
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.
IPPオブジェクトを従わせると、そうだとすれば、そのような属性のすべてのREQUIRED操作属性とすべての値が記述で示された状態でサポートしなければなりません。 IPPオブジェクトを従わせると、すべてのサポートされないか未知の操作属性か要求に受け取られた操作属性グループが無視されなければなりませんが、サポートされない値を含むサポートしている操作属性を含む要求は拒絶されなければなりません。
The following section on object attributes specifies the support required for object attributes.
オブジェクト属性の以下のセクションはオブジェクト属性に必要であるサポートを指定します。
5.2.3 IPP Object Attributes
5.2.3 IPPオブジェクト属性
Conforming IPP objects MUST support all of the REQUIRED object attributes, as defined in this specification in the indicated sections.
IPPオブジェクトを従わせると、REQUIREDオブジェクト属性のすべてが示されたセクションのこの仕様に基づき定義されるようにサポートしなければなりません。
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で説明されたそれらの値だけをサポートしなければなりません。 それはこれらの値のどんな非空の部分集合もサポートするかもしれません。 すなわち、それはそれらを少なくとも規定値の1つと高々皆、サポートしなければなりません。
5.2.4 Extensions
5.2.4 拡大
A conforming IPP object MAY support registered extensions and private extensions, as long as they meet the requirements specified in Section 6.
従っているIPPオブジェクトは登録された拡大と個人的な拡大をサポートするかもしれません、彼らがセクション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.
操作応答に各属性を含むように、従っているIPPオブジェクトは構文がセクション3と4の指定されるとしてのModelドキュメントの要件にタイプと値を従わせる値を返さなければなりません。
deBry, et al. Experimental [Page 114] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[114ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
5.2.5 Attribute Syntaxes
5.2.5 属性構文
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 IPP/1.0). 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.
IPPオブジェクトはセクション4.1で定義された属性構文のどれかを受け入れることができなければなりません、それらの最大限の範囲を含んでいて、クライアントが属性を供給するかもしれないか、またはシステム管理者が属性(IPP/1.0の範囲の外の手段による)を構成するかもしれないどんな操作でも。 特にIPPオブジェクトがサポートする各属性のために、だれの属性構文がIPPが、反対する'テキスト'であり、受け入れて、'textWithoutLanguage'と'textWithLanguage'の両方を処理しなければならないかは形成されます。IPPオブジェクトが属性構文であるとサポートする各属性が'名前'であるのでIPPオブジェクトは、同様に、'nameWithoutLanguage'と'nameWithLanguage'という両方のフォームを受け入れて、処理しなければなりません; その上、IPPオブジェクトはセクション4.1で指定された構文に従う操作応答で属性をクライアントに返さなければなりません、以前にクライアントによって供給されるならそれらの最大限の範囲を含んでいて。
5.3 Charset and Natural Language Requirements
5.3 Charsetと自然言語要件
All clients and IPP objects MUST support the 'utf-8' charset as defined in section 4.1.7.
すべてのクライアントとIPPオブジェクトは、セクション4.1.7で定義されるように'utf-8'がcharsetであるとサポートしなければなりません。
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オブジェクトは自然言語がIPPオブジェクトによってサポートされるか否かに関係なく、どんな個々の属性でも正しく「属性自然言語」操作属性かNatural Language Overrideメカニズムを使用するどんなクライアント要求も受け入れることができなければなりません。 IPPオブジェクトが自然言語をサポートするなら、'テキスト'か'名前'属性値であると生成されたすべてをサポートされた言語の1つに翻訳できなければなりません(恐らく索表で)(セクション3.1.4を見てください)。 すなわち、自然言語をサポートするIPPオブジェクトはクライアントによってその自然言語に供給されたどんな任意の'テキスト'か'名前'価値の汎用の翻訳者である必要はありません。 しかしながら、オブジェクトが翻訳できなければならない、(自動的に生成する、)、自分自身ののいずれも値とメッセージをその自然言語の結果と考えます。
5.4 Security Conformance Requirements
5.4 セキュリティ順応要件
Conforming IPP Printer objects MAY support Secure Socket Layer Version 3 (SSL3) [SSL] access, support access without SSL3 or support both means of access.
IPP Printerオブジェクトを従わせるのは、Secure Socket Layerバージョン3(SSL3)[SSL]がアクセスであるとサポートするかもしれません、SSL3のないアクセスかサポートの両方が意味するアクセサリーのサポート
Conforming IPP clients SHOULD support SSL3 access and non-SSL3 access. Note: This client requirement to support both means that conforming IPP clients will be able to inter-operate with any IPP Printer object.
IPPクライアントSHOULDサポートSSL3アクセスと非SSL3アクセサリーを従わせます。 以下に注意してください。 両方をサポートするというこのクライアント要件は、IPPクライアントを従わせるのがどんなIPP Printerオブジェクトでも共同利用できることを意味します。
deBry, et al. Experimental [Page 115] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[115ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
For a detailed discussion of security considerations and the IPP application security profile required for SSL3 support, see section 8.
セキュリティ問題の詳細な論議とSSL3サポートに必要であるIPPアプリケーションセキュリティプロフィールに関しては、セクション8を見てください。
6. IANA Considerations (registered and private extensions)
6. IANA問題(登録されて個人的な拡大)
This section describes how IPP can be extended to allow the following registered and private extensions to IPP:
このセクションは以下の登録されて個人的な拡大をIPPに許すためにどうIPPを広げることができるかを説明します:
1. keyword attribute values
2. enum attribute values
3. attributes
4. attribute syntaxes
5. operations
6. attribute groups
7. status codes
1. 3つの属性4属性構文5操作6属性グループ7状態がコード化するキーワード属性値2enum属性値
Extensions registered for use with IPP/1.0 are OPTIONAL for client and IPP object conformance to the IPP/1.0 Model specification.
使用のためにIPP/1.0に示された拡張子は、IPP/1.0Model仕様へのクライアントのためのOPTIONALとIPPオブジェクト順応です。
These extension procedures are aligned with the guidelines as set forth by the IESG [RFC2434]. 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. IPP/1.0 may also be extended by an appropriate RFC that specifies any of the above extensions.
IESG[RFC2434]によって詳しく説明されるようにこれらの拡張の手順はガイドラインに並べられます。 セクション11は考慮のための新しい登録証明書を提案する方法を説明します。 IANAは必須情報を省く登録提案を拒絶するか、またはセクション11で説明された適切な形式に続きません。 また、IPP/1.0は上の拡大のいずれも指定する適切なRFCによって広げられるかもしれません。
6.1 Typed 'keyword' and 'enum' Extensions
6.1 タイプされた'キーワード'と'enum'拡大
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が'キーワード'と'enum'拡大を考慮する、(セクション4.1.2を見てください、.3、4.1 .4)。 このドキュメントは、名前を通してその他の情報を読者に伝えるのに'キーワード'と'enum'基本的な属性構文タイプに接頭語を使用します。 それがクライアントかPrinterオブジェクトに重要でないので、このその他の情報はプロトコルで表されません。 以下のリストは接頭語とそれらの意味について説明します。
"type1": The IPP specification must be revised to add a new
keyword or a new enum. No private keywords or enums are
allowed.
「type1":」 新しいキーワードか新しいenumを加えるためにIPP仕様を改訂しなければなりません。 どんな個人的なキーワードもenumsも許容されていません。
"type2": Implementers can, at any time, add new keyword or enum
values by proposing the complete specification to IANA:
「type2":」 Implementersはいつでも、完全な仕様をIANAに提案することによって、新しいキーワードかenum値を加えることができます:
iana@iana.org
iana@iana.org
deBry, et al. Experimental [Page 116] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[116ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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はDesignated Expertがこのために保つメーリングリストで提案を見直すIPP Designated Expertに登録提案を送るでしょう。 初めは、そのリストはIPP WGによって使用されたメーリングリストになるでしょう:
ipp@pwg.org
ipp@pwg.org
even after the IPP WG is disbanded as permitted by [RFC2434].
The IPP Designated Expert is appointed by the IESG Area Director
responsible for IPP, according to [RFC2434].
[RFC2434]によって受入れられるようにIPP WGが解散された後にさえ。 IPP Designated Expertは[RFC2434]に従ってIPPに責任があるIESG Areaディレクターによって任命されます。
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.
type2キーワードかenumが承認されているとき、IPP Designated Expertはその登録に必要である今後のメインテナンスのための連絡先になります。
"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は、いつでも、提案をIPP Designated Expertに送るtype2のように完全な仕様をIANAに提出することによって、新しいキーワードとenum値を加えることができます。 どんな追加技術審査も必要でない間、その人の裁量では、IPP Designated Expertがアドバイスとコメントのためのtype2登録証明書のように同じメーリングリストに提案を送るかもしれません。
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.
type3キーワードかenumがIPP Designated Expertによって承認されるとき、オリジナルの提案者はその登録に必要である今後のメインテナンスのための連絡先になります。
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.
type2とtype3キーワードに関しては、提案者は登録提案でキーワードの名前を入れます、そして、名前は技術審査の一部です。
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.
type2とtype3 enums仕様が承認されていた後に、IANAとの相談におけるIPP Designated Expertはそれぞれのenum値の次の有効なenum番号を割り当てます。
IANA will publish approved type2 and type3 keyword and enum attributes value registration specifications in:
IANAは承認されたtype2を発行するでしょう、そして、type3キーワードとenum属性は以下で登録仕様を評価します。
ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
ftp.isi.edu/iana/課題/ipp/属性値/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
xxxがどこの初期の値とyyy.txtを指定する属性名であるかは、1enumsを含む描写的であるファイル名か同時に承認されたキーワードです。 とめのための数個の追加enumsが使用のために例えば承認されます。
deBry, et al. Experimental [Page 117] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[117ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
"finishings" attribute (and "finishings-default" and "finishings- supported" attributes), IANA will publish the additional values in the file:
「仕上げ」属性(そして、「仕上げデフォルト」と「サポートされた仕上げ」属性)、IANAはファイルの加算値を発行するでしょう:
ftp.isi.edu/iana/assignments/ipp/attribute-
values/finishings/stapling.txt
ftp.isi.edu/iana/課題/ipp/属性値/仕上げ/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.
以下に注意してください。 いくつかの属性が、である:なるように定義されます。 'type3キーワード'| 属性値が管理者と共にサイトの管理者によって広げられるのを許容する'名前'が名前を定義しました。 そのような名前はIANAに登録されません。
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.
定義上、上のタイプ3人の各人が、拡大が有効であると考えられるためにある種の登録か吟味の過程を断言します。 それぞれのより高い番号付のレベル(1、2、3)は、前のレベルよりだんだん少なく厳しくない傾向があります。 したがって、どんなtypeN値も、MがNである、しかしながら、そのような登録がNOT REQUIREDであるいくらかのtypeMのためにプロセスを使用することで示されるかもしれません。 例えば、タイプ1方法(IPP仕様の将来のバージョンに含まれているのによる)でtype3値は示されるかもしれなくて、しかしながら、それはNOT REQUIREDです。
This specification defines keyword and enum values for all of the above types, including type3 keywords.
この仕様はtype3キーワードを含む上のタイプのすべてのためにキーワードとenum値を定義します。
For private (unregistered) keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-" where xxx 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 private keyword 'abc' would be: 'xyz.com-abc'.
For private (unregistered) keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-" where xxx 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 private 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 private (unregistered) enum extension, implementers MUST use values in the reserved integer range which is 2**30 to 2**31-1.
For private (unregistered) enum extension, implementers MUST use values in the reserved integer range which is 2**30 to 2**31-1.
deBry, et al. Experimental [Page 118] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 118] RFC 2566 IPP/1.0: Model and Semantics April 1999
6.2 Attribute Extensibility
6.2 Attribute Extensibility
Attribute names 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 private (unregistered) attribute extensions, implementers SHOULD use keywords with a suitable distinguishing prefix as described in Section 6.1.
Attribute names 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 private (unregistered) 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.
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 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 value codes that identify each of the attribute syntaxes are assigned in the Encoding and Transport specification [RFC2565], including a designated range for private, experimental use.
Attribute syntaxes 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 value codes that identify each of the attribute syntaxes are assigned in the Encoding and Transport specification [RFC2565], including a designated range for private, experimental use.
For attribute syntaxes, the IPP Designated Expert in consultation with IANA assigns the next attribute syntax code in the appropriate range as specified in [RFC2565]. 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 [RFC2565]. 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.
deBry, et al. Experimental [Page 119] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 119] RFC 2566 IPP/1.0: Model and Semantics April 1999
6.4 Operation Extensibility
6.4 Operation Extensibility
Operations 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 private (unregistered) operation extensions, implementers MUST use the range for the "operation-id" in requests specified in Section 4.4.13 "operations-supported" Printer attribute.
Operations 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 private (unregistered) operation extensions, implementers MUST use the range for the "operation-id" in requests specified in Section 4.4.13 "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.13. 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.13. IANA will publish approved operation registration specifications as separate files:
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 Groups
6.5 Attribute Groups
Attribute groups passed in requests and responses may be registered following the type2 procedures described in Section 6.1. The tags that identify each of the attribute groups are assigned in [RFC2565].
Attribute groups passed in requests and responses may be registered following the type2 procedures described in Section 6.1. The tags that identify each of the attribute groups are assigned in [RFC2565].
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 [RFC2565]. 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 [RFC2565]. 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 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 13 for each status code class:
Operation status codes 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 13 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
"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
deBry, et al. Experimental [Page 120] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 120] RFC 2566 IPP/1.0: Model and Semantics April 1999
"server-error" - The IPP object failed to fulfill an apparently
valid request
"server-error" - The IPP object failed to fulfill an apparently valid request
For private (unregistered) operation status code extensions, implementers MUST use the top of each range as specified in Section 13.
For private (unregistered) 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
where "xxx-yyy" is the new operation status code keyword.
where "xxx-yyy" is the new operation status code keyword.
6.7 Registration of MIME types/sub-types for document-formats
6.7 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.8 Registration of charsets for use in 'charset' attribute values
6.8 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
- requests the charset and natural language for attributes returned
by the IPP object in operation responses (as described in Section
3.1.4.1).
- identifies the charset and natural language of the request which affects each supplied 'text' and 'name' attribute value, and - requests the charset and natural language for attributes returned by the IPP object in operation responses (as described in Section 3.1.4.1).
deBry, et al. Experimental [Page 121] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 121] RFC 2566 IPP/1.0: Model and Semantics April 1999
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 ' text' and 'name' attributes, an IPP object MUST accept ALL supplied natural languages. Just because a Printer object is currently
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 ' text' and 'name' attributes, an IPP object MUST accept ALL supplied natural languages. Just because a Printer object is currently
deBry, et al. Experimental [Page 122] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 122] RFC 2566 IPP/1.0: Model and Semantics April 1999
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'.
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
respond using the value of the "natural-language-configured"
attribute (using the Natural Language Override mechanism if
needed).
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 respond using the value of the "natural-language-configured" attribute (using the Natural Language Override mechanism if needed).
deBry, et al. Experimental [Page 123] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 123] RFC 2566 IPP/1.0: Model and Semantics April 1999
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:
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:
Attributes Source
-------------------------- ----------
Operation Attributes
job-name (name) client
document-name (name) client
requesting-user-name (name) client
status-message Job or Printer object
Attributes Source -------------------------- ---------- Operation Attributes job-name (name) client document-name (name) client requesting-user-name (name) client status-message Job or Printer object
Job Template Attributes:
job-hold-until) client matches administrator-configured
(keyword | name
job-hold-until-default client matches administrator-configured
(keyword | name)
job-hold-until-supported client matches administrator-configured
(keyword | name)
job-sheets client matches administrator-configured
(keyword | name)
job-sheets-default client matches administrator-configured
(keyword | name)
job-sheets-supported client matches administrator-configured
(keyword | name)
media client matches administrator-configured
(keyword | name)
media-default client matches administrator-configured
(keyword | name)
media-supported client matches administrator-configured
(keyword | name)
media-ready client matches administrator-configured
(keyword | name)
Job Template Attributes: job-hold-until) client matches administrator-configured (keyword | name job-hold-until-default client matches administrator-configured (keyword | name) job-hold-until-supported client matches administrator-configured (keyword | name) job-sheets client matches administrator-configured (keyword | name) job-sheets-default client matches administrator-configured (keyword | name) job-sheets-supported client matches administrator-configured (keyword | name) media client matches administrator-configured (keyword | name) media-default client matches administrator-configured (keyword | name) media-supported client matches administrator-configured (keyword | name) media-ready client matches administrator-configured (keyword | name)
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
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 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 (text(127)) operator
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 (text(127)) operator
deBry, et al. Experimental [Page 124] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 124] RFC 2566 IPP/1.0: Model and Semantics April 1999
8. Security Considerations
8. Security Considerations
Some IPP objects MAY be deployed over protocol stacks that support Secure Socket Layer Version 3 (SSL3) [SSL]. Note: SSL3 is not an IETF standards track specification. Other IPP objects MAY be deployed over protocol stacks that do not support SSL3. Some IPP objects MAY be deployed over both types of protocol stacks. Those IPP objects that support SSL3, are capable of supporting mutual authentication as well as privacy of messages via multiple encryption schemes. An important point about security related information for SSL3 access to an IPP object, is that the security-related parameters (authentication, encryption keys, etc.) are "out-of-band" to the actual IPP protocol.
Some IPP objects MAY be deployed over protocol stacks that support Secure Socket Layer Version 3 (SSL3) [SSL]. Note: SSL3 is not an IETF standards track specification. Other IPP objects MAY be deployed over protocol stacks that do not support SSL3. Some IPP objects MAY be deployed over both types of protocol stacks. Those IPP objects that support SSL3, are capable of supporting mutual authentication as well as privacy of messages via multiple encryption schemes. An important point about security related information for SSL3 access to an IPP object, is that the security-related parameters (authentication, encryption keys, etc.) are "out-of-band" to the actual IPP protocol.
An IPP object that does not support SSL3 MAY elect to support a transport layer that provides other security mechanisms. For example, in a mapping of IPP over HTTP/1.1 [RFC2565], if the IPP object does not support SSL3, HTTP still allows for client authentication using Digest Access Authentication (DAA) [RFC2069].
An IPP object that does not support SSL3 MAY elect to support a transport layer that provides other security mechanisms. For example, in a mapping of IPP over HTTP/1.1 [RFC2565], if the IPP object does not support SSL3, HTTP still allows for client authentication using Digest Access Authentication (DAA) [RFC2069].
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.
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.
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.
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.
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.0, 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.
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.0, 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.
deBry, et al. Experimental [Page 125] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 125] RFC 2566 IPP/1.0: Model and Semantics April 1999
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.
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.
Since the security levels or the specific threats that any given 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. SSL3 supports the type of negotiated levels of security required by most, if not all, potential IPP environments. IPP environments that require no security can elect to deploy IPP objects that do not utilize the optional SSL3 security mechanisms.
Since the security levels or the specific threats that any given 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. SSL3 supports the type of negotiated levels of security required by most, if not all, potential IPP environments. IPP environments that require no security can elect to deploy IPP objects that do not utilize the optional SSL3 security mechanisms.
8.1 Security Scenarios
8.1 Security Scenarios
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.
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.
8.1.1 Client and Server in the Same Security Domain
8.1.1 Client and Server in the Same Security Domain
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.
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 Client and Server in Different Security Domains
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,
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,
deBry, et al. Experimental [Page 126] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 126] RFC 2566 IPP/1.0: Model and Semantics April 1999
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.
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.
8.1.3 Print by Reference
8.1.3 Print by Reference
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. 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" will not be specified for version 1 of IPP.
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. 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" will not be specified for version 1 of IPP.
8.2 URIs for SSL3 and non-SSL3 Access
8.2 URIs for SSL3 and non-SSL3 Access
As described earlier, an IPP object can support SSL3 access, non-SSL3 access, or both. 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.
As described earlier, an IPP object can support SSL3 access, non-SSL3 access, or both. 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.
8.3 The "requesting-user-name" (name(MAX)) Operation Attribute
8.3 The "requesting-user-name" (name(MAX)) Operation Attribute
Each operation MUST specify the user who is performing the operation in both of the following two ways:
Each operation MUST specify the user who is performing the operation in both of the following two ways:
1) via the REQUIRED "requesting-user-name" operation attribute that
a client SHOULD supply in all operations. The client MUST obtain
the value for this attribute from an environmental or network
login name for the user, rather than allowing the user to supply
any value. If the client does not supply a value for
"requesting-user-name", the printer MUST assume that the client
is supplying some anonymous name, such as "anonymous".
2) via an authentication mechanism of the underlying transport
which may be configured to give no authentication information.
1) via the REQUIRED "requesting-user-name" operation attribute that a client SHOULD supply in all operations. The client MUST obtain the value for this attribute from an environmental or network login name for the user, rather than allowing the user to supply any value. If the client does not supply a value for "requesting-user-name", the printer MUST assume that the client is supplying some anonymous name, such as "anonymous". 2) via an authentication mechanism of the underlying transport which may be configured to give no authentication information.
deBry, et al. Experimental [Page 127] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry, et al. Experimental [Page 127] RFC 2566 IPP/1.0: Model and Semantics April 1999
There are six cases to consider:
There are six cases to consider:
a) the authentication mechanism gives no information, and the
client doesn't specify "requesting-user-name".
b) the authentication mechanism gives no information, but the
client specifies "requesting-user-name".
c) the authentication mechanism specifies a user which has no human
readable representation, and the client doesn't specify
"requesting-user-name".
d) the authentication mechanism specifies a user which has no human
readable representation, but the client specifies "requesting-
user-name".
e) the authentication mechanism specifies a user which has a human
readable representation. The Printer object ignores the
"requesting-user-name".
f) the authentication mechanism specifies a user who is trusted and
whose name means that the value of the "requesting-user-name",
which MUST be present, is treated as the authenticated name.
認証機構は情報を全く教えません、そして、クライアントは「要求しているユーザ名」を指定しません。a) b) 認証機構は情報を全く教えません; しかし、クライアントは「要求しているユーザ名」を指定します。c) 認証機構はユーザを指定します、そして、(どんな人間の読み込み可能な表現もありません)クライアントは「要求しているユーザ名」を指定しません。d) 認証機構はユーザを指定しますが、(どんな人間の読み込み可能な表現もありません)クライアントは、「ユーザ名を要求し」ながら、指定します。e) 認証機構はユーザを指定します(人間の読み込み可能な表現があります)。 Printerオブジェクトは「要求しているユーザ名」を無視します。f) 認証機構は信じられて、名前が、存在しなければならない「要求しているユーザ名」の値が認証された名前として扱われることを意味するユーザを指定します。
Note: Case "f" is intended for a tightly coupled gateway and server to work together so that the "user" name is able to be that of the gateway client and not that of the gateway. Because most, if not all, system vendors will initially implement IPP via a gateway into their existing print system, this mechanism is necessary unless the authentication mechanism allows a gateway (client) to act on behalf of some other client.
以下に注意してください。 ケース「f」が密結合ゲートウェイとサーバを一緒に働かせることを意図するので、「ユーザ」名はゲートウェイのものではなく、ゲートウェイクライアントのものであることをできます。 システムベンダーがすべてでないなら、初めはそれらの既存の印刷システムへのゲートウェイを通してIPPを最も実装するので、ゲートウェイ(クライアント)が認証機構である他のクライアントを代表して作動しない場合、このメカニズムが必要です。
The user-name has two forms:
ユーザ名には、2つのフォームがあります:
- one that is human readable: it is held in the REQUIRED "job-
originating-user-name" Job Description attribute which is set
during the job creation operations. It is used for presentation
only, such as returning in queries or printing on start sheets
- one for authorization: it is held in an undefined (by IPP) Job
object attribute which is set by the job creation operation. It
is used to authorize other operations, such as Send-Document,
Send-URI, Cancel-Job, to determine the user when the "my-jobs"
attribute is specified with Get-Jobs, and to limit what
attributes and values to return with Get-Job-Attributes and Get-
Jobs.
- 読み込み可能な状態で人間であるもの: それは雇用創出操作の間に設定されるREQUIRED「仕事の起因するユーザ名」Job記述属性で保持されます。 それは承認のための質問で戻るか、または始めのときにシート--1つを印刷などなどのプレゼンテーションだけに使用されます: それは雇用創出操作で設定される未定義(IPPによる)の仕事のオブジェクト属性で保持されます。 それがSend-ドキュメント、Send-URI、キャンセル仕事などの他の操作がユーザのためにいつかを決定するのを認可するのに使用される、「私、-、仕事、」 属性がGet-ジョブスと共に指定されて、何が、Get仕事の属性とGet仕事とともに帰るのを限界に、結果と考えて、評価しますか?
The human readable user name:
人間の読み込み可能なユーザ名:
- is the value of the "requesting-user-name" for cases b, d and f.
- comes from the authentication mechanism for case e
- is some anonymous name, such as "anonymous" for cases a and c.
- ケースのための「要求しているユーザ名」の値は、bと、dとfですか? - 来る、ケースeのための認証機構--ケースにおける「匿名」としてそのような何らかの匿名の名前が、aとcですか?
The user name used for authorization:
承認に使用されるユーザ名:
deBry, et al. Experimental [Page 128] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[128ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
- is the value of the "requesting-user-name" for cases b and f.
- comes from the authentication mechanism for cases c, d and e
- is some anonymous name, such as "anonymous" for case a.
- ケースbとfのための「要求しているユーザ名」が値がありますか? - 来る、ケースc、d、およびeのための認証機構--ケースにおける「匿名」としてそのような何らかの匿名の名前がaですか?
The essence of these rules for resolving conflicting sources of user-names is that a printer implementation is free to pick either source as long as it achieves consistent results. That is, if a user uses the same path for a series of requests, the requests MUST appear to come from the same user from the standpoint of both the human- readable user name and the user name for authorization. This rule MUST continue to apply even if a request could be authenticated by two or more mechanisms. It doesn't matter which of several authentication mechanisms a Printer uses as long as it achieves consistent results. If a client uses more than one authentication mechanism, it is recommended that an administrator make all credentials resolve to the same user and user-name as much as possible.
ユーザ名の闘争している源を決議するためのこれらの規則の本質は一貫した結果を獲得する限り、プリンタ実装が自由にどちらのソースも選ぶことができるということです。 すなわち、ユーザが一連の要求に同じ経路を使用するなら、要求は同じユーザから人間の読み込み可能なユーザ名と承認のためのユーザ名の両方の見地から来るように見えなければなりません。 2つ以上のメカニズムで要求を認証できても、この規則は、適用し続けなければなりません。一貫した結果を獲得する限り、Printerが数個の認証機構のどれを使用するかは重要ではありません。 クライアントが1台以上の認証機構を使用するなら、それはそれに推薦されます。すべての資格証明書が同じユーザとユーザ名にできるだけ決議する管理者造。
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 Queries on jobs submitted using non-IPP protocols
仕事の8.5の質問が、非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
それが一層のRECOMMENDEDである、IPP Printerが「仕事イド」と「仕事-uri」を生成するのがそのようなもののために「外国仕事」を評価します、できれば、それらが他のIPP操作の目標であることができるように、Get仕事の属性やキャンセル仕事のように。 また、そのような実装は、そのような外国仕事の認証の問題に対処する必要があります。 1つのアプローチはIPPクライアントのユーザ以外のユーザに属すようなすべての外国仕事を扱うだろうことです。 別のアプローチはあるでしょう。
deBry, et al. Experimental [Page 129] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[129ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
'匿名'に属する外国仕事。 IPPクライアントがIPP Printerオブジェクトのオペレータか管理者として認証された場合にだけ、外国仕事はIPP要求で質問されるかもしれませんか? あるいはまた、また、安全保障政策がユーザが他のユーザの仕事について質問するのを許容することであるなら、エンドユーザIPPクライアントにとって、外国仕事もGet-仕事とGet仕事の属性を使用するのにおいて目に見えるでしょう。
8.6 IPP Security Application Profile for SSL3
8.6 SSL3のためのIPPセキュリティアプリケーションプロフィール
The IPP application profile for SSL3 follows the "Secure Socket Layer" requirement as documented in the SSL3 specification [SSL]. For interoperability, the SSL3 cipher suites are:
SSL3のためのIPPアプリケーションプロフィールはSSL3仕様[SSL]に記録されるように「Secure Socket Layer」要件に続きます。 相互運用性のために、SSL3暗号スイートは以下の通りです。
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_NULL_MD5
___デス_CBC_SHA SSL_RSA_と_3DES_エーデCBC_SHA SSL_RSA_とMD5 SSL_RSA_が_ヌル_MD5と共に_RC2_CBC_40_MD5 SSL_RSA_と_RC4_40_MD5 SSL_RSA_輸出_で_をエクスポートするRC4_128_とSSL_RSA_
Client implementations MUST NOT assume any other cipher suites are supported by an IPP Printer object.
クライアント実装は、いかなる他の暗号スイートもIPP Printerオブジェクトによって支えられると仮定してはいけません。
If a conforming IPP object supports SSL3, it MUST implement and support the cipher suites listed above and MAY support additional cipher suites.
従っているIPPオブジェクトがSSL3をサポートするなら、それは、スイートが上に記載して、サポートするかもしれない暗号に追加暗号スイートを実装して、支えなければなりません。
A conforming IPP client SHOULD support SSL3 including the cipher suites listed above. A conforming IPP client MAY support additional cipher suites.
SHOULDが暗号スイートを含むSSL3をサポートする従っているIPPクライアントは上に記載しました。 従っているIPPクライアントは、追加暗号がスイートであるとサポートするかもしれません。
It is possible that due to certain government export restrictions some non-compliant versions of this extension could be deployed. Implementations wishing to inter-operate with such non-compliant versions MAY offer the SSL_RSA_EXPORT_WITH_RC4_40_MD5 and SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 mechanisms. However, since 40 bit ciphers are known to be vulnerable to attack by current technology, any client which actives a 40 bit cipher MUST NOT indicate to the user that the connection is completely secure from eavesdropping.
ある政府輸出制限のため、この拡大のいくつかの不従順なバージョンを配布することができたのは可能です。 そのような不従順なバージョンで共同利用したがっている実装は_40_MD5とSSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5メカニズムをSSL_RSA_EXPORT_WITH_RC4に申し出るかもしれません。40ビットの暗号が現在の技術、どんなクライアントのそばでもどの能動態を攻撃するかために被害を受け易いのが知られているので、しかしながら、40ビットの暗号は、接続が盗聴から完全に安全であることをユーザに示してはいけません。
deBry, et al. Experimental [Page 130] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[130ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
9. References
9. 参照
[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の仕様です。
[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インチ、10月1996日の ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/ overview.ps.gzに頭文字をつけます」。
[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. and C. Manros, "Internet Printing
Protocol/1.0: Implementer's Guide", Work in Progress.
[ipp-iig] ヘイスティングズとT.とC.Manros、「プロトコル/1.0に以下を印刷するインターネット」 「Implementerのガイド」、進行中で、働いてください。
[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.、「ドメイン名--、実装AND仕様、」、STD13、RFC1035、11月1987日
deBry, et al. Experimental [Page 131] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[131ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
[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月。
[RFC1179] McLaughlin, L. (Editor), "Line Printer Daemon Protocol",
RFC 1179, August 1990.
[RFC1179]マクラフリン、L.(エディタ)、「ラインプリンタデーモンプロトコル」、RFC1179、1990年8月。
[RFC1952] Deutsch, P., "GZIP file format specification version
4.3", RFC 1952, May 1996.
ドイツ語、P.、[RFC1952]「GZIPは1996年5月に書式仕様バージョン4.3インチ、RFC1952をファイルします」。
[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月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T.
Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC 2068, January 1997.
[RFC2068] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to
HTTP: Digest Access Authentication", RFC 2069, January
1997.
[RFC2069] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、流し台、E.、およびL.スチュワート、「HTTPへの拡大:」 「ダイジェストアクセス認証」、RFC2069、1997年1月。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages" RFC 2277, January 1998.
[RFC2277]Alvestrand、1998年1月のH.、「文字コードと言語に関するIETF方針」RFC2277。
[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。
deBry, et al. Experimental [Page 132] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[132ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
[RFC2565]エリオ、R.、バトラー、S.、ムーア、P.、およびR.チューナー、「インターネット印刷プロトコル/1.0:」 「コード化と輸送」、RFC2565、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月の原文のコンベンション。」
[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 」
deBry, et al. Experimental [Page 133] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[133ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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. El Segundo, CA 90245
エルセガンド、トムヘイスティングズゼロックス社737のハワイ通りカリフォルニア 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 Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
ロバートエリオゼロックス社3400のHillview Ave、パロアルト、Bldg#1カリフォルニア 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
deBry, et al. Experimental [Page 134] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[134ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 Mailing List: ipp@pwg.org IPP Mailing List Subscription: ipp-request@pwg.org IPP Web Page: http://www.pwg.org/ipp/
IPPメーリングリスト: ipp@pwg.org IPPメーリングリスト購読: ipp-request@pwg.org IPPウェブページ: http://www.pwg.org/ipp/
Implementers of this specification 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が明確化問題のどんな議論と追加属性と値のための登録提案のレビューにも参加するためにIPP Mailing Listを接合するよう奨励されます。
Other Participants:
他の関係者:
Chuck Adams - Tektronix
Jeff Barnett - IBM
Ron Bergman - Dataproducts Corp.
Sylvan Butler - HP
Keith Carter - IBM Corporation
Jeff Copeland - QMS
Andy Davidson - Tektronix
Mabry Dozier - QMS
Lee Farrell - Canon Information Systems
Steve Gebert - IBM
Babek Jahromi - Microsoft
David Kellerman - Northlake Software
Rick Landau - Digital
Greg LeClair - Epson
Harry Lewis - IBM
Pete Loya - HP
Ray Lutz - Cognisys
Mike MacKay - Novell, Inc.
Daniel Manchala - Xerox
Carl-Uno Manros - Xerox
Jay Martin - Underscore
Larry Masinter - Xerox
Stan McConnell - Xerox
Ira McDonald - High North Inc.
Paul Moore - Microsoft
Tetsuya Morita - Ricoh
Yuichi Niwa - Ricoh
Pat Nogay - IBM
チャック・アダムス--テクトロニクスのジェフ・バーネット--IBMのロンバーグマン--Dataproductsの社の森のバトラー--hpキース・カーター--IBMの社のジェフ・コープランド--QMSアンディ・ディヴィッドソン--テクトロニクスのメイブリー・ドージア--QMSリー・ファレル--教会法情報システムスティーブ・ゲーベルト--IBM Babek Jahromi--マイクロソフトのデヴィッド・ケラーマン--Northlakeソフトウェアリック・ランドー--デジタルグレッグ・ルクレア--エプソンのハリー・ルイス--IBMピートLoya--hpレイ・ルッツ--Cognisysマイク・マッケイ--ノベルInc; ポール・ムーア--マイクロソフトのTetsuya森田--リコーYuichi丹羽--リコーパットNogay--ダニエルManchala--ゼロックスカール-宇野Manros--ゼロックスのジェイ・マーチン--強調ラリーMasinter--ゼロックスのスタン・マッコネール--ゼロックスのイラ・マクドナルド--高北の株式会社IBM
deBry, et al. Experimental [Page 135] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[135ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Ron Norton - Printronics
Bob Pentecost - HP
Rob Rhoads - Intel
Xavier Riley - Xerox
David Roach - Unisys
Stuart Rowley - Kyocera
Hiroyuki Sato - Canon
Bob Setterbo - Adobe
Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark
Randy Turner - Sharp
Atsushi Yuki - Kyocera
Rick Yardumian - Xerox
Lloyd Young - Lexmark
Bill Wagner - DPI
Jim Walker - DAZEL
Chris Wellens - Interworking Labs
Rob Whittle - Novell, Inc.
Don Wright - Lexmark
Peter Zehler - Xerox
Steve Zilles - Adobe
Ron Norton - Printronics Bob Pentecost - HP Rob Rhoads - Intel Xavier Riley - Xerox David Roach - Unisys Stuart Rowley - Kyocera Hiroyuki Sato - Canon Bob Setterbo - Adobe Devon Taylor - Novell, Inc. Mike Timperman - Lexmark Randy Turner - Sharp Atsushi Yuki - Kyocera Rick Yardumian - Xerox Lloyd Young - Lexmark Bill Wagner - DPI Jim Walker - DAZEL Chris Wellens - Interworking Labs Rob Whittle - Novell, Inc. Don Wright - Lexmark Peter Zehler - Xerox Steve Zilles - Adobe
11. Formats for IPP Registration Proposals
11. IPPのために、登録提案をフォーマットします。
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:
登録のためのIPP拡張子を提案するために、提案者はIANAウェブページ( http://www.iana.org )で" iana@iana.org "へのメールか適切な書類に書き込むことによって、IANAに願書を出さなければなりません。 このセクションは以下としてセクション6に提供するように拡大の登録証明書をIPPに提案するのに必須情報と形式を指定します。
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
1. 5つの属性6属性構文7操作8状態がコード化するtype2'キーワード'属性値2type3'キーワード'属性値3type2'enum'属性値4type3'enum'属性値
11.1 Type2 keyword attribute values registration
11.1 Type2キーワード属性値登録
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:
登録のタイプ: 加えられるこのキーワード仕様がことである属性のtype2キーワード属性値Name: このキーワード価値の提案されたキーワード名: このキーワード価値(IPP Modelセクション4.1.2.3のスタイルに続く)の仕様: 提案者の名前:
deBry, et al. Experimental [Page 136] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[136ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Address of proposer: Email address of proposer:
提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 Designated Expertは承認された登録仕様のためにtype2キーワードに関しては、連絡先になるでしょう、何か登録仕様のメインテナンスが必要であるなら。
11.2 Type3 keyword attribute values registration
11.2 Type3キーワード属性値登録
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:
登録のタイプ: 加えられるこのキーワード仕様がことである属性のtype3キーワード属性値Name: このキーワード価値の提案されたキーワード名: このキーワード価値(IPP Modelセクション4.1.2.3のスタイルに続く)の仕様: 提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 提案者は承認された登録仕様のためにtype3キーワードに関しては、連絡先になるでしょう、何か登録仕様のメインテナンスが必要であるなら。
11.3 Type2 enum attribute values registration
11.3 Type2 enum属性値登録
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): 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:
登録のタイプ: 加えられるこのenum仕様がことである属性のtype2 enum属性値Name: このenum価値のキーワード英字名: 数値(IANAとの相談でIPP Designated Expertによって割り当てられる): このenum価値(IPP Modelセクション4.1.4のスタイルに続く)の仕様: 提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 Designated Expertは承認された登録仕様のためにtype2 enumsに関しては、連絡先になるでしょう、何か登録仕様のメインテナンスが必要であるなら。
11.4 Type3 enum attribute values registration
11.4 Type3 enum属性値登録
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):
登録のタイプ: 加えられるこのenum仕様がことである属性のtype3 enum属性値Name: このenum価値のキーワード英字名: 数値(IANAとの相談でIPP Designated Expertによって割り当てられる): このenum価値(IPP Modelセクション4.1.4のスタイルに続く)の仕様:
deBry, et al. Experimental [Page 137] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[137ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Name of proposer: Address of proposer: Email address of proposer:
提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 提案者は承認された登録仕様のためにtype3 enumsに関しては、連絡先になるでしょう、何か登録仕様のメインテナンスが必要であるなら。
11.5 Attribute registration
11.5 属性登録
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:
登録のタイプ: この属性のProposedキーワード名を結果と考えてください: 属性(操作、Job Template、Job記述、Printer記述)のタイプ: 使用される操作は属性が操作であるなら以下を結果と考えます。 オブジェクト、(仕事、Printerなど、オブジェクトへのバウンド)、: 構文(es)(セクション4.2のように1setOfを含んで、及びます)を結果と考えてください: 属性構文が'キーワード'か'enum'であるなら、それは、type2かtype3です: これがPrinter属性であるなら、値が返した5月は「ドキュメント・フォーマット」によります(セクション6.2を見てください): これがJob Template属性であるなら、仕様をどのように「複数のドキュメント処理」属性の値に依存するか: この属性(IPP Modelセクション4.2のスタイルに続く)の仕様: 提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 IPP Designated Expertが承認された登録仕様のために連絡先になる、属性において、登録仕様のメインテナンスがいずれかであるなら必要です。
11.6 Attribute Syntax registration
11.6 属性Syntax登録
Type of registration: attribute syntax Proposed name of this attribute syntax: Type of attribute syntax (integer, octetString, character-string, see [RFC2565]): Numeric value (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:
登録のタイプ: この属性構文の構文Proposed名を結果と考えてください: 属性構文(整数、octetString、文字列は[RFC2565]を見る)のタイプ: 数値(IANAとの相談でIPP Designated Expertによって割り当てられる): この属性(IPP Modelセクション4.1のスタイルに続く)の仕様: 提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
deBry, et al. Experimental [Page 138] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[138ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
以下に注意してください。 IPP Designated Expertが承認された登録仕様のために連絡先になる、属性構文において、登録仕様のメインテナンスがいずれかであるなら必要です。
11.7 Operation registration
11.7 操作登録
Type of registration: operation Proposed name of this operation: Numeric operation-id value (to be assigned by the IPP Designated Expert in consultation with IANA): Object Target (Job, Printer, etc. that operation is upon): Specification of this attribute (follow the style of IPP Model Section 3): Name of proposer: Address of proposer: Email address of proposer:
登録のタイプ: Proposedが命名するこの操作の操作: 数値操作イド値(IANAとの相談でIPP Designated Expertによって割り当てられる): Target(仕事、操作があるPrinterなど)は反対します: この属性(IPP Modelセクション3のスタイルに続く)の仕様: 提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 IPP Designated Expertが承認された登録仕様のために連絡先になる、操作において、登録仕様のメインテナンスがいずれかであるなら必要です。
11.8 Attribute Group registration
11.8 属性Group登録
Type of registration: attribute group Proposed name of this attribute group: Numeric tag according to [RFC2565] (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: 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:
登録のタイプ: この属性グループのグループProposed名を結果と考えてください: [RFC2565](IANAとの相談でIPP Designated Expertによって割り当てられる)に従った数値タグ: 属性グループが起こる各操作のための操作要求とグループ番号: 属性グループが起こる各操作のための操作応答とグループ番号: この属性グループ(IPP Modelセクション3のスタイルに続く)の仕様: 提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 IPP Designated Expertは承認された登録仕様のために属性グループにおける、連絡先になるでしょう、何か登録仕様のメインテナンスが必要であるなら。
11.9 Status code registration
11.9 ステータスコード登録
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:
登録のタイプ: この状態コード値のステータスコードKeyword英字名: 数値(IANAとの相談でIPP Designated Expertによって割り当てられる): このステータスコードが使用されるかもしれない操作:
deBry, et al. Experimental [Page 139] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[139ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
Specification of this status code (follow the style of IPP Model Section 14 APPENDIX B: Status Codes and Suggested Status Code Messages): Name of proposer: Address of proposer: Email address of proposer:
このステータスコード(IPP Modelセクション14 APPENDIX B: 状態CodesとSuggested Status Code Messagesのスタイルに続く)の仕様: 提案者の名前: 提案者のアドレス: 提案者のEメールアドレス:
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.
以下に注意してください。 Designated Expertが承認された登録仕様のために連絡先になる、ステータスコードにおいて、登録仕様のメインテナンスがいずれかであるなら必要です。
deBry, et al. Experimental [Page 140] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[140ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
12. APPENDIX A: Terminology
12. 付録A: 用語
This specification uses the terminology defined in this section.
この仕様はこのセクションで定義された用語を使用します。
12.1 Conformance Terminology
12.1 順応用語
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
12.1.1 NEED NOT
12.1.1 必要性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.
今期はRFC2119に含まれていません。 「必要性NOT」という動詞は文の対象が規格に順応を要求するために実装する必要はない動作を示します。 「5月のNOT」が禁止のように聞こえるので、「必要性NOT」という動詞は「5月のNOT」の代わりに使用されます。
12.2 Model Terminology
12.2 モデル用語
12.2.1 Keyword
12.2.1 キーワード
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.
セクション4.1を見てください。要約の中の意味実体に関する識別子がモデル化されるときキーワードがこのドキュメントの中に使用される、(.2 .3)。 属性名、いくつかの属性値、属性構文、および属性グループ名はキーワードとして表されます。
12.2.2 Attributes
12.2.2 属性
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.
属性はIPPオブジェクトのインスタンスに関連している情報の項目です。 属性は属性名と1つ以上の属性値から成ります。 各属性に、特定の属性構文があります。 すべてのオブジェクト属性がセクション4で定義されます、そして、すべての操作属性がセクション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.
仕事のTemplate Attributesはセクション4.2で説明されます。 クライアントは任意に、要求(Jobオブジェクトを作成する操作要求)を中のaが作成するJob Template属性に提供します。 PrinterオブジェクトはPrinterのためにサポートされるのとデフォルト値を定義する属性を関連づけました。
12.2.2.1 Attribute Name
12.2.2.1 属性名
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
各属性は本書では属性名によって唯一特定されます。 属性名はキーワードです。 それについて説明する節の見出しでキーワード属性名を与えます。
deBry, et al. Experimental [Page 141] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[141ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 属性グループ名
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.
関連属性は命名されたグループに分類されます。 グループの名前はキーワードです。 グループで明らかにすべての属性を命名することに代わってグループ名は使用されるかもしれません。 属性グループはセクション3で定義されます。
12.2.2.3 Attribute Value
12.2.2.3 属性値
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.
各属性に、1つ以上の値があります。 属性値はその属性に指定された構文タイプで表されます。 本書ではテキストを実行する際に、属性値がただ一つの引用符で示される、('、)、それらの属性構文がキーワード、整数、引用符が価値自体の一部でないことのテキストであるのなど、'
12.2.2.4 Attribute Syntax
12.2.2.4 属性構文
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 [RFC2565] indicates the actual "on-the-wire" encoding rules for each syntax type. Attribute syntax types are defined in section 4.1.
各属性は、明白な構文タイプを使用することで定義されます。 本書では、それぞれの構文タイプは特定の意味でキーワードと定義されます。 Encodingと[RFC2565]が、各構文のための「ワイヤ」の実際の符号化規則がタイプするのを示すTransportドキュメント。 属性構文タイプはセクション4.1で定義されます。
12.2.3 Supports
12.2.3 サポート
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.
定義上、対応する属性がその属性のための質問への応答における何らかの値で居住されている状態でそのPrinterオブジェクトが応じる場合にだけ、Printerオブジェクトは属性をサポートします。 Printerオブジェクトは値がPrinterオブジェクトの「サポートしている値」の1つの属性であるなら属性値をサポートします。 Printerオブジェクトの後ろのデバイスは何らかのIPP属性に対応する振舞いを示すかもしれませんが、その属性のために質問される場合Printerオブジェクトが属性で応じないなら、IPPに関する限り、その実装はその特徴をサポートしません。 Printerオブジェクトの「xxxによってサポートしている」属性が特定の値で居住されないなら(その値がその属性のための正当な値であっても)、そのPrinterオブジェクトは、それが特定の値であるとサポートしません。
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
従う実装はすべてのREQUIRED属性をサポートしなければなりません。 しかしながら、REQUIRED属性のためにさえ、IPPへの順応は、すべての実装がすべての可能な値がすべての可能なジョブ処理の振舞いを表して、特徴であるとサポートするのを強制しません。 for
deBry, et al. Experimental [Page 142] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[142ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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).
Printerが応じる次にあるドキュメントだけがフォーマットするPrinterサポートの与えられたインスタンスであることでの例、「ドキュメントは」 1セットの値で居住された属性、ことによるとその属性のために定義された全体の可能な値から取られたものだけを形式でサポートしました。 この限られたセットの値はPrinterのサポートしているドキュメント・フォーマットのセットを表します。 その属性のために属性と何らかのセットの値をサポートすると、その属性とそれらの値に関連しているそれらの特徴でIPPエンドユーザが意識しているのが可能にされて、使用はされます。 実装が、属性か何らかの特定の値をサポートしないのを選ぶなら、当時のIPPエンドユーザには、IPP自身の文脈の中でその特徴を利用する能力が全くないでしょう。 しかしながら、IPP意識していない既存の習慣とレガシーシステムのために、「サポートされない」特徴(ドキュメントデータ自体の中の埋め込まれた指示などの)を制御するか、または要求するIPPの範囲の外にある他のメカニズムがあるかもしれません。
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) Printerオブジェクトが物理的にとめることができないなら、'主要部分'の値で「仕上げでサポートしている」属性に居住してはいけません。 2) Printerオブジェクトが物理的にとめることができる、しかしながら、実装はIPP「仕上げ」属性におけるとめをサポートしないのを選びます。 この場合、'主要部分'は「仕上げでサポートしている」Printerオブジェクト属性において値であるはずがありません。 値の'主要部分'のサポートがなければ、IPPエンドユーザは、Jobがとめられるよう要求するためにプロトコル自体の中に手段を全く持っていないでしょう。 しかしながら、既存のドキュメントデータフォーマッタは、ドキュメントデータの中に直接埋め込まれた指示がある状態でドキュメントがとめられるよう要求できるかもしれません。 この場合、IPP実装はとめを「サポートしない」で、しかしながら、エンドユーザはまだ完了した作業のとめをいくつか管理できます。 3) Printerオブジェクトは物理的にとめることができます、そして、実装はIPP「仕上げ」属性におけるとめをサポートするのを選びます。 この場合、'主要部分'は「仕上げでサポートしている」Printerオブジェクト属性において値であるに違いありません。 そうして、とめの特徴でIPP属性を使用することでエンドユーザが意識しているのを可能にして、使用をするでしょう。
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.
PrinterオブジェクトによるJob Template属性のサポートはOPTIONALですが、Printerオブジェクトの後ろのデバイスが何かIPP属性と何らかの関連値に対応する特徴や機能をわかることができるならその実装SHOULDがそのIPP属性と値をサポートするのは、RECOMMENDEDです。
deBry, et al. Experimental [Page 143] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[143ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 IPP. 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.
サポートしている値の属性のどれかにおける値のセットはIPPの範囲の外にある何らかの管理プロセスか自動感受性機構によるセット(居住される)です。 施政方針とコントロール理由で、管理者は、可能な値の部分集合だけをエンドユーザにとって目に見えるようにするのを選ぶかもしれません。 この場合IPP Printer抽象化の後ろの実質生産量デバイスはある特徴ができるかもしれない、しかしながら、管理者がその特徴へのアクセスがIPPプロトコルを通してエンドユーザに暴露されないと指定しています。 また、Printerオブジェクトが論理的な印刷デバイス(フィジカル・デバイスであるだけではない)を表すかもしれないので、値をサポートするための実際のプロセスは、未定義であり、実装に任せられます。 しかしながら、Printerオブジェクトが値をサポートするなら、何らかの手動の人間の行為が値に関連している意味動作がわかるのに必要であるかもしれませんが、エンドユーザ動作は全く必要ではありません。
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.
例えば、「仕上げでサポートしている」属性における値の1つが'主要部分'であるなら、実際のプロセスはデバイスに送られた何らかのコマンドで制御されたフィジカル・デバイスで自動主要部分の動作であるかもしれません。 または、とめの実際のプロセスはオペレータの出席されたPrinterオブジェクトのオペレータによる手動の動きであるかもしれません。
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").
サポートしている属性がどう機能するかに関する別の例に関しては、仕事のシートが全く紙を保存するために印刷されないように、すべての印刷仕事を制御することを望んでいるシステム管理者を考えてください。 仕事のシートを全く押し込まないように、システム管理者は'なにも'への「シートがサポートした仕事」属性に唯一のサポートしている値を設定します。 要求を作成してください。クライアントが何かを要求するならこの場合'なにも'を除いてください、拒絶されるか、または無視されます(「ipp属性信義」の値に依存します)「仕事シート」が、評価する。 すべての仕事の仕事の始め/端壁板の使用を強制するために、管理者は「シートがサポートした仕事」属性で値の'なにも'を入れません。 要求を作成してください。この場合、クライアントが'なにも'を要求するなら無視する、拒絶されるか、または無視されます(再び、「ipp属性信義」の値に依存します)「仕事のシート」が、評価する。
12.2.4 print-stream page
12.2.4 印刷ストリームページ
A "print-stream page" is a page according to the definition of pages in the language used to express the document data.
ドキュメントデータを言い表すのに使用される言語とのページの定義に従って、「印刷ストリームページ」は1ページです。
12.2.5 impression
12.2.5 印象
An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page.
「印象」は1メディアページに課されたイメージ(異なった構成のことによると多くの印刷ストリームページ)です。
deBry, et al. Experimental [Page 144] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[144ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
13. APPENDIX B: Status Codes and Suggested Status Code Messages
13. 付録B: ステータスコードと提案されたステータスコードメッセージ
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.
このセクションは操作要求の結果でステータスコードenumキーワードと意味情報を提供するのに使用される値を定義します。 それぞれの操作応答はステータスコードを含まなければなりません。 また、応答は状態の短い原文の記述を提供するステータスメッセージを含むかもしれません。 ステータスコードは使用のためにオートマトンで意図します、そして、ステータスメッセージは人間のエンドユーザのために意図します。 ステータスメッセージが操作応答のOPTIONALの部品であるので、IPPアプリケーション(すなわち、ブラウザ、GUI、印刷ドライバーまたはゲートウェイ)はステータスメッセージを調べるか、または表示するNOT REQUIREDです、それがアプリケーションに返されないかもしれないので。
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
「情報」--「うまくいった」状態で受け取られていていて、継続するプロセスを要求してください--動作は、首尾よく受け取られて、分かって、「リダイレクション」を受け入れました--「クライアント誤り」という要求を終了するためにさらなる行動を取らなければなりません--要求は、誤りのある構文を含んでいるか、実現している「サーバ誤り」であるはずがありません--IPPオブジェクトは明らかに有効な要求を実現させませんでした。
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の名前は米国の英語のための提案されたステータスメッセージです。
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
0x01FF「リダイレクション」への「うまくいっている」(「情報0x00FF」への0×0000)0×0100--0x02FFへの0×0200
deBry, et al. Experimental [Page 145] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[145ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
"client-error" - 0x0400 to 0x04FF
"server-error" - 0x0500 to 0x05FF
「クライアント誤り」--0x04FF「サーバ誤り」への0×0400--0x05FFへの0×0500
The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0 to 5) is reserved for private use within each status code class. Values 0x0600 to 0x7FFF are reserved for future assignment and MUST NOT be used.
それぞれの範囲(0〜n=5のための0x0nFFへの0x0n40)の上半分(128の値)は私的使用目的でそれぞれのステータスコードのクラスの中で予約されます。 0x7FFFへの値0x0600を、将来の課題のために予約して、使用してはいけません。
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.0 for this class of status code.
このクラスのステータスコードのためにIPP/1.0で定義されたステータスコードが全くありません。
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オブジェクトの変遷は仕事が印刷されたという唯一のインディケータです。
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
(2) 要求が成功しましたが、いくつかの供給された(1)属性が無視されたか、またはサポートされない値をサポートしている値で代入したか、それを拒絶しないで操作を実行するために無視しました。 すべての操作のための応答のUnsupported Attributesグループでサポートされない属性、属性構文、または値を返さなければなりません。 質問操作のためのこの規則への例外があります: プリンタ属性を得て、ジョブスを得て、仕事の属性を得ます。
deBry, et al. Experimental [Page 146] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[146ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 section 3.2.1.2.
「要求された属性」操作属性だけのために。 いつまで、「要求された属性」操作属性の供給値がサポートされない属性、IPPオブジェクトがそうするかもしれないよう要求しますが、NOT REQUIREDであるか、Unsupported Attribute応答グループ(サポートされない値だけがある)で「要求された属性」属性を返してください。 .2にセクション3.2.1を見てください。
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 section 3.2.1.2.
要求は成功しましたが、いくつかの供給された属性値が他の供給された属性の値と衝突しました。 (2) これらの闘争値は(サポートされます)値で代入された(1)であったかそれを拒絶しないで仕事を処理するために属性を取り除きました。 クライアントによって供給されるようにすべての操作のために、応答のUnsupported Attributesグループで他の属性と衝突して、代入するか、または無視した属性か値を返さなければなりません。 .2にセクション3.2.1を見てください。
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.0 for this class of status code.
このクラスのステータスコードのためにIPP/1.0で定義されたステータスコードが全くありません。
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はエラー状態とそれが一時的であるか永久的な状態であるかどうかに関する説明を含むメッセージを返します。
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
IPPオブジェクトは、要求を理解していますが、それを実現させるのを拒否しています。 繰り返されて、追加認証情報か承認資格証明書が助けでなくて要求SHOULD NOTを望んでいます。 この状態
deBry, et al. Experimental [Page 147] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[147ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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オブジェクトが、要求がちょうどなぜ拒否されたか、そして、または他のどんな応答もいつ適切でないかを明らかにしたがっていないとき、コードは一般的に使用されます。
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は要求を繰り返します。
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は変更なしで要求を繰り返します。
deBry, et al. Experimental [Page 148] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[148ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
主として、リソースが故意に入手できなく、IPPオブジェクト管理者が、そのリソースへのリモートリンクが取り外されることを望んでいるように受取人に通知することによってこの応答がメインテナンスに関するタスクを補助することを意図します。 すべての永久に入手できないリソースが「過ぎ去る」とマークするか、またはどんな長さの時間にもマークを保つのは必要ではありません--すなわち、IPPオブジェクト管理者の思慮深さにいなくなりました。
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はこのステータスコードを返します。
deBry, et al. Experimental [Page 149] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[149ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes.
IPPオブジェクトは、「ドキュメント・フォーマット」操作属性で指定されるように形式にはドキュメントデータがあるので要求を修理するのを拒否していて、それはPrinterオブジェクトによってサポートされません。 この誤りはクライアントによって供給された「ipp属性信義」の如何にかかわらず返されます。 Printerオブジェクトはこのステータスコードを返さなければなりません、また、サポートされない他の属性があっても、この誤りがJob Template属性より大きい問題であるので。
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-attributes-fidelity" operation attribute with the 'true' value, the Printer object MUST return this status code. 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 an optional 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 attributes and values rather than reject the request and return this status code.
aでは、要求を作成してください、Printer物が要求で供給された1つ以上の属性、属性構文、または属性値をサポートしないで、クライアントが'本当'の値と共に「ipp属性信義」操作属性を供給して、Printer物がこのステータスコードを返さなければならないなら。 例えば、要求が、'iso-a4'メディアと、メディアタイプがPrinterによって支持されないのを示すなら、反対してください。 または、クライアントが任意の属性を供給するか、そして、属性自体はPrinterによって支持さえされません。 「ipp属性信義」属性が'誤っている'なら、Printerは要求を拒絶して、このステータスコードを返すよりむしろサポートされない属性と値に値を無視しなければならないか、または代入しなければなりません。
deBry, et al. Experimental [Page 150] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[150ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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 type of the client supplied URI in a Print-URI or a Send-URI operation is not supported.
Print-URIにおける、クライアントの供給されたURIのタイプかSend-URI操作が支持されません。
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).
セクション3.1を見てください。'utf-8'charsetを使用して、IPP Printerが「属性-charset」操作属性におけるクライアントによって供給されたcharsetを支持しないなら、Printerがどんな操作のためにも、操作を拒絶して、この状態とどんな'テキスト'か'名前'属性も返さなければならない、(.4 .1)。
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 specification does not permit to be substituted or ignored.
いくつかの属性値がこの仕様が代入するか、または無視することを許可しない他の属性の値と衝突したので、要求は拒絶されます。
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物はそれが要求を実現させるのを防いだ予期していなかった状態に遭遇しました。 この誤りステータスコードは、より永久的なタイプの内部エラーを含意するという点において「サーバの誤りの一時的な誤り」と異なっています。 また、異なっている、「サーバ誤り装置誤り、」 予期していなかった条件(望ましくない、しかし、期待している紙ジャムかトナーで出ている問題と異なった)を含意するので。 この誤りステータスコードは、たぶん何らかの博識な人間の介入が必要であることを示します。
deBry, et al. Experimental [Page 151] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[151ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
IPP物は要求を実現させるのに必要である機能性を支持しません。 これは、IPP物が操作を認識しないときの適切な応答であるかそれを支持できません。
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 used in the request message. The IPP object is indicating that it is unable or unwilling to complete the request using the same version as supplied in the request other than with this error message. The response should contain a Message describing why that version is not supported and what other versions are supported by that IPP object.
IPP物は、サポートに支えもしませんし、拒否もしません、要求メッセージで使用されたIPPプロトコルバージョン。 IPPは、同じバージョンを使用する要求を終了するのがこのエラーメッセージ以外の要求で供給するように不本意であることを示しているのを反対します。 応答はそのバージョンがなぜ支持されないか、そして、どんな他のバージョンがそのIPP物によって支持されるかを説明するMessageを含むべきです。
A conforming IPP/1.0 client MUST specify the valid version ('1.0') on
each request. A conforming IPP/1.0 object MUST NOT return this
status code to a conforming IPP/1.0 client. An IPP object MUST
return this status code to a non-conforming IPP client. The response
MUST identify in the "version-number" operation attribute the closest
version number that the IPP object does support.
従っているIPP/1.0クライアントは各要求のときに有効なバージョン('1.0')を指定しなければなりません。 従っているIPP/1.0物は従っているIPP/1.0クライアントにこのステータスコードを返してはいけません。 IPP物は非従っているIPPクライアントにこのステータスコードを返さなければなりません。 応答は「バージョン番号」操作属性でIPP物が支持する中で最も近いバージョン番号を特定しなければなりません。
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
IPP物はPrintかSend操作を処理しますが、紙のジャムなどのプリンタ誤りは発生します。 応答は本当のJob Status(「仕事状態」と「仕事の州の理由」属性の値)を含んでいます。 任意の「仕事の州のメッセージ」属性値かさらに詳細に誤りについて説明するOPTIONALステータスメッセージで追加情報を返すことができます。 状況でPrinterが受け入れることができないところにこの誤りステータスコードを返すだけである、そのような装置誤りのために要求を作成してください。 現在、それはプリンタです。例えば、Printerがスプールできないで、一度にある仕事を受け入れることができるだけであるなら、aを拒絶するかもしれない理由が要求を作成する、紙のジャムを食べます。 しかしながら、多くがケースに入れるコネ、どこがPrinterであるか。
deBry, et al. Experimental [Page 152] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[152ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
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.
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物は応答を遅らせるかもしれません。
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-not-accepting-jobs" attribute to 'false' (by means outside of IPP/1.0).
管理者が'誤り'(IPP/1.0における外の手段による)に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)
An error indicating that the job has been canceled by an operator or the system while the client was transmitting the data to the IPP Printer. If a job-id and job-uri had been created, then they are returned in the Print-Job, Send-Document, or Send-URI response as usual; otherwise, no job-id and job-uri are returned in the response.
クライアントがデータをIPP Printerに送っていた間仕事がオペレータかシステムによって中止されているのを示す誤り。 仕事イドと仕事-uriを作成したなら、Print-仕事、Send-ドキュメント、または通常通りのSend-URI応答でそれらを返します。 さもなければ、応答で仕事イドと仕事-uriを全く返しません。
13.2 Status Codes for IPP Operations
13.2 IPP操作のための状態コード
PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
印刷PJ=仕事、Pu=印刷URI、ドキュメントを発信させている雇用を創り出しているサウスダコタCJ==SUは仕事を有効にしている=に対してURIを送っているジョージア=と仕事の属性を得てプリンタ属性を得た状態で等しいです、ジョブスを得ているC=キャンセルGJ=仕事
deBry, et al. Experimental [Page 153] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[153ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
IPP Operations
IPP Status Keyword PJ PU CJ SD SU V GA GJ C
------------------ -- -- -- -- -- - -- -- -
successful-ok x x x x x x x x x
successful-ok-ignored-or-substituted- x x x x x x x x x
attributes
successful-ok-conflicting-attributes x x x x x x x x x
client-error-bad-request x x x x x x x x x
client-error-forbidden x x x x x x x x x
client-error-not-authenticated x x x x x x x x x
client-error-not-authorized x x x x x x x x x
client-error-not-possible x x x x x x x x x
client-error-timeout x x
client-error-not-found x x x x x x x x x
client-error-gone x x x x x x x x x
client-error-request-entity-too-large x x x x x x x x x
client-error-request-value-too-long x x x x x x x x x
client-error-document-format-not- x x x x x x
supported
client-error-attributes-or-values-not- x x x x x x x x x
supported
client-error-uri-scheme-not-supported x x
client-error-charset-not-supported x x x x x x x x x
client-error-conflicting-attributes x x x x x x x x x
server-error-internal-error x x x x x x x x x
server-error-operation-not-supported x x x x
server-error-service-unavailable x x x x x x x x x
server-error-version-not-supported x x x x x x x x x
server-error-device-error x x x x x
server-error-temporary-error x x x x x
server-error-not-accepting-jobs x x x x
server-error-busy x x x x x x x x x
server-error-job-canceled x x
IPP操作IPP状態キーワードPJ Pu CJサウスダコタSU V Ga GJ C------------------ -- -- -- -- -- - -- -- - うまくいっているOKのx x x xうまくいっているx x x x x OK無視される、-、-代入されたx xのx x x x x x xは誤りが認証しなかったうまくいっている間違いない闘争属性x x x x x x x x xクライアントの誤りの悪い要求x x x x x x x x x禁じられたクライアント誤りx x x x x x x x xクライアントを結果と考えます; x x x x x x x x x誤りが権限を与えなかったクライアントx x x x x x x x x可能でないクライアント誤りx x x x x x x x xクライアント誤りタイムアウトx x誤りが当たらなかったクライアントx x x x x x x x x、クライアント誤り過ぎ去る、クライアント誤りが大き過ぎる状態で実体を要求しているx x x x x x x x x; サーバ誤り仕事が中止された支持されなかったx x x x x x x x x x x x xサーバ誤り装置誤りx x x x xサーバの誤りの一時的な誤りx x x x x仕事を受け入れないサーバ誤りx x x x誤りが忙しくするサーバx x x x x x x
deBry, et al. Experimental [Page 154] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[154ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
14. APPENDIX C: "media" keyword values
14. 付録C: 「メディア」キーワード値
Standard keyword values are taken from several sources.
標準のキーワード値はいくつかのソースから抜粋されます。
Standard values are defined (taken from DPA[ISO10175] and the Printer MIB[RFC1759]):
基準値は定義されます(DPA[ISO10175]とPrinter MIB[RFC1759]から、取ります):
'default': The default medium for the output device
'iso-a4-white': Specifies the ISO A4 white medium
'iso-a4-colored': Specifies the ISO A4 colored medium
'iso-a4-transparent' Specifies the ISO A4 transparent medium
'iso-a3-white': Specifies the ISO A3 white medium
'iso-a3-colored': Specifies the ISO A3 colored medium
'iso-a5-white': Specifies the ISO A5 white medium
'iso-a5-colored': Specifies the ISO A5 colored medium
'iso-b4-white': Specifies the ISO B4 white medium
'iso-b4-colored': Specifies the ISO B4 colored medium
'iso-b5-white': Specifies the ISO B5 white medium
'iso-b5-colored': Specifies the ISO B5 colored medium
'jis-b4-white': Specifies the JIS B4 white medium
'jis-b4-colored': Specifies the JIS B4 colored medium
'jis-b5-white': Specifies the JIS B5 white medium
'jis-b5-colored': Specifies the JIS B5 colored medium
'デフォルトとしてください': 出力装置'iso-a4-白'のためのデフォルト媒体: 白人の媒体が'iso-a4着色した'ISO A4は指定します: ISO A4の有色の中型の'iso-a4透明な'ISO A4透明体のSpecifies'iso-a3-白'を指定します: 白人の媒体が'iso-a3着色した'ISO A3は指定します: 中型の'iso-a5-白'に着色されたISO A3は指定します: 白人の媒体が'iso-a5着色した'ISO A5は指定します: 中型の'iso-b4-白'に着色されたISO A5は指定します: 白人の媒体が'iso-b4着色した'ISO B4は指定します: 中型の'iso-b5-白'に着色されたISO B4は指定します: 白人の媒体が'iso-b5着色した'ISO B5は指定します: 中型の'jis-b4-白'に着色されたISO B5は指定します: 白人の媒体が'jis-b4着色した'JIS B4は指定します: 中型の'jis-b5-白'に着色されたJIS B4は指定します: 白人の媒体が'jis-b5着色した'JIS B5は指定します: JIS B5の有色の媒体を指定します。
The following standard values are defined for North American media:
以下の基準値は北米のメディアのために定義されます:
'na-letter-white': Specifies the North American letter white medium
'na-letter-colored': Specifies the North American letter colored
medium
'na-letter-transparent': Specifies the North American letter
transparent medium
'na-legal-white': Specifies the North American legal white medium
'na-legal-colored': Specifies the North American legal colored
medium
'Na手紙白': 北米の手紙白い中型の'着色されたNa手紙'は指定します: 媒体に着色された北米の手紙が指定する、'、Na手紙透明である、'、: 透明体'Naの法的な白'という北米の手紙は指定します: 北米の法的な白人の媒体が指定する、'、Na法的である、有色、'、: 北米の法的な有色の媒体を指定します。
The following standard values are defined for envelopes:
以下の基準値は封筒のために定義されます:
'iso-b4-envelope': Specifies the ISO B4 envelope medium
'iso-b5-envelope': Specifies the ISO B5 envelope medium
'iso-c3-envelope': Specifies the ISO C3 envelope medium
'iso-c4-envelope': Specifies the ISO C4 envelope medium
'iso-c5-envelope': Specifies the ISO C5 envelope medium
'iso-c6-envelope': Specifies the ISO C6 envelope medium
'iso-designated-long-envelope': Specifies the ISO Designated Long
envelope medium
'na-10x13-envelope': Specifies the North American 10x13 envelope
medium
'iso-b4-封筒': ISO B4封筒媒体'iso-b5-封筒'を指定します: ISO B5封筒媒体'iso-c3-封筒'を指定します: ISO C3封筒媒体'iso-c4-封筒'を指定します: ISO C4封筒媒体'iso-c5-封筒'を指定します: ISO C5封筒媒体'iso-c6-封筒'を指定します: ISO C6の封筒中型の'長い封筒に指定されたiso'は指定します: ISO Designated Long封筒媒体'Na10×13封筒'を指定します: ノース・アメリカン10x13封筒媒体を指定します。
deBry, et al. Experimental [Page 155] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[155ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
'na-9x12-envelope': Specifies the North American 9x12 envelope
medium
'monarch-envelope': Specifies the Monarch envelope
'na-number-10-envelope': Specifies the North American number 10
business envelope medium
'na-7x9-envelope': Specifies the North American 7x9 inch envelope
'na-9x11-envelope': Specifies the North American 9x11 inch envelope
'na-10x14-envelope': Specifies the North American 10x14 inch
envelope
'na-number-9-envelope': Specifies the North American number 9
business envelope
'na-6x9-envelope': Specifies the North American 6x9 inch envelope
'na-10x15-envelope': Specifies the North American 10x15 inch
envelope
'Na9x12封筒': ノース・アメリカン9x12封筒媒体'君主封筒'を指定します: Monarch封筒'Na数の10封筒'を指定します: 北米のNo.10業務用封筒媒体'Na7×9封筒'を指定します: ノース・アメリカン7x9インチ封筒'Na9×11封筒'を指定します: ノース・アメリカン9x11インチ封筒'Na10×14封筒'を指定します: ノース・アメリカン10x14インチ封筒'Na数の9封筒'を指定します: 北米のNo.9業務用封筒'Na6×9封筒'を指定します: ノース・アメリカン6x9インチ封筒'Na10×15封筒'を指定します: ノース・アメリカン10x15インチ封筒を指定します。
The following standard values are defined for the less commonly used media (white-only):
以下の基準値は、より少ない一般的に使用されたメディア(白く唯一の)のために定義されます:
'executive-white': Specifies the white executive medium
'folio-white': Specifies the folio white medium
'invoice-white': Specifies the white invoice medium
'ledger-white': Specifies the white ledger medium
'quarto-white': Specified the white quarto medium
'iso-a0-white': Specifies the ISO A0 white medium
'iso-a1-white': Specifies the ISO A1 white medium
'iso-a2-white': Specifies the ISO A2 white medium
'iso-a6-white': Specifies the ISO A6 white medium
'iso-a7-white': Specifies the ISO A7 white medium
'iso-a8-white': Specifies the ISO A8 white medium
'iso-a9-white': Specifies the ISO A9 white medium
'iso-10-white': Specifies the ISO A10 white medium
'iso-b0-white': Specifies the ISO B0 white medium
'iso-b1-white': Specifies the ISO B1 white medium
'iso-b2-white': Specifies the ISO B2 white medium
'iso-b3-white': Specifies the ISO B3 white medium
'iso-b6-white': Specifies the ISO B6 white medium
'iso-b7-white': Specifies the ISO B7 white medium
'iso-b8-white': Specifies the ISO B8 white medium
'iso-b9-white': Specifies the ISO B9 white medium
'iso-b10-white': Specifies the ISO B10 white medium
'jis-b0-white': Specifies the JIS B0 white medium
'jis-b1-white': Specifies the JIS B1 white medium
'jis-b2-white': Specifies the JIS B2 white medium
'jis-b3-white': Specifies the JIS B3 white medium
'jis-b6-white': Specifies the JIS B6 white medium
'jis-b7-white': Specifies the JIS B7 white medium
'幹部社員白': 幹部社員の白い媒体'二つ折りの白'を指定します: 二つ折りの白い中型の'インボイス白'を指定します: '原簿白い'状態で白人のインボイス媒体を指定します: 白い原簿中型の'四折判白'を指定します: 四折判の白い媒体'iso-a0-白'を指定します: ISO A0の白い中型の'iso-a1-白'を指定します: ISO A1の白い中型の'iso-a2-白'を指定します: ISO A2の白い中型の'iso-a6-白'を指定します: ISO A6の白い中型の'iso-a7-白'を指定します: ISO A7の白い中型の'iso-a8-白'を指定します: ISO A8の白い中型の'iso-a9-白'を指定します: ISO A9の白い中型の'10が空白にするiso'は指定します: ISO A10の白い中型の'iso-b0-白'を指定します: ISO B0の白い中型の'iso-b1-白'を指定します: ISO B1の白い中型の'iso-b2-白'を指定します: ISO B2の白い中型の'iso-b3-白'を指定します: ISO B3の白い中型の'iso-b6-白'を指定します: ISO B6の白い中型の'iso-b7-白'を指定します: ISO B7の白い中型の'iso-b8-白'を指定します: ISO B8の白い中型の'iso-b9-白'を指定します: ISO B9の白い中型の'iso-b10-白'を指定します: ISO B10の白い中型の'jis-b0-白'を指定します: JIS B0の白い中型の'jis-b1-白'を指定します: JIS B1の白い中型の'jis-b2-白'を指定します: JIS B2の白い中型の'jis-b3-白'を指定します: JIS B3の白い中型の'jis-b6-白'を指定します: JIS B6の白い中型の'jis-b7-白'を指定します: JIS B7の白人の媒体を指定します。
deBry, et al. Experimental [Page 156] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[156ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
'jis-b8-white': Specifies the JIS B8 white medium
'jis-b9-white': Specifies the JIS B9 white medium
'jis-b10-white': Specifies the JIS B10 white medium
'jis-b8-白': JIS B8の白い中型の'jis-b9-白'を指定します: JIS B9の白い中型の'jis-b10-白'を指定します: JIS B10の白人の媒体を指定します。
The following standard values are defined for engineering media:
以下の基準値は工学メディアのために定義されます:
'a': Specifies the engineering A size medium
'b': Specifies the engineering B size medium
'c': Specifies the engineering C size medium
'd': Specifies the engineering D size medium
'e': Specifies the engineering E size medium
'a': 工学Aサイズ媒体'b'は指定します: 工学Bサイズ媒体'c'は指定します: 'サイズ媒体が指定する工学Cを指定します': 工学Dサイズ媒体'e'は指定します: 工学Eサイズ媒体を指定します。
The following standard values are defined for input-trays (from ISO DPA and the Printer MIB):
以下の基準値は入力トレー(ISO DPAとPrinter MIBからの)のために定義されます:
'top': The top input tray in the printer.
'middle': The middle input tray in the printer.
'bottom': The bottom input tray in the printer.
'envelope': The envelope input tray in the printer.
'manual': The manual feed input tray in the printer.
'large-capacity': The large capacity input tray in the printer.
'main': The main input tray
'side': The side input tray
'先端': 先端はプリンタでトレーを入力しました。 '中央': 中央はプリンタでトレーを入力しました。 '底に達してください': 下部はプリンタでトレーを入力しました。 '封筒': 封筒はプリンタでトレーを入力しました。 'マニュアル': 手動の給送はプリンタでトレーを入力しました。 '大容量': 大容量はプリンタでトレーを入力しました。 'メイン': メインはトレー'側'を入力しました: サイド入力トレー
The following standard values are defined for media sizes (from ISO DPA):
以下の基準値はメディアサイズ(ISO DPAからの)のために定義されます:
'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined
in ISO 216
'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
ISO 216
'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
ISO 216
'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
ISO 216
'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
ISO 216
'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
ISO 216
'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
ISO 216
'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
ISO 216
'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in
ISO 216
'iso-a0': ISO A0サイズを指定します: 841mm×ISO216で定義される1189mmの'iso-a1': ISO A1サイズを指定します: 594mm×ISO216で定義される841mmの'iso-a2': ISO A2サイズを指定します: 420mm×ISO216で定義される594mmの'iso-a3': ISO A3サイズを指定します: 297mm×ISO216で定義される420mmの'iso-a4': ISO A4サイズを指定します: 210mm×ISO216で定義される297mmの'iso-a5': ISO A5サイズを指定します: 148mm×ISO216で定義される210mmの'iso-a6': ISO A6サイズを指定します: 105mm×ISO216で定義される148mmの'iso-a7': ISO A7サイズを指定します: 74mm×ISO216で定義される105mmの'iso-a8': ISO A8サイズを指定します: 52mm×ISO216で定義される74mm
deBry, et al. Experimental [Page 157] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[157ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in
ISO 216
'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
ISO 216
'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined
in ISO 216
'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined
in ISO 216
'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
ISO 216
'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
ISO 216
'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
ISO 216
'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
ISO 216
'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
ISO 216
'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
ISO 216
'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in
ISO 216
'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in
ISO 216
'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
ISO 216
'na-letter': Specifies the North American letter size: 8.5 inches by
11 inches
'na-legal': Specifies the North American legal size: 8.5 inches by
14 inches
'executive': Specifies the executive size (7.25 X 10.5 in)
'folio': Specifies the folio size (8.5 X 13 in)
'invoice': Specifies the invoice size (5.5 X 8.5 in)
'ledger': Specifies the ledger size (11 X 17 in)
'quarto': Specifies the quarto size (8.5 X 10.83 in)
'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
ISO 269
'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
ISO 269
'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
ISO 269
'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
ISO 269
'iso-designated-long': Specifies the ISO Designated Long size: 110
mm by 220 mm as defined in ISO 269
'na-10x13-envelope': Specifies the North American 10x13 size: 10
inches by 13 inches
'iso-a9': ISO A9サイズを指定します: 37mm×ISO216で定義される52mmの'iso-a10': ISO A10サイズを指定します: 26mm×ISO216で定義される37mmの'iso-b0': ISO B0サイズを指定します: 1000mm×ISO216で定義される1414mmの'iso-b1': ISO B1サイズを指定します: 707mm×ISO216で定義される1000mmの'iso-b2': ISO B2サイズを指定します: 500mm×ISO216で定義される707mmの'iso-b3': ISO B3サイズを指定します: 353mm×ISO216で定義される500mmの'iso-b4': ISO B4サイズを指定します: 250mm×ISO216で定義される353mmの'iso-b5': ISO B5サイズを指定します: 176mm×ISO216で定義される250mmの'iso-b6': ISO B6サイズを指定します: 125mm×ISO216で定義される176mmの'iso-b7': ISO B7サイズを指定します: 88mm×ISO216で定義される125mmの'iso-b8': ISO B8サイズを指定します: 62mm×ISO216で定義される88mmの'iso-b9': ISO B9サイズを指定します: 44mm×ISO216で定義される62mmの'iso-b10': ISO B10サイズを指定します: 31mm×ISO216'Na手紙'で定義される44mm: 北米の手紙サイズを指定します: 11の8.5インチは'Na法的に'少しずつ動きます: 北米の法的なサイズを指定します: 8.5インチ×14インチの'幹部社員': 幹部社員サイズ(中に7.25X10.5がある状態で)'二つ折り'を指定します: 二つ折りのサイズ(中に8.5X13がある状態で)'インボイス'は指定します: インボイスサイズ(中に5.5X8.5がある状態で)'原簿'は指定します: サイズ(中に11X17がある状態で)'四折判'という原簿は指定します: 四折判サイズ(中に8.5X10.83がある状態で)'iso-c3'は指定します: ISO C3サイズを指定します: 324mm×ISO269で定義される458mmの'iso-c4': ISO C4サイズを指定します: 229mm×ISO269で定義される324mmの'iso-c5': ISO C5サイズを指定します: 162mm×ISO269で定義される229mmの'iso-c6': ISO C6サイズを指定します: 114mm×ISO269で定義される162mmの'長い間指定されたiso': ISO Designated Longサイズを指定します: 110mm×ISO269で定義される220mmの'Na10x13封筒': ノース・アメリカン10x13サイズを指定します: 10インチ×13インチ
deBry, et al. Experimental [Page 158] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[158ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
'na-9x12-envelope': Specifies the North American 9x12 size: 9
inches by 12 inches
'na-number-10-envelope': Specifies the North American number 10
business envelope size: 4.125 inches by 9.5 inches
'na-7x9-envelope': Specifies the North American 7x9 inch envelope
size
'na-9x11-envelope': Specifies the North American 9x11 inch envelope
size
'na-10x14-envelope': Specifies the North American 10x14 inch
envelope size
'na-number-9-envelope': Specifies the North American number 9
business envelope size
'na-6x9-envelope': Specifies the North American 6x9 envelope size
'na-10x15-envelope': Specifies the North American 10x15 envelope
size
'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
in)
'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
'jis-b3': Specifies the JIS B3 size: 364mm x 515mm
'jis-b4': Specifies the JIS B4 size: 257mm x 364mm
'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
'Na9x12封筒': ノース・アメリカン9x12サイズを指定します: 9インチ×12インチの'Na No.10封筒': 北米のNo.10業務用封筒サイズを指定します: 4.125インチ×9.5インチの'Na7x9封筒': ノース・アメリカン7x9インチ封筒サイズ'Na9×11封筒'を指定します: ノース・アメリカン9x11インチ封筒サイズ'Na10×14封筒'を指定します: ノース・アメリカン10x14インチ封筒サイズ'Na数の9封筒'を指定します: 北米のNo.9業務用封筒サイズ'Na6×9封筒'を指定します: ノース・アメリカン6x9封筒サイズ'Na10×15封筒'を指定します: ノース・アメリカン10x15封筒サイズ'君主封筒'を指定します: Monarch封筒サイズ(中に3.87x7.5がある状態で)'jis-b0'は指定します: JIS B0サイズを指定します: 1030mm x1456mm'jis-b1': JIS B1サイズを指定します: 728mm x1030mm'jis-b2': JIS B2サイズを指定します: 515mm x728mm'jis-b3': JIS B3サイズを指定します: 364mm x515mm'jis-b4': JIS B4サイズを指定します: 257mm x364mm'jis-b5': JIS B5サイズを指定します: 182mm x257mm'jis-b6': JIS B6サイズを指定します: 128mm x182mm'jis-b7': JIS B7サイズを指定します: 91mm x128mm'jis-b8': JIS B8サイズを指定します: 64mm x91mm'jis-b9': JIS B9サイズを指定します: 45mm x64mm'jis-b10': JIS B10サイズを指定します: 32mm x45mm
deBry, et al. Experimental [Page 159] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[159ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
15. APPENDIX D: Processing IPP Attributes
15. 付録D: 処理IPP属性
When submitting a print job to a Printer object, the IPP model allows a client to supply operation and Job Template attributes along with the document data. These Job Template attributes in the create request affect the rendering, production and finishing of the documents in the job. Similar types of instructions may also be contained in the document to be printed, that is, embedded within the print data itself. In addition, the Printer has a set of attributes that describe what rendering and finishing options which are supported by that Printer. This model, which allows for flexibility and power, also introduces the potential that at job submission time, these client-supplied attributes may conflict with either:
Printer物に印刷仕事を提出するとき、IPPモデルはクライアントにドキュメントデータに伴う操作とJob Template属性を供給させます。 中のこれらのJob Template属性、表現、生産に影響するよう要求して、仕事で書類を終えながら、作成します。 また、同様のタイプの指示も、印刷されるべきドキュメントで含まれて、すなわち、印刷データ自体の中で埋め込まれるかもしれません。 さらに、Printerには、そのPrinterによってサポートされるすべての表現と仕上げのオプションについて説明する1セットの属性があります。 また、このモデル(柔軟性とパワーを考慮する)はジョブ依頼時間、これらのクライアントによって供給された属性で衝突するかもしれない可能性を導入します:
- what the implementation is capable of realizing (i.e., what the
Printer supports), as well as
- the instructions embedded within the print data itself.
- また、実現が換金できる(すなわち、Printerは何を支持しますか)こと--指示は印刷の中でデータ自体を埋め込みました。
The following sections describe how these two types of conflicts are handled in the IPP model.
以下のセクションはこれらの2つのタイプの闘争がIPPモデルでどう扱われるかを説明します。
15.1 Fidelity
15.1 信義
If there is a conflict between what the client requests and what a Printer object supports, the client may request one of two possible conflict handling mechanisms:
クライアントが要求することとPrinter物が支持することとの闘争があれば、クライアントは2つの可能な闘争取り扱いメカニズムの1つを要求するかもしれません:
1) either reject the job since the job can not be processed exactly
as specified, or
2) allow the Printer to make any changes necessary to proceed with
processing the Job the best it can.
1) ちょうど指定されるとして仕事を処理できないので、仕事を拒絶してください。さもないと、2は、)Printerがどんな変更もJobを処理するのにそれが続かせることができるベストを続かせるのに必要にするのを許容します。
In the first case the client is indicating to the Printer object: "Print the job exactly as specified with no exceptions, and if that can't be done, don't even bother printing the job at all." In the second case, the client is indicating to the Printer object: "It is more important to make sure the job is printed rather than be processed exactly as specified; just make sure the job is printed even if client supplied attributes need to be changed or ignored."
前者の場合クライアントはPrinter物に以下を示しています。 「ちょうど指定されるとしての例外のない仕事を印刷してください、そして、それができないなら、わざわざ全く仕事は印刷さえしないでください。」 2番目の場合では、クライアントはPrinter物に以下を示しています。 「仕事がむしろ印刷されるのは、ちょうど指定されるとして処理されるより念のため重要です」。 「クライアントの供給された属性が、変えるか、または無視する必要があっても仕事が印刷されるのをちょっと確実にしてください。」
The IPP model accounts for this situation by introducing an "ipp- attribute-fidelity" attribute.
IPPは、この状況のために「ipp属性信義」属性を導入することによって、アカウントをモデル化します。
In a create request, "ipp-attribute-fidelity" is a boolean operation attribute that is OPTIONALLY supplied by the client. The value ' true' indicates that total fidelity to client supplied Job Template attributes and values is required. The client is requesting that the Job be printed exactly as specified, and if that is not possible then
aでは、要求を作成してください、そして、「ipp属性信義」はクライアントによって供給されたOPTIONALLYであるブール演算属性です。 '本当値の'は、クライアントの供給されたJob Template属性と値への総信義が必要であることを示します。 クライアントは、ちょうど指定されて、それがその時可能でないならJobが印刷されるよう要求しています。
deBry, et al. Experimental [Page 160] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[160ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
the job MUST be rejected rather than processed incorrectly. The value 'false' indicates that a reasonable attempt to print the Job is acceptable. If a Printer does not support some of the client supplied Job Template attributes or values, the Printer MUST ignore them or substitute any supported value for unsupported values, respectively. The Printer may choose to substitute the default value associated with that attribute, or use some other supported value that is similar to the unsupported requested value. For example, if a client supplies a "media" value of 'na-letter', the Printer may choose to substitute 'iso-a4' rather than a default value of ' envelope'. If the client does not supply the "ipp-attribute-fidelity" attribute, the Printer assumes a value of 'false'.
不当に処理されるよりむしろ仕事を拒絶しなければなりません。 '誤値の'は、Jobを印刷する合理的な試みが許容できるのを示します。 Printerがクライアントの供給されたJob Template属性か値のいくつかをサポートしないなら、Printerはそれらを無視しなければならないか、またはそれぞれどんなサポートしている値もサポートされない値の代わりに用いなければなりません。 Printerは、その属性に関連しているデフォルト値を代入するか、またはある他のサポートされない要求された値と同様のサポートしている値を使用するのを選ぶかもしれません。 例えば、クライアントが'Na手紙'の「メディア」値を供給するなら、Printerは、'封筒'のデフォルト値よりむしろ'iso-a4'を代入するのを選ぶかもしれません。 クライアントが「ipp属性信義」属性を供給しないなら、Printerは'誤ること'の値を仮定します。
Each Printer implementation MUST support both types of "fidelity" printing (that is whether the client supplies a value of 'true' or ' false'):
それぞれのPrinter実装は「信義」印刷の両方のタイプをサポートしなければなりません(すなわち、クライアントは'本当である'か'誤ること'の値を供給するかどうか):
- If the client supplies 'false' or does not supply the attribute,
the Printer object MUST always accept the request by ignoring
unsupported Job Template attributes and by substituting
unsupported values of supported Job Template attributes with
supported values.
- If the client supplies 'true', the Printer object MUST reject the
request if the client supplies unsupported Job Template
attributes.
- クライアントが'誤ること'を供給するか、または属性を供給しないなら、Printerオブジェクトは、サポートしている値でサポートされないJob Template属性を無視して、サポートしているJob Template属性のサポートされない値を代入することによって、いつも要請を受け入れなければなりません。 - クライアント供給であるなら、クライアントがサポートされないJob Template属性を供給するなら、'本当に'Printerオブジェクトは要求を拒絶しなければなりません。
Since a client can always query a Printer to find out exactly what is and is not supported, "ipp-attribute-fidelity" set to 'false' is useful when:
クライアントがまさに何があるかを見つけるためにいつもPrinterについて質問できて、サポートされないので、'誤っていること'に設定された「ipp属性信義」が役に立つ、いつ:
1) The End-User uses a command line interface to request attributes
that might not be supported.
2) In a GUI context, if the End User expects the job might be moved
to another printer and prefers a sub-optimal result to nothing
at all.
3) The End User just wants something reasonable in lieu of nothing
at all.
1) エンドユーザは、サポートされないかもしれない属性を要求するのにコマンドラインインタフェースを使用します。 2) エンドユーザがGUI文脈仕事が別のプリンタに動かされるかもしれないと予想して、全く無よりサブ最適の結果を好むなら。 3) エンドユーザはただ全く無の代わりに何か妥当なものが欲しいです。
15.2 Page Description Language (PDL) Override
15.2 ページ記述言語(PDL)オーバーライド
If there is a conflict between the value of an IPP Job Template attribute and a corresponding instruction in the document data, the value of the IPP attribute SHOULD take precedence over the document instruction. Consider the case where a previously formatted file of document data is sent to an IPP Printer. In this case, if the client supplies any attributes at job submission time, the client desires that those attributes override the embedded instructions. Consider the case were a previously formatted document has embedded in it
闘争があれば、属性SHOULDはドキュメント指示の上でIPP Job Template属性の値とドキュメントデータにおける対応する指示、IPPの値の間では、優先します。 ドキュメントデータの以前にフォーマットされたファイルがIPP Printerに送られるケースを考えてください。 この場合、クライアントがジョブ依頼時に何か属性を供給するなら、クライアントは、それらの属性が埋め込まれた指示をくつがえすことを望んでいます。 ケースが以前にフォーマットされたドキュメントがそれを中に埋め込んだということであると考えてください。
deBry, et al. Experimental [Page 161] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[161ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
commands to load 'iso-a4' media. However, the document is passed to an end user that only has access to a printer with 'na-letter' media loaded. That end user most likely wants to submit that document to an IPP Printer with the "media" Job Template attribute set to 'na- letter'. The job submission attribute should take precedence over the embedded PDL instruction. However, until companies that supply document data interpreters allow a way for external IPP attributes to take precedence over embedded job production instructions, a Printer might not be able to support the semantics that IPP attributes override the embedded instructions.
'iso-a4'メディアをロードするコマンド。 しかしながら、ドキュメントは'Na手紙'メディアがロードされている状態でプリンタに近づく手段を持っているだけであるエンドユーザに渡されます。 そのエンドユーザはたぶん「メディア」Job Template属性セットで'Na手紙'にIPP Printerへのそのドキュメントを提出したがっています。 ジョブ依頼属性は埋め込まれたPDL指示の上で優先するべきです。 しかしながら、供給ドキュメントデータインタプリタで外部のIPP属性のための方法に優先する会社が仕事の製造指図書を埋め込むまで、PrinterはIPP属性がくつがえす意味論に埋め込まれた指示をサポートすることができないかもしれません。
The IPP model accounts for this situation by introducing a "pdl- override-supported" attribute that describes the Printer objects capabilities to override instructions embedded in the PDL data stream. The value of the "pdl-override-supported" attribute is configured by means outside IPP/1.0.
オーバーライド指示への能力がPDLデータに埋め込んだPrinterオブジェクトについて説明する「pdlにオーバーライドでサポートしている」属性を導入するのによるこの状況のためのIPPモデルアカウントは流れます。 「オーバーライドがサポートしたpdl」属性の値はIPP/1.0の外で手段で構成されます。
This REQUIRED Printer attribute takes on the following values:
このREQUIRED Printer属性は以下の値を呈します:
- '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.
- '試みられる': この値は、Printerオブジェクトが、IPP属性値がドキュメントデータにおける埋め込まれた指示の上で優先させるのを試みるのを示して、しかしながら、保証が全くありません。 - '試みられない': この値は、PrinterオブジェクトがIPP属性値に先行を引き継がせる試みを全くドキュメントデータにおける埋め込まれた指示にしないのを示します。
At job processing time, an implementation that supports the value of 'attempted' might do one of several different actions:
ジョブ処理時に、'試みられること'の値をサポートする実装はいくつかの異なった動作の1つをするかもしれません:
1) Generate an output device specific command sequence to realize
the feature represented by the IPP attribute value.
2) Parse the document data itself and replace the conflicting
embedded instruction with a new embedded instruction that
matches the intent of the IPP attribute value.
3) Indicate to the Printer that external supplied attributes take
precedence over embedded instructions and then pass the external
IPP attribute values to the document data interpreter.
4) Anything else that allows for the semantics that IPP attributes
override embedded document data instructions.
1) 出力装置の特定のコマンド・シーケンスを生成して、IPP属性値によって表された特徴がわかってください。 2) ドキュメントデータ自体を分析してください、そして、闘争の埋め込まれた指示をIPP属性値の意図に合っている新しい埋め込まれた指示に取り替えてください。 3) 外部の供給された属性がドキュメントデータインタプリタに埋め込まれた指示の上で優先して、次に、外部のIPP属性値を渡すのをPrinterに示してください。 4) IPP属性がくつがえす意味論を考慮する他の何かがドキュメントデータ指示を埋め込みました。
Since 'attempted' does not offer any type of guarantee, even though a given Printer object might not do a very "good" job of attempting to ensure that IPP attributes take a higher precedence over instructions embedded in the document data, it would still be a conforming implementation.
'試みられ'て、いずれもタイプする申し出が、与えられたPrinterオブジェクトがそうしないかもしれませんが、IPP属性がドキュメントデータに埋め込まれた指示の上により高い先行を取って、それがまだ従う実装であることを保証するのを試みる非常に「良い」仕事がそうするのを保証しないので
deBry, et al. Experimental [Page 162] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[162ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
At job processing time, an implementation that supports the value of 'not-attempted' might do one of the following actions:
ジョブ処理時に、'試みられないこと'の値をサポートする実装は以下の動作の1つをするかもしれません:
1) Simply pre-pend the document data with the PDL instruction that
corresponds to the client-supplied PDL attribute, such that if
the document data also has the same PDL instruction, it will
override what the Printer object pre-pended. In other words,
this implementation is using the same implementation semantics
for the client-supplied IPP attributes as for the Printer object
defaults.
2) Parse the document data and replace the conflicting embedded
instruction with a new embedded instruction that approximates,
but does not match, the semantic intent of the IPP attribute
value.
1) 単にプレpendはクライアントによって供給されたPDL属性(また、ドキュメントデータに同じPDL指示があると、Printerオブジェクトがあらかじめpendedしたものをくつがえすようなもの)に対応するPDL指示があるドキュメントデータです。 言い換えれば、この実装はクライアントによって供給されたIPP属性にPrinterオブジェクトデフォルトのように同じ実装意味論を使用しています。 2) ドキュメントデータを分析してください、そして、闘争の埋め込まれた指示を合っていないのを除いたIPP属性値のいずれの意味意図にも近似しない新しい埋め込まれた指示に取り替えてください。
Note: The "ipp-attribute-fidelity" attribute applies to the
Printer's ability to either accept or reject other unsupported Job
Template attributes. In other words, if "ipp-attribute-fidelity" is
set to 'true', a Job is accepted if and only if the client supplied
Job Template attributes and values are supported by the Printer.
Whether these attributes actually affect the processing of the Job
when the document data contains embedded instructions depends on the
ability of the Printer to override the instructions embedded in the
document data with the semantics of the IPP attributes. If the
document data attributes can be overridden ("pdl-override-supported"
set to 'attempted'), the Printer makes an attempt to use the IPP
attributes when processing the Job. If the document data attributes
can not be overridden ("pdl-override-supported" set to 'not-
attempted'), the Printer makes no attempt to override the embedded
document data instructions with the IPP attributes when processing
the Job, and hence, the IPP attributes may fail to affect the Job
processing and output when the corresponding instruction is embedded
in the document data.
以下に注意してください。 「ipp属性信義」属性は他のサポートされないJob Template属性を受け入れるか、または拒絶するPrinterの性能に適用されます。 そして、言い換えれば、「ipp属性信義」を'本当に'設定するなら、Jobを受け入れる、クライアントがJob Templateを供給した場合にだけ、属性と値はPrinterによってサポートされます。 ドキュメントデータが埋め込まれた指示を含んでいるとこれらの属性が実際にJobの処理に影響するかどうかがPrinterがIPP属性の意味論でドキュメントデータに埋め込まれた指示をくつがえす能力に依存します。 ドキュメントデータ属性をくつがえすことができるなら(「オーバーライドがサポートしたpdl」は'試みられること'にセットしました)、PrinterはJobを処理するときIPP属性を使用する試みをします。 ドキュメントデータ属性をくつがえすことができない、(「オーバーライドがサポートしたpdl」がセットした、'、-、試み、'、)、Jobを処理するとき、PrinterはIPP属性で埋め込まれたドキュメントに優越する試みを全くデータ指示にしないで、またしたがって、対応する指示がドキュメントデータに埋め込まれているとき、IPP属性はJob処理と出力に影響しないかもしれません。
15.3 Using Job Template Attributes During Document Processing.
15.3 文書処理の間、仕事のテンプレート属性を使用します。
The Printer object uses some of the Job object's Job Template attributes during the processing of the document data associated with that job. These include, but are not limited to, "orientation", "number-up", "sides", "media", and "copies". The processing of each document in a Job Object MUST follow the steps below. These steps are intended only to identify when and how attributes are to be used in processing document data and any alternative steps that accomplishes the same effect can be used to implement this specification.
Printerオブジェクトはその仕事に関連しているドキュメントデータの処理の間、JobオブジェクトのJob Template属性のいくつかを使用します。 これらが含んでいる、有限で、「オリエンテーション」の、そして、「数の上がっていない」「側」、「メディア」、および「コピー」はそうです。 Job Objectでのそれぞれのドキュメントの処理は下の方法に従わなければなりません。 これらのステップが、この仕様を履行するために属性がいつ、どのように処理ドキュメントデータと何かそれが実行する代替のステップで使用されるのに、同じ効果を使用できるということであるかを単に特定することを意図します。
1. Using the client supplied "document-format" attribute or some
form of document format detection algorithm (if the value of
"document- format" is not specific enough), determine whether or
1. またはクライアントを使用すると「ドキュメント・フォーマット」属性かドキュメント・フォーマット検出アルゴリズムの何らかのフォームが与えられた、(「ドキュメント形式」の値が十分特定でないなら)決定。
deBry, et al. Experimental [Page 163] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[163ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
not the document data has already been formatted for printing.
If the document data has been formatted, then go to step 2.
Otherwise, the document data MUST be formatted. The formatting
detection algorithm is implementation defined and is not
specified by this specification. The formatting of the document
data uses the "orientation-requested" attribute to determine how
the formatted print data should be placed on a print-stream
page, see section 4.2.10 for the details.
いずれのドキュメントデータも印刷のために既にフォーマットされていません。 ドキュメントデータがフォーマットされたなら、ステップ2に行ってください。 さもなければ、ドキュメントデータをフォーマットしなければなりません。 形式検出アルゴリズムは、定義された実装であり、この仕様で指定されません。 ドキュメントデータの形式はフォーマットされた印刷データがどのように印刷ストリームページに置かれるべきであるかを決定するのに「オリエンテーションで要求された」属性を使用します、とセクション4.2.10が詳細に関して見ます。
2. The document data is in the form of a print-stream in a known
media type. The "page-ranges" attribute is used to select, as
specified in section 4.2.7, a sub-sequence of the pages in the
print-stream that are to be processed and images.
2. ドキュメントデータが知られているメディアタイプの印刷ストリームの形にあります。 「ページ範囲」属性は、セクション4.2.7で指定されるように印刷ストリームにおける処理されることになっているページとイメージのサブ系列を選択するのに使用されます。
3. The input to this step is a sequence of print-stream pages. This
step is controlled by the "number-up" attribute. If the value of
"number-up" is N, then during the processing of the print-stream
pages, each N print-stream pages are positioned, as specified in
section 4.2.9, to create a single impression. If a given
document does not have N more print-stream pages, then the
completion of the impression is controlled by the "multiple-
document-handling" attribute as described in section 4.2.4; when
the value of this attribute is 'single-document' or 'single-
document-new-sheet', the print-stream pages of document data
from subsequent documents is used to complete the impression.
3. このステップへの入力は印刷ストリームページの系列です。 このステップは「数の上がっている」属性によって制御されます。 「上に数」の値がNであるなら、印刷ストリームページの処理の間、各N印刷ストリームページは置かれます、ただ一つの印象を引き起こすためにセクション4.2.9で指定されるように。 与えられたドキュメントにNが、より多くの印刷ストリームページないなら、印象の完成はセクション4.2.4で説明されるように「複数のドキュメント処理」属性によって制御されます。 この属性の値が'新しいシートを記録していた状態で''シングルをシングル記録する'ことであるときに、その後のドキュメントからのドキュメントデータの印刷ストリームページは、印象を終了するのに使用されます。
The size(scaling), position(translation) and rotation of the
print-stream pages on the impression is implementation defined.
Note that during this process the print-stream pages may be
rendered to a form suitable for placing on the impression; this
rendering is controlled by the values of the "printer-
resolution" and "print- quality" attributes as described in
sections 4.2.12 and 4.2.13. In the case N=1, the impression is
nearly the same as the print-stream page; the differences would
only be in the size, position and rotation of the print-stream
page and/or any decoration, such as a frame to the page, that is
added by the implementation.
印象における印刷ストリームページのサイズ(スケーリングする)、位置(翻訳)、および回転は定義された実装です。 このプロセスの間印刷ストリームページが印象で入賞するのに適当なフォームに提供されるかもしれないことに注意してください。 このレンダリングはセクション4.2.12と4.2で.13に説明されるように「プリンタ解決」と「印刷品質」属性の値によって制御されます。 ケースN=1では、印象は印刷ストリームページとほとんど同じです。 違いはサイズ、印刷ストリームページの位置と回転、そして/または、実装によって加えられるページへのフレームなどのどんなデコレーション中であるだけでしょう。
4. The collection of impressions is placed, in sequence, onto sides
of the media sheets. This placement is controlled by the "sides"
attribute and the orientation of the print-stream page, as
described in section 4.2.8. The orientation of the print-stream
pages affects the orientation of the impression; for example, if
"number-up" equals 2, then, typically, two portrait print-stream
pages become one landscape impression. Note that the placement
of impressions onto media sheets is also controlled by the
"multiple-document-handling" attribute as described in section
4.2.4.
4. 印象の収集は連続してメディアシートの側面に置かれます。 このプレースメントはセクション4.2.8で説明されるように「側」属性と印刷ストリームページのオリエンテーションで制御されます。 印刷ストリームページのオリエンテーションは印象のオリエンテーションに影響します。 例えば、次に、「上に数」が2と通常等しいなら、2肖像印刷ストリームページは1回の風景印象になります。 また、メディアシートへの印象のプレースメントがセクション4.2.4で説明されるように「複数のドキュメント処理」属性によって制御されることに注意してください。
deBry, et al. Experimental [Page 164] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[164ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
5. The "copies" and "multiple-document-handling" attributes are
used to determine how many copies of each media instance are
created and in what order. See sections 4.2.5 and 4.2.4 for the
details.
5. 「コピー」と「複数のドキュメント処理」属性は、それぞれのメディアインスタンスのいくつのコピーが作成されるかを決定して、何で注文するかに使用されます。 セクション4.2.5と4.2を見てください。.4 詳細のために。
6. When the correct number of copies are created, the media
instances are finished according to the values of the
"finishings" attribute as described in 4.2.6. Note that
sometimes finishing operations may require manual intervention
to perform the finishing operations on the copies, especially
uncollated copies. This specification allows any or all of the
processing steps to be performed automatically or manually at
the discretion of the Printer object.
6. いつコピーの適度の数が作成されて、「仕上げ」属性の値に応じてメディアインスタンスが説明されるように終わっているか、4.2、.6 時々操作を終えるのがコピーにおける仕上げの操作、特に非照合されたコピーを実行するために手動の介入を必要とするかもしれないことに注意してください。 この仕様で、処理ステップのいずれかすべてがPrinterオブジェクトの裁量で自動的か手動で働きます。
deBry, et al. Experimental [Page 165] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[165ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
16. APPENDIX E: Generic Directory Schema
16. 付録E: ジェネリックディレクトリ図式
This section defines a generic schema for an entry in a directory service. A directory service is a means by which service users can locate service providers. In IPP environments, this means that IPP Printers can be registered (either automatically or with the help of an administrator) as entries of type printer in the directory using an implementation specific mechanism such as entry attributes, entry type fields, specific branches, etc. IPP clients can search or browse for entries of type printer. Clients use the directory service to find entries based on naming, organizational contexts, or filtered searches on attribute values of entries. For example, a client can find all printers in the "Local Department" context. Authentication and authorization are also often part of a directory service so that an administrator can place limits on end users so that they are only allowed to find entries to which they have certain access rights. IPP itself does not require any specific directory service protocol or provider.
このセクションはジェネリック図式をディレクトリサービスのエントリーと定義します。 ディレクトリサービスはサービス利用者がサービスプロバイダーの場所を見つけることができる手段です。 IPP環境で、これは実装の特定のメカニズムを使用するディレクトリのタイプのエントリーとして登録された(自動的か管理者の助けがある)プリンタがそのようなものであったかもしれないならエントリー属性、エントリータイプ分野、特定のブランチなどとしてそのIPP Printersを意味します。 IPPクライアントは、タイププリンタのエントリーを捜すか、またはブラウズできます。 クライアントは、エントリーの属性値で命名に基づくエントリー、組織的な文脈、またはフィルターにかけることの検索を見つけるのにディレクトリサービスを使用します。 例えば、クライアントは「地方の部」文脈ですべてのプリンタを見つけることができます。 しばしばも認証と承認は、自分達がそれらが、あるアクセス権を持っているエントリーを見つけることができるだけであるように管理者が限界をエンドユーザに置くことができるためのディレクトリサービスの一部です。 IPP自身はどんな特定のディレクトリサービスプロトコルやプロバイダーも必要としません。
Note: Some directory implementations allow for the notion of "aliasing". That is, one directory entry object can appear as multiple directory entry object with different names for each object. In each case, each alias refers to the same directory entry object which refers to a single IPP Printer object.
以下に注意してください。 いくつかのディレクトリ実装が「エイリアシング」の概念を考慮します。 すなわち、1個のディレクトリエントリオブジェクトが各オブジェクトのために異なった名前と共に同じくらい複数のディレクトリエントリオブジェクトに現れることができます。 その都度、各別名は単一のIPP Printerオブジェクトについて言及するのと同じディレクトリエントリオブジェクトについて言及します。
The generic schema is a subset of IPP Printer Job Template and Printer Description attributes (sections 4.2 and 4.4). These attributes are identified as either RECOMMENDED or OPTIONAL for the directory entry itself. This conformance labeling is NOT the same conformance labeling applied to the attributes of IPP Printers objects. The conformance labeling in this Appendix is intended to apply to directory templates and to IPP Printer implementations that subscribe by adding one or more entries to a directory. RECOMMENDED attributes SHOULD be associated with each directory entry. OPTIONAL attributes MAY be associated with the directory entry (if known or supported). In addition, all directory entry attributes SHOULD reflect the current attribute values for the corresponding Printer object.
ジェネリック図式はIPP Printer Job TemplateとPrinter記述属性(セクション4.2と4.4)の部分集合です。 これらの属性はディレクトリエントリ自体のためのRECOMMENDEDかOPTIONALのどちらかとして特定されます。 この順応ラベリングは同じ順応ラベリングがIPP Printersオブジェクトの属性に適用されたということではありません。 このAppendixの順応ラベリングがディレクトリテンプレートと、そして、1つ以上のエントリーをディレクトリに追加することによって申し込まれるIPP Printer実装に適用することを意図します。 RECOMMENDEDはSHOULDを結果と考えます。各ディレクトリエントリに関連してください。 OPTIONAL属性はディレクトリエントリに関連しているかもしれません(知られているか、またはサポートされるなら)。 さらに、すべてのディレクトリエントリ属性SHOULDは対応するPrinterオブジェクトのために現在の属性値を反映します。
The names of attributes in directory schema and entries SHOULD be the same as the IPP Printer attribute names as shown.
IPP Printerと同じくらいが属性名であったなら示されるようにディレクトリ図式とエントリーSHOULDで属性について命名します。
In order to bridge between the directory service and the IPP Printer object, one of the RECOMMENDED directory entry attributes is the Printer object's "printer-uri-supported" attribute. The IPP client queries the "printer-uri-supported" attribute in the directory entry
ディレクトリサービスとIPP Printerオブジェクトの間でブリッジするために、RECOMMENDEDディレクトリエントリ属性の1つはPrinterオブジェクトの「uriが支えたプリンタ」属性です。 IPPクライアントはディレクトリエントリの「uriが支えたプリンタ」属性について質問します。
deBry, et al. Experimental [Page 166] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[166ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
and then addresses the IPP Printer object using one of its URIs. The "uri-security-supported" attribute identifies the protocol (if any) used to secure a channel.
そして、その時は、URIの1つを使用することでIPP Printerオブジェクトを扱います。 「セキュリティがサポートしたuri」属性はチャンネルを固定するのに使用されるプロトコル(もしあれば)を特定します。
The following attributes define the generic schema for directory entries of type PRINTER:
以下の属性はタイプPRINTERのディレクトリエントリーとジェネリック図式を定義します:
printer-uri-supported RECOMMENDED Section 4.4.1
uri-security-supported RECOMMENDED Section 4.4.2
printer-name RECOMMENDED Section 4.4.3
printer-location RECOMMENDED Section 4.4.4
printer-info OPTIONAL Section 4.4.5
printer-more-info OPTIONAL Section 4.4.6
printer-make-and-model RECOMMENDED Section 4.4.8
charset-supported OPTIONAL Section 4.4.15
generated-natural-language-
supported OPTIONAL Section 4.4.17
document-format-supported RECOMMENDED Section 4.4.19
color-supported RECOMMENDED Section 4.4.23
finishings-supported OPTIONAL Section 4.2.6
number-up-supported OPTIONAL Section 4.2.7
sides-supported RECOMMENDED Section 4.2.8
media-supported RECOMMENDED Section 4.2.11
printer-resolution-supported OPTIONAL Section 4.2.12
print-quality-supported OPTIONAL Section 4.2.13
uriが支えたプリンタRECOMMENDEDセクション4.4 .1 セキュリティがサポートしたuri RECOMMENDEDセクション4.4 .2 プリンタ名のRECOMMENDEDセクション4.4 .3 プリンタ位置のRECOMMENDEDセクション4.4 .4 プリンタインフォメーションOPTIONALセクション4.4 .5 プリンタ詳しい情報OPTIONALセクション4.4 .6 プリンタメーカーとモデルRECOMMENDEDセクション4.4 .8 charsetによってサポートされたOPTIONALセクション4.4 .15 発生して当然の言語でサポートしているOPTIONALセクション4; 4.17 形式が支えたドキュメントRECOMMENDEDセクション4.4.19の色でサポートしているRECOMMENDEDセクション4.4.23の仕上げでサポートしているOPTIONALセクション4.2.6サポートされることへの数のOPTIONALセクション4.2.7の側でサポートしているRECOMMENDEDセクション4.2.8のメディアによってサポートされたRECOMMENDEDセクション4.2.11サポートされたプリンタ解決OPTIONALセクション4.2.12品質がサポートした印刷OPTIONALセクション4.2.13
deBry, et al. Experimental [Page 167] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[167ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
17. APPENDIX F: Change History for the IPP Model and Semantics document
17. 付録F: IPP ModelとSemanticsドキュメントのための変化歴史
The following substantive changes and major clarifications have been made to this document from the June 30, 1998 version based on the interoperability testing that took place September 23-25 1998 and subsequent mailing list and meeting discussions. They are listed in the order of occurrence in the document. These changes are the ones that might affect implementations. Clarifications that are unlikely to affect implementations are not listed. The issue numbers refer to the IPP Issues List which is available in the following directory:
以下の実質的な変更と主要な明確化を場所に1998年9月23日から25日がかかった相互運用性テスト、その後のメーリングリスト、およびミーティング議論に基づく1998年6月30日バージョンからこのドキュメントにしました。 それらはドキュメントにおける、発生の注文に記載されています。 これらの変化は実装に影響するかもしれないものです。 実装に影響しそうにない明確化は記載されていません。 問題番号は以下のディレクトリで利用可能なIPP Issues Listについて言及します:
ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/
ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/
Section Description
セクション記述
global Replaced TLS references with SSL3 references as agreed with
our Area Director on 11/12/1998.
11/12/1998の私たちのAreaディレクターとの同意されるとしてのSSL3参照によるグローバルなReplaced TLS参照。
global Removed the indications that some of these IPP documents
are informational, since the intent is now to publish all
IPP/1.0 documents as informational as agreed with our Area
Director on 11/12/1998.
グローバルなRemoved、これらのいくつかのIPPドキュメントが意図が現在、11/12/1998の私たちのAreaディレクターに同意されるのと同じくらい情報のすべてのIPP/1.0ドキュメントを発表することであるので情報であるという指摘。
3.1.2, Clarify that the IPP object SHOULD NOT validate the
16.3.3 range of the request-id being 1 to 2**31-1, but accepts
[now ipp- and returns any value. Clients MUST still keep in the
iig] range 1 to 2**31 though. 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 (Issue 1.36).
3.1.2、Clarify、IPPオブジェクトSHOULD NOTがしかし、1〜2**31-1であるので要求イドの16.3.3範囲を有効にするのは受け入れます。[現在のippといずれも評価するリターン。 クライアントはまだiigに閉じ込めなければなりません。] もっとも範囲1〜2**31。 完全な「要求イド」が受け取られている前に要求が終えられるなら、IPPオブジェクトは、0(問題1.36)の「要求イド」と共に要求を拒絶して、応答を返します。
3.1.4.1, Clarified that when a client submits a request in a
13.1.4.14 charset that is not supported, the IPP object SHOULD
return any 'text' or 'name' attributes in the 'utf-8'
charset, if it returns any, since clients and IPP
objects MUST support 'utf-8'. (Issue 1.19)
3.1.4.1 IPPオブジェクトSHOULDは'utf-8'charsetでどんな'テキスト'か'名前'属性も返します、いずれかも返すなら、クライアントがaを提出するときa13.1.4でサポートされない.14charsetを要求するClarified、クライアントとIPPオブジェクトが'utf-8'をサポートしなければならないので。 (問題1.19)
3.1.4.1 Clarified Section 3.1.4.1 Request Operation Attributes
that a client MAY use the attribute level natural
language override (text/nameWithLanguage) redundantly in
a request. (Issue 1.46)
3.1.4.1 クライアントがそうするはっきりさせられたセクション3.1.4.1Request Operation Attributesが要求で冗長に、属性レベル自然言語オーバーライド(テキスト/nameWithLanguage)を使用します。 (問題1.46)
3.1.4.2 Clarified Section 3.1.4.2 Response Operation Attributes
that an IPP object MAY use the attribute level natural
language override (text/nameWithLanguage) redundantly in
a response. (Issue 1.46)
3.1.4.2 使用するかもしれないIPPが属性を反対させるはっきりさせられたセクション3.1.4.2Response Operation Attributesが応答で冗長に、自然言語オーバーライド(テキスト/nameWithLanguage)を平らにします。 (問題1.46)
deBry, et al. Experimental [Page 168] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[168ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
3.1.6 Clarified section 3.1.6: If the Printer object supports
the "status-message" operation attribute, it NEED NOT
return a status message for the following error status
codes: 'client-error-bad-request', 'client-error-
charset-not-supported', 'server-error-internal-error',
'server-error-operation-not-supported', and 'server-
error-version-not-supported'.
3.1.6 はっきりさせられたセクション3.1.6: Printerオブジェクトが「ステータスメッセージ」操作属性をサポートするなら、以下の誤りステータスコードのためのステータスメッセージを返す必要はありません: 'クライアントの誤りの悪い要求'、'サポートされなかったクライアント誤りcharset'、'サーバ誤り内部エラー'、'操作がサポートしなかったサーバ誤り'、および'サポートされなかったサーバ誤りバージョン'。
3.2.1.1 Clarified that if a client is not supplying any Job
Template attributes in a 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.
This makes [RFC2566] agree with [RFC2565]. (Issue 1.16)
3.2.1.1 はっきりさせられて、それがクライアントであるなら要求におけるどんなJob Template属性も供給していなくて、クライアントSHOULDは空のグループを送るよりむしろGroup2を省略します。 しかしながら、Printerオブジェクトは空のグループを受け入れることができなければなりません。 これで、[RFC2566]は[RFC2565]に同意します。 (問題1.16)
3.2.1.2, Clarified that if an IPP object is not returning any 3.2.5.2, Unsupported Attributes in a response, the IPP object 3.2.6.2, SHOULD omit Group 2 rather than sending an empty group. 3.3.1.2, However, a client MUST be able to accept an empty group. 3.3.3.2, This makes [RFC2566] agree with [RFC2565]. (Issue 1.17) 3.3.4.2
3.2.1.2、Clarified、それ、IPPが、IPPオブジェクトであるならどんな3.2にも.5を返すのが、a応答で.2、Unsupported Attributesでないことを反対する、3.2、.6、.2、SHOULDは空のグループを送るよりむしろGroup2を省略します。 3.3.1.2 However、クライアントは空のグループを受け入れることができなければなりません。 3.3.3.2 Thisは[RFC2566]を[RFC2565]に同意させます。 (問題1.17) 3.3.4.2
3.2.1.2, Clarified that an IPP object MUST treat an unsupported
13.1.2.2, attribute syntax supplied in a request in the same way
13.1.4.12 as an unsupported value. The IPP object MUST return the
attribute, the attribute syntax, and the value in the
Unsupported Attributes group. (Issue 1.26)
.2、属性構文は要求で同じよう13.1に.4を供給しました。3.2.1.2 IPPが反対させるClarifiedがサポートされない13.1に.2を扱わなければならない、.12 サポートされない値として。 IPPオブジェクトはUnsupported Attributesグループで属性、属性構文、および値を返さなければなりません。 (問題1.26)
3.2.5.2, Clarified for Get-Printer-Attributes, Get-Jobs, and Get- 3.2.6.2, Job-Attributes that an IPP object MUST return 3.3.4.2, 'successful-ok-ignored-or-substituted-attributes' (0x1),
3.2.5.2、Getプリンタ属性、Get-ジョブス、およびGet3.2.6.2、IPPオブジェクトがそうしなければならないJob-属性リターンのためのClarified、3.3、.4、.2、'うまくいっているOKは、属性を無視したか、または代入した'(0×1)。
13.1.2.1, rather than 'successful-ok' (0x0), when a client
13.1.2.2, supplies unsupported attributes as values of the
13.1.4.12 'requested-attributes' operation attribute. (Issue
1.24)
Also clarified that 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.
(Issue 1.18)
13.1.2.1 'うまくいっているOK'(0×0)よりむしろいつ、クライアント、13.1、.2、.2、.12'要求された属性'の13.1.4操作属性の値としてサポートされない属性を供給するか。 (問題1.24) また、はっきりさせられて、応答がいずれがある「要求された属性」操作属性を含む必要はないのがクライアントによって要求されましたが、IPPオブジェクトによってサポートされない値(属性キーワード)を供給しました。 (問題1.18)
3.2.6.2 Deleted the job-level natural language override (NLO)
4.1.1.2 from Section 3.2.6.2 Get-Jobs Response so that all
4.3.24 operation responses are the same with respect to NLO.
(Issue 1.47)
3.2.6.2、すべての4.3の.24操作応答がNLOに関して同じであるように、セクション3.2.6.2Get-仕事のResponseから賃仕事のレベル自然言語オーバーライド(NLO)4.1.1.2を削除しました。 (問題1.47)
deBry, et al. Experimental [Page 169] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[169ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
3.3.1 Clarified that an IPP Printer that supports the Create-
Job operation MUST handle the situation when a client
does not supply Send-Document or Send-URI operations
within a one- to four-minute time period. Also
clarified that a client MUST send documents in a multi-
document job without undue or unbounded delay. (Issue
1.28)
3.3.1 はっきりさせられて、クライアントであるときに、Create仕事が操作であるとサポートするIPP Printerが状況を扱わなければならないのが1つの中で4分の期間までSend-ドキュメントかSend-URI操作を供給しません。 また、はっきりさせられて、クライアントが発信しなければならないのが過度の、または、限りない遅れなしでマルチドキュメントに仕事を記録します。 (問題1.28)
3.3.3 Clarified that the IPP object MUST reject a Cancel-Job
request if the job is in 'completed', 'canceled', or
'aborted' job states. (Issue 1.12)
3.3.3 はっきりさせられて、仕事が'完成した'か、'取り消された'か、'中止になっている'仕事の州にあるなら、IPPが反対するのがキャンセル仕事の要求を拒絶しなければなりません。 (問題1.12)
4.1.2.3 Added this new sub-section: it specifies that
nameWithoutLanguage plus the implicit natural language
matches nameWithLanguage, if the values and natural
languages are the same. Also added that keyword never
matches nameWithLanguage or nameWithoutLanguage.
Clarified that if both have countries, that the
countries SHOULD match as well. If either do not, then
the country field SHOULD be ignored. (Issues 1.33 and
1.34)
4.1.2.3 加えられたこれほど新しい小区分: それはそのnameWithoutLanguageを指定します、そして、値と自然言語が同じであるなら、暗黙の自然言語はnameWithLanguageに合っています。 また、キーワードがnameWithLanguageかnameWithoutLanguageに決して合っていないと言い足しました。 それには、はっきりさせられて、国が両方であるならあって、また、国のSHOULDマッチです。 次に、どちらかがそうしないなら、国はSHOULDをさばきます。無視されます。 (問題1.33と1.34)
4.1.5 Clarified regarding the case-insensitivity of URLs to
refer only to the RFCs that define them. (Issue 1.10)
4.1.5 参照するURLの大文字小文字の同一視だけに関して、彼らを定義するRFCsにはっきりさせられます。 (問題1.10)
4.1.11 Clarified that 'boolean' is not a full-sized integer.
(Issue 1.38)
4.1.11 はっきりさせられて、その'論理演算子'は完全サイズの整数ではありません。 (問題1.38)
4.1.15 Clarified that 'resolution' is not three full-sized
integers. (Issue 1.20)
4.1.15 はっきりさせられて、その'解決'は3つの完全サイズの整数ではありません。 (問題1.20)
4.2.* Clarified that standard values are keywords or enums,
not names. (Issue 1.49).
4.2. *そんなに標準ではっきりさせられて、値は、名前的ではなくキーワードかenumsです。 (問題1.49。)
4.2.4 Added the 'single-document-new-sheet' value to Section
4.2.4 multiple-document-handling. (Issue 1.54)
4.2.4 加えられて、'単一のドキュメント新しいシート'は.4の複数のドキュメント処理をセクション4.2に評価します。 (問題1.54)
4.4.18, Clarified that the "document-format-default" and
4.4.19 "document-format-supported" Printer Description
attributes are REQUIRED to agree with the table. (Issue
1.4)
4.4.18 Clarifiedその「ドキュメント形式デフォルト」と4.4.19「形式が支えたドキュメント」Printer記述属性はテーブルに同意するREQUIREDです。 (問題1.4)
4.4.21 Changed "queued-job-count" from OPTIONAL to RECOMMENDED.
(Issue 1.14)
4.4.21 任意であるのから推薦された変えられた「列に並ばせられた仕事のカウント。」 (問題1.14)
deBry, et al. Experimental [Page 170] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[170ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
4.4.28 Clarified that the implementation supplied value for the
"multiple-operation-time-out" attribute SHOULD be
between 30 and 240 seconds, though the implementation
MAY allow the administrator to set values, and MAY allow
values outside this range. (Issue 1.28)
4.4.28 はっきりさせられて、実装が「複数の操作タイムアウト」属性SHOULDに値を供給したのが、管理者が実装で値を設定できるかもしれませんが、30〜240秒であり、この範囲の外に値を許容するかもしれません。 (問題1.28)
5.1, Clarified Client Conformance that if a client supports
5.2.5 an attribute of 'text' attribute syntax, that it MUST
support both the textWithoutLanguage and the
textWithLanguage forms. Same for 'name' attribute
syntax. Same for an IPP object (Issue 1.48)
5.1、Clarified Client Conformance、それ、クライアントサポートである、5.2、.5、'テキスト'属性構文の属性、両方がtextWithoutLanguageとtextWithLanguageであるとサポートしなければならないのが'名前'属性構文のために. 同じことを形成します。 IPPオブジェクトのための同じこと(問題1.48)
6.5, Added new section to allow Attribute Groups to be
12.8 registered as extensions for being passed in operation
requests and responses. (Issue 1.25)
6.5 Attribute Groupsが12.8であることを許容するAddedの新しい部は操作要求と応答で通過されるための拡大として示されました。 (問題1.25)
7. Updated the table of text and name attributes to agree
with Section 4.2.
7. セクション4.2に同意するためにテキストと名前属性のテーブルをアップデートしました。
8.5 Added a new section RECOMMENDING that the Get-Jobs
SHOULD return non-IPP jobs whether or not assigning them
a job-id and job-uri. Also RECOMMENDED generating, if
possible, job-id and job-uri and supporting other IPP
operations on foreign jobs as an implementer option.
(Issue 1.32)
8.5がGet-ジョブスSHOULDが割り当てながら非IPP仕事を返す新しいセクションRECOMMENDINGを加えた、それら、仕事イドと仕事-uri。 できれば、仕事イドと仕事-uriを生成して、implementerオプションとして外国仕事の他のIPP操作をサポートするRECOMMENDEDも。 (問題1.32)
9. Updated document references.
9. ドキュメント参照をアップデートしました。
13.1.4.14 Clarified 'client-error-charset-not-supported' that
'utf-8' must be used for any 'text' or 'name' attributes
returned in the error response (Issue 1.19).
13.1.4.14 誤り応答(問題1.19)で返されたどんな'テキスト'か'名前'属性にもはっきりさせられた'charsetがサポートしなかったクライアント誤り'それ'utf-8'を使用しなければなりません。
13.1.5.9 Added a new error code 'server-error-job-canceled'
(0x0508) to be returned if a job is canceled by another
client or aborted by the IPP object while the first
client is still sending the document data. (Issue 1.29)
13.1.5.9 加えられて、最初のクライアントがまだドキュメントデータを送る間、返される新しいエラーコード'中止されたサーバ誤り仕事'(0×0508)は、仕事であるなら別のクライアントによって取り消されるか、またはIPPオブジェクトによって中止されます。 (問題1.29)
15.3, Moved these sections recommending operation processing
15.4 steps to the new Implementer's Guide (informational).
There indicated that all of the error checks are not
required, so an IPP object MAY be forgiving and accept
non-conforming requests. However, a conforming client
MUST supply requests that would pass all of the error
checks indicated. (Issue 1.21)
15.3 これらのセクションが新しいImplementerのガイド(情報の)に踏むことを操作処理15.4を勧めるMoved。 そこでは、エラーチェックのすべては必要でないことを示して、寛大であるので、非の従う要求を受け入れるかもしれませんIPPが、反対する。 しかしながら、従っているクライアントはチェックが示した誤りのすべてを通過する要求を提供しなければなりません。 (問題1.21)
deBry, et al. Experimental [Page 171] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[171ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
16 Changed directory schema attributes from REQUIRED to
RECOMMENDED. Changed some of the OPTIONAL to
RECOMMENDED to agree with the SLP template. Changed the
"charset-supported" and "natural-language-supported"
from REQUIRED to OPTIONAL. Recommended that the names
be the same in a directory entry as the IPP attribute
names. (Issue 1.53)
16はディレクトリ図式属性をREQUIREDからRECOMMENDEDに変えました。 SLPテンプレートに同意するためにいくらかのOPTIONALをRECOMMENDEDに変えました。 任意に必要であることで、「charsetによってサポートされること」と「サポートされた自然な言語」を変えます。 名前がディレクトリエントリでIPPが名前を結果と考えるのと同じであることを推薦しました。 (問題1.53)
deBry, et al. Experimental [Page 172] RFC 2566 IPP/1.0: Model and Semantics April 1999
deBry、他 実験的な[172ページ]RFC2566IPP/1.0: モデルと意味論1999年4月
18. Full Copyright Statement
18. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
deBry, et al. Experimental [Page 173]
deBry、他 実験的[173ページ]
一覧
スポンサーリンク
