RFC3510 日本語訳
3510 Internet Printing Protocol/1.1: IPP URL Scheme. R. Herriot, I.McDonald. April 2003. (Format: TXT=22009 bytes) (Updates RFC2910) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Herriot Request for Comments: 3510 I. McDonald Updates: 2910 High North Inc. Category: Standards Track April 2003
コメントを求めるワーキンググループR.エリオの要求をネットワークでつないでください: 3510のI.マクドナルドアップデート: 2910年の高い北の株式会社カテゴリ: 標準化過程2003年4月
Internet Printing Protocol/1.1:
IPP URL Scheme
インターネット印刷プロトコル/1.1: IPP URL体系
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service.
このメモは"ipp"URL(Uniform Resource Locator)体系を定義します。 このメモはIPP/1.1をアップデートします: コード化とTransport(RFC2910)、セクション5を広げて、はっきりさせることによって、RFC2910で「IPP URLは計画します」。 "ipp"URLは、IPPがプロトコルであるとサポートする印刷サービス(RFC2910)、またはそのような印刷サービスで管理されたネットワーク資源(例えば、印刷仕事)のネットワークの位置を指定するのに使用されます。
Table of Contents
目次
1. Introduction ............................................... 2
2. Terminology ................................................ 3
2.1. Conformance Terminology .............................. 3
2.2. Model Terminology .................................... 3
3. IPP Model for Printers and Jobs ............................ 3
4. IPP URL Scheme ............................................. 4
4.1. IPP URL Scheme Applicability ......................... 4
4.2. IPP URL Scheme Associated Port ....................... 4
4.3. IPP URL Scheme Associated MIME Type .................. 5
4.4. IPP URL Scheme Character Encoding .................... 5
4.5. IPP URL Scheme Syntax ................................ 5
4.6. IPP URL Examples ..................................... 6
4.6.1. IPP Printer URL Examples ..................... 6
4.6.2. IPP Job URL Examples ......................... 6
4.7. IPP URL Comparisons .................................. 7
1. 序論… 2 2. 用語… 3 2.1. 順応用語… 3 2.2. 用語をモデル化してください… 3 3. IPPはプリンタと仕事のためにモデル化します… 3 4. IPP URL体系… 4 4.1. IPP URL体系の適用性… 4 4.2. IPP URL体系はポートを関連づけました… 4 4.3. IPP URL体系はMIMEの種類を関連づけました… 5 4.4. IPP URL体系文字符号化… 5 4.5. IPP URL体系構文… 5 4.6. IPP URLの例… 6 4.6.1. IPPプリンタURLの例… 6 4.6.2. IPP仕事のURLの例… 6 4.7. IPP URL比較… 7
Herriot & McDonald Standards Track [Page 1] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[1ページ]。
5. Conformance Requirements ................................... 8
5.1. IPP Client Conformance Requirements .................. 8
5.2. IPP Printer Conformance Requirements ................. 8
6. IANA Considerations ........................................ 9
7. Internationalization Considerations ........................ 9
8. Security Considerations .................................... 9
9. Intellectual Property Rights ............................... 10
10. Normative References ....................................... 11
11. Informative References ..................................... 11
12. Acknowledgments ............................................ 12
Appendix A - Registration of "ipp" URL Scheme .................. 13
Authors' Addresses ............................................. 15
Full Copyright Statement ....................................... 16
5. 順応要件… 8 5.1. IPPクライアント順応要件… 8 5.2. IPPプリンタ順応要件… 8 6. IANA問題… 9 7. 国際化問題… 9 8. セキュリティ問題… 9 9. 知的所有権はまっすぐになります… 10 10. 標準の参照… 11 11. 有益な参照… 11 12. 承認… 12 付録A--"ipp"URL体系の登録… 13人の作者のアドレス… 15 完全な著作権宣言文… 16
1. Introduction
1. 序論
This memo conforms to all of the requirements in Registration Procedures for URL Scheme Names [RFC2717]. This memo also follows all of the recommendations in Guidelines for new URL Schemes [RFC2718].
このメモはURL Scheme Names[RFC2717]のためのRegistration Proceduresで要件のすべてに一致しています。 また、このメモは新しいURL Schemes[RFC2718]のためのGuidelinesで推薦のすべてに続きます。
See section 1, "Introduction", of [RFC2911] and section 1, "Introduction", of [RFC3196] for overview information about IPP. See section 10, "Description of the Base IPP Documents", of [RFC3196] for a full description of the IPP document set.
IPPの概要情報に関してセクション1、[RFC2911]とセクション1、「序論」、[RFC3196]の「序論」を見てください。 IPP文献集合の余すところのない解説に関してセクション10、[RFC3196]「基地のIPPドキュメントの記述」を見てください。
This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910, but does not define any new parameters or other new extensions to the syntax of IPP URLs.
このメモはIPP/1.1をアップデートします: コード化と広がるのによるTransport(RFC2910)と少しの新しいパラメタや他の新しい拡大もIPP URLの構文と定義しないのを除いて、セクション5、RFC2910の「IPP URL体系」をはっきりさせること。
The IPP URL scheme defined in this document is based on the ABNF for the HTTP URL scheme defined in HTTP [RFC2616], which in turn is derived from the URI Generic Syntax [RFC2396] and further updated for IPv6 by [RFC2732]. An IPP URL is transformed into an HTTP URL according to the rules specified in section 5 of IPP Protocol [RFC2910].
本書では定義されたIPP URL体系はURI Generic Syntax[RFC2396]から順番に得られるHTTP[RFC2616]で定義されて、IPv6のために[RFC2732]によってさらにアップデートされたHTTP URL体系のためのABNFに基づいています。 IPPプロトコル[RFC2910]のセクション5で指定された規則に従って、IPP URLはHTTP URLに変えられます。
This document defines IPP URL scheme applicability, associated port
(631), associated MIME type ("application/ipp"), character encoding,
and syntax.
このドキュメントはIPP URL体系の適用性、関連ポート(631)、関連MIMEの種類(「アプリケーション/ipp」)、文字符号化、および構文を定義します。
This document is laid out as follows:
このドキュメントは以下の通り広げられます:
- Section 2 defines the terminology used throughout the document.
- セクション2はドキュメント中で使用される用語を定義します。
- Section 3 supplies references to the IPP Printer and IPP Job
object model defined in IPP Model [RFC2911].
- セクション3はオブジェクト・モデルがIPP Model[RFC2911]で定義したIPP PrinterとIPP Jobに参照を供給します。
Herriot & McDonald Standards Track [Page 2] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[2ページ]。
- Section 4 specifies the IPP URL scheme.
- セクション4はIPP URL体系を指定します。
- Section 5 specifies the conformance requirements for IPP Clients
and IPP Printers that claim conformance to this document.
- セクション5はこのドキュメントに順応を要求するIPP ClientsとIPP Printersのための順応要件を指定します。
- Sections 6, 7, and 8 specify IANA, internationalization, and
security considerations.
- セクション6、7、および8 IANA、国際化、およびセキュリティ問題を指定してください。
- Sections 9, 10, 11, 12, and 13 specify normative references,
informative references, acknowledgements, authors' addresses, and
full IETF copyright statement.
- セクション9、10、11、12、および13 引用規格、有益な参照、承認、作者のアドレス、および完全なIETF著作権宣言文を指定してください。
- Section 14 (Appendix A) is a completed registration template for
the IPP URL Scheme (see section 6.0 of [RFC2717]).
- セクション14(付録A)はIPP URL Schemeのための完成した登録テンプレート([RFC2717]のセクション6.0を見る)です。
2. Terminology
2. 用語
This specification document uses the terminology defined in this
section.
この仕様ドキュメントはこのセクションで定義された用語を使用します。
2.1. Conformance Terminology
2.1. 順応用語
The uppercase terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. These terms are used to specify conformance
requirements for all implementations (both print clients and print
services) of this specification.
大文字している用語“MUST"、「必須NOT」が「必要です」、“SHALL"、「」 “SHOULD"でない、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか? これらの用語は、この仕様のすべての実装(クライアントを印刷して、サービスを印刷する)のための順応要件を指定するのに使用されます。
2.2. Model Terminology
2.2. モデル用語
See section 12.2, "Model Terminology", in IPP Model [RFC2911].
IPP Model[RFC2911]の「用語をモデル化してください」というセクション12.2を見てください。
3. IPP Model for Printers and Jobs
3. IPPはプリンタと仕事のためにモデル化します。
See section 2, "IPP Objects", section 2.1, "Printer Object", and
section 2.2, "Job Object", in [RFC2911] for a full description of
the IPP object model and terminology.
[RFC2911]でIPPオブジェクト・モデルと用語の余すところのない解説に関してセクション2、「IPPオブジェクト」セクション2.1、「プリンタオブジェクト」とセクション2.2、「仕事のオブジェクト」を見てください。
In this document, "IPP Client" means the software (on some
hardware platform) that submits, monitors, and/or manages print
jobs via the IPP Protocol [RFC2910] to a print spooler, print
gateway, or physical printing device.
本書では、「IPPクライアント」はプリントスプーラへのIPPプロトコル[RFC2910]で、印刷仕事を提出して、モニターする、そして/または、管理するソフトウェア(いくつかのハードウェアプラットホームの)、印刷ゲートウェイ、または物理的な印刷デバイスを意味します。
Herriot & McDonald Standards Track [Page 3] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[3ページ]。
In this document, "IPP Printer object" means the software (on some
hardware platform) that receives print jobs and/or printer/job
operations via the IPP Protocol [RFC2910] from an "IPP Client".
本書では、「IPP Printerオブジェクト」は「IPPクライアント」からのIPPプロトコル[RFC2910]で印刷仕事、そして/または、プリンタ/仕事の操作を受けるソフトウェア(いくつかのハードウェアプラットホームの)を意味します。
In this document, "IPP Printer" is a synonym for "IPP Printer
object".
本書では、「IPPプリンタ」は、「IPP Printerは反対する」同義語です。
In this document, "IPP Job object" means the set of attributes and
documents for one print job instantiated on an "IPP Printer".
属性のセットは、本書では、「IPP Jobは反対すること」を意味します、そして、ドキュメントは個人的には「IPPプリンタ」に例示された仕事を印刷します。
In this document, "IPP Job" is a synonym for "IPP Job object".
本書では、「IPP仕事」は、「IPP Jobは反対する」同義語です。
In this document, "IPP URL" means a URL with the "ipp" scheme.
本書では、「IPP URL」は"ipp"体系があるURLを意味します。
Note: In this document, "IPP URL" is a synonym for "ipp-URL" (in
section 4, "IPP URL Scheme", of this document) and "ipp-URL" (in
section 5, "IPP URL Scheme", of [RFC2910]).
以下に注意してください。 本書では、「IPP URL」は「ipp-URL」(セクション4のこのドキュメントの「IPP URL体系」)と「ipp-URL」(セクション5の[RFC2910]の「IPP URL体系」)のための同義語です。
4. IPP URL Scheme
4. IPP URL体系
4.1. IPP URL Scheme Applicability
4.1. IPP URL体系の適用性
The "ipp" URL scheme MUST only be used to specify absolute URLs
(relative IPP URLs are not allowed) for IPP print services and
their associated network resources. The "ipp" URL scheme MUST
only be used to specify the use of the abstract protocol defined
in IPP Model [RFC2911] over an HTTP [RFC2616] transport, as
defined in IPP Protocol [RFC2910]. Any other transport binding
for the abstract protocol defined in IPP Model [RFC2911] would
require a different URL scheme.
絶対URL(相対的なIPP URLは許容されていない)をIPP印刷サービスとそれらの関連ネットワーク資源に指定するのに"ipp"URL体系を使用するだけでよいです。 HTTP[RFC2616]輸送の上でIPP Model[RFC2911]で定義された抽象的なプロトコルの使用を指定するのに"ipp"URL体系を使用するだけでよいです、IPPプロトコル[RFC2910]で定義されるように。 IPP Model[RFC2911]で定義された抽象的なプロトコルで付くいかなる他の輸送も異なったURL体系を必要とするでしょう。
The "ipp" URL scheme allows an IPP client to choose an appropriate
IPP print service (for example, from a directory). The IPP client
can establish an HTTP connection to the specified IPP print
service. The IPP client can send IPP protocol requests (for
example, a "Print-Job" request) and receive IPP protocol responses
over that HTTP connection.
"ipp"URL体系で、IPPクライアントは適切なIPP印刷サービス(例えばディレクトリから)を選ぶことができます。 IPPクライアントは指定されたIPP印刷サービスにHTTP接続を確立できます。 IPPクライアントは、プロトコル要求(例えば、「印刷仕事」要求)をIPPに送って、そのHTTP接続の上にIPPプロトコル応答を受けることができます。
4.2. IPP URL Scheme Associated Port
4.2. IPPのURLの体系の関連ポート
All IPP URLs which do NOT explicitly specify a port MUST be
resolved to IANA-assigned well-known port 631, as registered in
[IANA-PORTREG].
明らかにポートを指定しないすべてのIPP URLをIANAによって割り当てられたウェルノウンポート631に決議しなければなりません、[IANA-PORTREG]に登録されるように。
See: IANA Port Numbers Registry [IANA-PORTREG].
See: IPP Protocol [RFC2910].
見ます: IANAは数の登録[IANA-PORTREG]を移植します。 見ます: IPPは[RFC2910]について議定書の中で述べます。
Herriot & McDonald Standards Track [Page 4] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[4ページ]。
4.3. IPP URL Scheme Associated MIME Type
4.3. IPPのURLの体系の関連MIMEの種類
All IPP URLs MUST be used to specify network print services which
support the "application/ipp" MIME media type as registered in
[IANA-MIMEREG] for IPP protocol requests and responses.
IPPプロトコル要求のために「アプリケーション/ipp」MIMEが登録されるとして[IANA-MIMEREG]のメディアタイプであるとサポートするネットワーク印刷サービスと応答を指定するのにすべてのIPP URLを使用しなければなりません。
See: IANA MIME Media Types Registry [IANA-MIMEREG].
See: IPP Protocol [RFC2910].
見ます: IANAはメディアタイプのために登録[IANA-MIMEREG]をまねます。 見ます: IPPは[RFC2910]について議定書の中で述べます。
4.4. IPP URL Scheme Character Encoding
4.4. IPP URL体系文字符号化
IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP
URLs. Characters other than those in the "reserved" and "unsafe"
sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.
IPP URLはそれらの同等なHTTP URLのように[RFC2396]コード化を使用しなければなりません。 「予約され」て「危険な」セット[RFC2396]におけるそれら以外のキャラクターはそれらの「「%」十六進法十六進法」コード化に同等です。
4.5. IPP URL Scheme Syntax
4.5. IPP URL体系構文
The abstract protocol defined in IPP Model [RFC2911] places a
limit of 1023 octets (NOT characters) on the length of a URI (see
section 4.1.5, "uri", in [RFC2911]).
抽象的なプロトコルはIPP Model[RFC2911]場所でURIの長さにおける1023の八重奏(キャラクタでない)の限界を定義しました(セクション4.1.5、"uri"を見てください、[RFC2911]で)。
Note: IPP Printers ought to be cautious about depending on URI
lengths above 255 bytes, because some older client implementations
might not properly support these lengths.
以下に注意してください。 IPP Printersは255バイトより高いURIの長さに依存することに関して用心深くあるべきです、いくつかのさらに古いクライアント実装が適切にこれらの長さをサポートしないかもしれないので。
IPP URLs MUST be represented in absolute form. Absolute URLs MUST always begin with a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This specification adopts the definitions of "host", "port", "abs_path", and "query" from [RFC2396], as updated for IPv6 by [RFC2732].
絶対フォームにIPP URLを表さなければなりません。 コロンが体系名のあとに続いていて、絶対URLはいつも始まらなければなりません。 URL構文と意味論の決定的な情報に関しては、見てください、「Uniform Resource Identifier(URI):」 「ジェネリック構文と意味論」[RFC2396。] IPv6のために[RFC2732]によってアップデートされるようにこの仕様は[RFC2396]から「ホスト」、「ポート」、「腹筋_経路」、および「質問」の定義を採用します。
The IPP URL scheme syntax in ABNF is as follows:
ABNFのIPP URL体系構文は以下の通りです:
ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
ipp-URL=は「以下をippします」。 「//」ホスト[「:」 ポート][腹筋_経路[“?"質問]]
If the port is empty or not given, port 631 is assumed. The semantics are that the identified resource (see section 5.1.2 of [RFC2616]) is located at the IPP print service listening for HTTP connections on that port of that host, and the Request-URI for the identified resource is 'abs_path'.
ポートが人影がないか考えないで、ポート631は想定されます。 意味論は特定されたリソース(.2セクション5.1[RFC2616]を見る)がそのホストのそのポートの上でHTTP接続の聞こうとするIPP印刷サービスで位置しているということです、そして、特定されたリソースのためのRequest-URIは'腹筋_経路'です。
If the 'abs_path' is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (see section 5.1.2 of [RFC2616]).
「'腹筋_経路'がURLに存在していないなら、」 /としてそれを与えなければなりません」。リソース(.2セクション5.1[RFC2616]を見る)にRequestユリとして使用されると。
Herriot & McDonald Standards Track [Page 5] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[5ページ]。
4.6. IPP URL Examples
4.6. IPP URLの例
Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in IPP URLs.
以下に注意してください。 文字通りのIPv4かIPv6が中古のコネがIPP URLであったならSHOULD NOTを扱います。
4.6.1. IPP Printer URL Examples
4.6.1. IPPプリンタURLの例
The following are examples of well-formed IPP URLs for IPP Printers (for example, to be used as protocol elements in 'printer-uri' operation attributes of 'Print-Job' request messages):
↓これはIPP Printers(例えばプロトコル要素として'印刷仕事'要求メッセージの'プリンタ-uri'操作属性に使用される)のための整形式のIPP URLに関する例です:
ipp://example.com
ipp://example.com/printer
ipp://example.com/printer/tiger
ipp://example.com/printer/fox
ipp://example.com/printer/tiger/bob
ipp://example.com/printer/tiger/ira
ipp://example.com ipp://example.com/プリンタipp://example.com/プリンタ/虎のipp://example.com/プリンタ/キツネipp://example.com/プリンタ/虎/ボブのipp://example.com/プリンタ/虎/ira
Each of the above URLs are well-formed URLs for IPP Printers and each would reference a logically different IPP Printer, even though some of those IPP Printers might share the same host system. The 'bob' or 'ira' last path components might represent two different physical printer devices, while 'tiger' might represent some grouping of IPP Printers (for example, a load-balancing spooler). Or the 'bob' and 'ira' last path components might represent separate human recipients on the same physical printer device (for example, a physical printer supporting two job queues). In either case, both 'bob' and 'ira' would behave as different and independent IPP Printers.
それぞれの上のURLは、IPP Printersのための整形式のURLであり、それぞれ論理的に異なったIPP Printerに参照をつけるでしょう、それらのいくつかのIPP Printersが同じホストシステムを共有するかもしれませんが。 '虎'がIPP Printers(例えば、負荷分散スプーラ)の何らかの組分けを表すかもしれない間の'ボブ'か2台の最後の経路コンポーネントが表すかもしれない'ira'異なった物理的なプリンタデバイス。 または、'ボブ'と最後の経路コンポーネントが表すかもしれない'ira'は同じ物理的なプリンタデバイス(例えば、2つのジョブキューをサポートする物理的なプリンタ)で人間の受取人を切り離します。 どちらかの場合では、両方が'たたかれます'、そして、'ira'は異なって独立しているIPP Printersとして振る舞うでしょう。
The following are examples of well-formed IPP URLs for IPP Printers with (optional) ports and paths:
↓これは(任意)のポートと経路があるIPP Printersのための整形式のIPP URLに関する例です:
ipp://example.com
ipp://example.com/~smith/printer
ipp://example.com:631/~smith/printer
ipp://example.com ipp://example.com/~鍛冶屋/プリンタipp://example.com: 631/~鍛冶屋/プリンタ
The first and second IPP URLs above MUST be resolved to port 631 (IANA assigned well-known port for IPP). The second and third IPP URLs above are equivalent (see section 4.7 below).
631を移植するために1番目と上の第2IPP URLを決議しなければなりません(IANAはIPPのためにウェルノウンポートを割り当てました)。 2番目と上の第3IPP URLは同等です(下のセクション4.7を見てください)。
4.6.2. IPP Job URL Examples
4.6.2. IPP仕事のURLの例
The following are examples of well-formed IPP URLs for IPP Jobs (for example, to be used as protocol elements in 'job-uri' attributes of 'Print-Job' response messages):
↓これはIPPジョブス(例えばプロトコル要素として'印刷仕事'応答メッセージの'仕事-uri'属性に使用される)のための整形式のIPP URLに関する例です:
ipp://example.com/printer/123
ipp://example.com/printer/tiger/job123
ipp://example.com/プリンタ/123ipp://example.com/プリンタ/虎/job123
Herriot & McDonald Standards Track [Page 6] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[6ページ]。
IPP Job URLs are valid and meaningful only until Job completion and possibly an implementation defined optional period of persistence after Job completion (see IPP Model [RFC2911]).
Job完成とことによると実装がJob完成の後に任意の期間の固執を定義するまでしか(IPP Model[RFC2911]を見てください)、IPP Job URLは、有効であって、重要ではありません。
Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states that:
あいまいに、IPP Model[RFC2911]のセクション4.3.1'仕事-uri'は、以下のことと述べます。
"the precise format of a Job URI is implementation dependent."
「Job URIの正確な形式は実装に依存しています。」
Thus, the relationship between the value of the "printer-uri" operation attribute used in a 'Print-Job' request and the value of the "job-uri" attribute returned in the corresponding 'Print-Job' response is implementation dependent. Also, section 4.3.3 'job- printer-uri' of IPP Model [RFC2911] states that the 'job-printer-uri' attribute of a Job object:
したがって、'印刷仕事'要求で使用される「プリンタ-uri」操作属性の値と対応する'印刷仕事'応答で返された「仕事-uri」属性の値との関係は実装に依存しています。 また、IPP Model[RFC2911]のセクション4.3.3'仕事のプリンタ-uri'はJobオブジェクトのその'仕事のプリンタuri'属性を述べます:
"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."
「クライアントがクライアントにとって、JobオブジェクトのURIだけが利用可能であるときにこのJobオブジェクトを作成したPrinterオブジェクトを特定することを許可します。」
However, the above statement is false, because the transform from an IPP Job URL to the corresponding IPP Printer URL is unspecified in either IPP Model [RFC2911] or IPP Protocol [RFC2910].
しかしながら、上の陳述は誤っています、IPP Job URLから対応するIPP Printer URLまでの変換がIPP Model[RFC2911]かIPPプロトコル[RFC2910]のどちらかで不特定であるので。
IPP Printers that conform to this specification SHOULD only generate IPP Job URLs (for example, in the "job-uri" attribute in a 'Print- Job' response) by appending exactly one path component to the corresponding IPP Printer URL (for interoperability).
この仕様SHOULDに従うIPP Printersは、対応するIPP Printer URL(相互運用性のための)にまさに1つの経路コンポーネントを追加することによって、URL(例えば'印刷仕事'応答における「仕事-uri」属性で)をIPP Jobに生成するだけです。
4.7. IPP URL Comparisons
4.7. IPP URL比較
When comparing two IPP URLs to decide if they match or not, an IPP Client MUST use the same rules as those defined for HTTP URI comparisons in [RFC2616], with the sole following exception:
それらが合っているかどうか決めるために2つのIPP URLを比較するとき、IPP Clientは[RFC2616]でHTTP URI比較のために定義されたものと同じ規則を使用しなければなりません、唯一の次の例外で:
- A port that is empty or not given MUST be treated as equivalent to
the well-known port for that IPP URL (port 631);
- そのIPP URLのために人影がないか与えられなかったポートをウェルノウンポートと同等物として扱わなければなりません(631を移植してください)。
See: Section 3.2.3, "URI Comparison", in [RFC2616].
見ます: セクション3.2 .3 [RFC2616]の「URI比較。」
Herriot & McDonald Standards Track [Page 7] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[7ページ]。
5. Conformance Requirements
5. 順応要件
5.1. IPP Client Conformance Requirements
5.1. IPPクライアント順応要件
IPP Clients that conform to this specification:
この仕様に以下を従わせるIPP Clients
a) MUST only send IPP protocol connections to the port specified in
each given IPP URL (if present) or otherwise to IANA assigned
well-known port 631;
a) IPP URLを考えて(存在しているなら)、それぞれで指定されたポート、または、そうでなければ、ウェルノウンポート631が割り当てられたIANAにIPPプロトコル接続を送るだけでよいです。
b) MUST only send IPP URLs used as protocol elements in outgoing IPP
protocol request messages (for example, in the "printer-uri"
operation attribute in a 'Print-Job' request) that conform to the
ABNF specified in section 4.5, "IPP URL Scheme Syntax, of this
document;
b) ABNFに従う送信するIPPプロトコル要求メッセージ(例えば'印刷仕事'要求における「プリンタ-uri」操作属性で)のプロトコル要素が、セクション4.5で「このドキュメントのIPP URL Scheme Syntax」と指定したので使用されるURLをIPPに送るだけでよいです。
c) MUST only convert IPP URLs to their corresponding HTTP URL forms
according to the rules in section 5, "IPP URL Scheme", in
[RFC2910].
c) セクション5、「IPP URLは計画するところ」の規則に従って、[RFC2910]でそれらの対応するHTTP URLフォームにIPP URLを変換するだけでよいです。
5.2. IPP Printer Conformance Requirements
5.2. IPPプリンタ順応要件
IPP Printers that conform to this specification:
この仕様に以下を従わせるIPP Printers
a) MUST listen for incoming IPP protocol connections on IANA-assigned
well-known port 631, unless explicitly configured by system
administrators or site policies;
a) システム管理者かサイト方針で明らかに構成されない場合、IANAによって割り当てられたウェルノウンポート631で入って来るIPPプロトコル接続の聞こうとしなければなりません。
b) SHOULD NOT listen for incoming IPP protocol connections on any
other port, unless explicitly configured by system administrators
or site policies;
b) SHOULD NOTはいかなる他のポートの上でも入って来るIPPプロトコル接続の聞こうとします、システム管理者かサイト方針で明らかに構成されない場合。
c) SHOULD only accept IPP URLs used as protocol elements in incoming
IPP protocol request messages (for example, in the "printer-uri"
operation attribute in a 'Print-Job' request) that conform to the
ABNF specified in section 4.5, "IPP URL Scheme Syntax", of this
document;
c) SHOULDはABNFに従う入って来るIPPプロトコル要求メッセージ(例えば'印刷仕事'要求における「プリンタ-uri」操作属性で)のプロトコル要素が、セクション4.5で「IPP URL体系構文」と指定したのでこのドキュメントについて使用されるIPP URLを受け入れるだけです。
d) SHOULD only send IPP URLs used as protocol elements in outgoing
IPP protocol response messages (for example, in the "job-uri"
attribute in a 'Print-Job' response) that conform to the ABNF
specified in section 4.5, "IPP URL Scheme Syntax", of this
document;
d) SHOULDはABNFに従う外向的なIPPプロトコル応答メッセージ(例えば'印刷仕事'応答における「仕事-uri」属性で)におけるプロトコル要素が、セクション4.5で「IPP URL体系構文」と指定したのでこのドキュメントについて使用されるURLをIPPに送るだけです。
e) SHOULD only generate IPP Job URLs (for example, in the "job-uri"
attribute in a 'Print-Job' response) by appending exactly one path
component to the corresponding IPP Printer URL (for
interoperability);
e) SHOULDは対応するIPP Printer URL(相互運用性のための)にまさに1つの経路コンポーネントを追加することによって、URL(例えば'印刷仕事'応答における「仕事-uri」属性で)をIPP Jobに生成するだけです。
Herriot & McDonald Standards Track [Page 8] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[8ページ]。
f) SHOULD NOT use literal IPv6 or IPv4 addresses in configured or
locally generated IPP URLs.
f) SHOULD NOTが文字通りのIPv6を使用するか、またはIPv4は構成されたか、または局所的に生成しているIPPでURLを扱います。
6. IANA Considerations
6. IANA問題
This IPP URL Scheme specification does not introduce any additional IANA considerations, beyond those described in [RFC2910] and [RFC2911].
このIPP URL Scheme仕様は[RFC2910]と[RFC2911]で説明されたものを超えてどんな追加IANA問題も紹介しません。
See: Section 6, "IANA Considerations" in [RFC2910] See: Section 6, "IANA Considerations" in [RFC2911].
見ます: セクション6、[RFC2910]の「IANA問題」は見られます: セクション6、[RFC2911]の「IANA問題。」
7. Internationalization Considerations
7. 国際化問題
This IPP URL Scheme specification does not introduce any additional internationalization considerations, beyond those described in [RFC2910] and [RFC2911].
このIPP URL Scheme仕様は[RFC2910]と[RFC2911]で説明されたものを超えてどんな追加国際化問題も紹介しません。
See: Section 7, "Internationalization Considerations", in [RFC2910]. See: Section 7, "Internationalization Considerations", in [RFC2911].
見ます: セクション7、[RFC2910]の「国際化問題。」 見ます: セクション7、[RFC2911]の「国際化問題。」
8. Security Considerations
8. セキュリティ問題
This IPP URL Scheme specification does not introduce any additional security considerations, beyond those described in [RFC2910] and [RFC2911], except the following:
このIPP URL Scheme仕様は[RFC2910]と[RFC2911]で説明されたものを超えてどんな追加担保問題も紹介しません、以下を除いて:
a) An IPP URL might be faked to point to a rogue IPP print service,
thus collecting confidential document contents from IPP clients.
Server authentication mechanisms and security mechanisms specified
in the IPP Protocol [RFC2910] are sufficient to address this
threat.
a) IPP URLは凶暴なIPP印刷サービスを示すために見せかけられるかもしれません、その結果、IPPクライアントから機密書類コンテンツを集めます。 IPPプロトコル[RFC2910]で指定されたサーバー証明メカニズムとセキュリティー対策は、この脅威を扱うために十分です。
b) An IPP URL might be used to access an IPP print service by an
unauthorized IPP client. Client authentication mechanisms and
security mechanisms specified in the IPP Protocol [RFC2910] are
sufficient to address this threat.
b) IPP URLは、権限のないIPPクライアントによるIPP印刷サービスにアクセスするのに使用されるかもしれません。 IPPプロトコル[RFC2910]で指定されたクライアント認証機構とセキュリティー対策は、この脅威を扱うために十分です。
c) An IPP URL might be used to access an IPP print service at a print
protocol application layer gateway (for example, an IPP to LPD
gateway [RFC2569]) causing silent compromise of IPP security
mechanisms. There is no practical defense against this threat by
a client system. System administrators should avoid such
compromising configurations.
c) IPP URLは、IPPセキュリティー対策の静かな感染を引き起こしながら印刷プロトコル応用層ゲートウェイ(例えば、LPDゲートウェイ[RFC2569]へのIPP)でIPP印刷サービスにアクセスするのに使用されるかもしれません。どんな実用的なディフェンスもクライアントシステムによるこの脅威に反対していません。 システム管理者は、構成に感染しながら、そのようなものを避けるべきです。
d) An IPP URL does not have parameters to specify the required client
authentication mechanism (for example, 'certificate' as defined in
section 4.4.2, "uri-authentication-supported", of IPP Model
d) IPP URLには必要なクライアント認証機構を指定するパラメタがない、(例えば、セクション4.4.2で定義される'証明書'、IPP Modelの「認証がサポートしたuri」
Herriot & McDonald Standards Track [Page 9] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[9ページ]。
[RFC2911]) and required security mechanism (for example, 'tls' as
defined in section 4.4.3, "uri-security-supported", of IPP Model
[RFC2911]). Service discovery or directory protocols might be
used to discover the required client authentication and security
mechanisms associated with given IPP URLs.
[RFC2911)と必要なセキュリティー対策(例えば、セクション4.4.3で定義される'tls'、IPP Modelの「セキュリティがサポートしたuri」[RFC2911])。 サービス発見かディレクトリプロトコルが、必要なクライアント認証と与えられたIPP URLに関連しているセキュリティー対策を発見するのに使用されるかもしれません。
Historical Note: During the development of this document, consideration was given to the addition of standard IPP URL parameters for the client authentication and security mechanisms. However, based on a strong IETF IPP Working Group consensus, no parameters were added to the "ipp" URL scheme as originally defined in IPP Protocol [RFC2910] in September 2000, for reasons of backwards compatibility with the many currently shipping implementations of IPP/1.1.
歴史的な注意: このドキュメントの開発の間、クライアント認証とセキュリティー対策のための標準のIPP URLパラメタの追加に対して考慮を払いました。強いIETF IPP作業部会コンセンサスに基づいたパラメタが全くどのように"ipp"URLに追加されなかったとしても、2000年9月に元々IPPプロトコル[RFC2910]で定義される後方にの理由で、現在IPP/1.1の実装を出荷する多くとの互換性を計画してください。
See: Section 8, "Security Considerations", in [RFC2910]. See: Section 8, "Security Considerations", in [RFC2911].
見ます: セクション8、[RFC2910]の「セキュリティ問題。」 見ます: セクション8、[RFC2911]の「セキュリティ問題。」
9. Intellectual Property Rights
9. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Herriot & McDonald Standards Track [Page 10] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL体系2003年4月にRFC3510を追跡します[10ページ]。
10. Normative References
10. 引用規格
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December
1999.
[RFC2732] HindenとR.と大工とB.とL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1999年12月。
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "IPP/1.1 Encoding and Transport [IPP Protocol]",
RFC 2910, September 2000.
[RFC2910] エリオ、R.、バトラー、S.、ムーア、P.、ターナー、R.、J.Wenn、および「IPP/1.1コード化と輸送[IPPプロトコル]」、RFC2910(2000年9月)
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and
P. Powell, "IPP/1.1 Model and Semantics [IPP Model]",
RFC 2911, September 2000.
[RFC2911] ヘイスティングズ、T.、エリオ、R.、deBry、R.、イサクソン、S.、P.パウエル、および「IPP/1.1モデルと意味論[IPPはモデル化する]」、RFC2911(2000年9月)
[US-ASCII] Coded Character Set -- 7-bit American Standard Code
for Information Interchange, ANSI X3.4-1986.
[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
11. Informative References
11. 有益な参照
[IANA-MIMEREG] IANA MIME Media Types Registry.
ftp://ftp.iana.org/in-notes/iana/assignments/media-
types/...
[IANA-MIMEREG]IANA MIMEメディアTypes Registry ftp://ftp.iana.org/in-notes/iana/assignments/media- タイプ/…
[IANA-PORTREG] IANA Port Numbers Registry. ftp://ftp.iana.org/in-
notes/iana/assignments/port-numbers
[IANA-PORTREG]IANA Port民数記Registry ftp://ftp.iana.org/in- 注意/iana/課題/ポートナンバー
[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月。
[RFC2717] Petke, R. and I. King, "Registration Procedures for
URL Scheme Names", RFC 2717, November 1999.
[RFC2717] PetkeとR.とI.キング、「URL体系名のための登録手順」、RFC2717、1999年11月。
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R.
Petke, "Guidelines for new URL Schemes", RFC 2718,
November 1999.
[RFC2718] MasinterとL.とAlvestrandとH.とZigmondとD.とR.Petke、「新しいURL Schemesのためのガイドライン」、RFC2718、1999年11月。
Herriot & McDonald Standards Track [Page 11] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL計画2003年4月にRFC3510を追跡します[11ページ]。
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C. and
H. Holst, "Internet Printing Protocol/1.1:
Implementor's Guide", RFC 3196, November 2001.
[RFC3196] ヘイスティングズとT.とManrosとC.とZehlerとP.とクーグラーとC.とH.ホルスト、「プロトコル/1.1に以下を印刷するインターネット」 「作成者のガイド」、RFC3196、2001年11月。
12. Acknowledgments
12. 承認
This document is a product of the Internet Printing Protocol Working Group of the Internet Engineering Task Force (IETF).
このドキュメントはインターネットPrintingプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。
Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM), Hugo Parra (Novell), Don Wright (Lexmark), and all the members of the IETF IPP WG.
パット・フレミング(IBM)、トム・ヘイスティングズ(ゼロックス)、ハリー・ルイス(IBM)、ユーゴー・パラ(ノベル)、ドン・ライト(Lexmark)、およびIETF IPP WGのすべてのメンバーをありがとうございます。
Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910] was the primary input to this IPP URL Scheme specification.
セクション5、IPPプロトコルで「IPP URLは計画すること」が[RFC2910]、このIPP URL Scheme仕様への本源的投入でした。
Herriot & McDonald Standards Track [Page 12] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL計画2003年4月にRFC3510を追跡します[12ページ]。
Appendix A - Registration of "ipp" URL Scheme
付録A--"ipp"URL計画の登録
Note: The following registration obsoletes section 5, "IPP URL Scheme", of IPP Protocol [RFC2911].
以下に注意してください。 以下の登録はセクション5、IPPプロトコルの「IPP URL計画」を時代遅れにします[RFC2911]。
URL Scheme Name: ipp
URL計画名: ipp
URL Scheme Syntax:
URL計画構文:
ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
ipp-URL=は「以下をippします」。 「//」ホスト[「:」 ポート][腹筋_経路[“?"質問]]
Character Encoding Considerations:
問題をコード化するキャラクター:
IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP
URLs. Characters other than those in the "reserved" and "unsafe"
sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.
IPP URLはそれらの同等なHTTP URLのように[RFC2396]コード化を使用しなければなりません。 「予約され」て「危険な」セット[RFC2396]におけるそれら以外のキャラクターはそれらの「「%」十六進法十六進法」コード化に同等です。
Intended Usage:
意図している用法:
The intended usage of the "ipp" URL scheme is COMMON.
"ipp"URL計画の意図している用法はCOMMONです。
An "ipp" URL is used to specify the network location of a print
service that supports the IPP Protocol [RFC2910], or of a network
resource (for example, a print job) managed by such a print
service. An IPP client can choose to establish an HTTP connection
to the specified print service for transmission of IPP protocol
requests (for example, IPP print job submission requests).
"ipp"URLは、IPPプロトコルをサポートする印刷サービス[RFC2910]、またはそのような印刷サービスで管理されたネットワーク資源(例えば、印刷仕事)のネットワークの位置を指定するのに使用されます。 IPPクライアントは、IPPプロトコル要求の伝達のための指定された印刷サービスにHTTP接続を確立するのを選ぶことができます(例えば、IPPはジョブ依頼要求を印刷します)。
Applications or Protocols which use this URL scheme:
このURL計画を使用するアプリケーションかプロトコル:
See: Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910].
見ます: セクション5、IPPの「IPP URL計画」は[RFC2910]について議定書の中で述べます。
Interoperability Considerations:
相互運用性問題:
See: Section 9, "Interoperability with IPP/1.0 Implementations",
in IPP Protocol [RFC2910].
見ます: セクション9、IPPの「IPP/1.0実現がある相互運用性」は[RFC2910]について議定書の中で述べます。
Security Considerations:
セキュリティ問題:
See: Section 8, "Security Considerations", in IPP Protocol
[RFC2910].
見ます: セクション8、IPPの「セキュリティ問題」は[RFC2910]について議定書の中で述べます。
Relevant Publications:
関連刊行物:
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn,
"IPP/1.1 Encoding and Transport [IPP Protocol]", RFC 2910,
September 2000.
[RFC2910] エリオ、R.、バトラー、S.、ムーア、P.、ターナー、R.、J.Wenn、および「IPP/1.1コード化と輸送[IPPプロトコル]」、RFC2910(2000年9月)
Herriot & McDonald Standards Track [Page 13] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL計画2003年4月にRFC3510を追跡します[13ページ]。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC3510] Herriot, R. and I. McDonald, "IPP/1.1: IPP URL Scheme", RFC
3510, April 2003.
[RFC3510] エリオ、R.、およびI.マクドナルド、「IPP/1.1:」 「IPP URL計画」、RFC3510、2003年4月。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303
Aveパロアルト、ロバートエリオコンサルタント706Coloradoカリフォルニア 94303
Phone: +1 650-327-4466 EMail: bob@herriot.com
以下に電話をしてください。 +1 650-327-4466 メールしてください: bob@herriot.com
Ira McDonald High North Inc 221 Ridge Ave Grand Marais, MI 49839
MI Aveの壮大なマレ、イラマクドナルド高い北のInc221Ridge49839
Phone: +1 906-494-2434 EMail: imcdonald@sharplabs.com
以下に電話をしてください。 +1 906-494-2434 メールしてください: imcdonald@sharplabs.com
Herriot & McDonald Standards Track [Page 14] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL計画2003年4月にRFC3510を追跡します[14ページ]。
Authors' Addresses
作者のアドレス
Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303
Aveパロアルト、ロバートエリオコンサルタント706Coloradoカリフォルニア 94303
Phone: +1 650-327-4466 EMail: bob@herriot.com
以下に電話をしてください。 +1 650-327-4466 メールしてください: bob@herriot.com
Ira McDonald High North Inc 221 Ridge Ave Grand Marais, MI 49839
MI Aveの壮大なマレ、イラマクドナルド高い北のInc221Ridge49839
Phone: +1 906-494-2434 EMail: imcdonald@sharplabs.com
以下に電話をしてください。 +1 906-494-2434 メールしてください: imcdonald@sharplabs.com
Usage questions and comments on this IPP URL Scheme should be sent directly to the editors at their above addresses (and to the IPP mailing list, if you are a subscriber - see below).
このIPP URL Schemeの用法質問とコメントを直接彼らの上の住所のエディタに送るべきです(加入者--あなたがそうなら、IPPメーリングリストに、以下を見てください)。
IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: ipp@pwg.org
IPPウェブページ: http://www.pwg.org/ipp/ IPPメーリングリスト: ipp@pwg.org
To subscribe to the IPP mailing list, send the following email:
IPPメーリングリストに加入するには、以下のメールを送ってください:
1) send it to majordomo@pwg.org
1) それを majordomo@pwg.org に送ってください。
2) leave the subject line blank
2) 件名を空白の状態でおいてください。
3) put the following two lines in the message body: subscribe ipp
3) 以下の2つの線をメッセージ本体に入れてください: ippを申し込んでください。
Implementers of this specification are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and comments. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the IPP mailing list.
この仕様のImplementersが明確化問題とコメントのどんな議論にも参加するためにIPP Mailing Listを接合するよう奨励されます。 メーリングリスト廃棄物が非加入者から郵送するスパムを減少させて、したがって、あなたは、IPPメーリングリストに質問やご意見を送るためにメーリングリストに加入しなければなりません。
Herriot & McDonald Standards Track [Page 15] RFC 3510 IPP URL Scheme April 2003
エリオとマクドナルドStandardsはIPP URL計画2003年4月にRFC3510を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Herriot & McDonald Standards Track [Page 16]
エリオとマクドナルド標準化過程[16ページ]
一覧
スポンサーリンク
