[要約] RFC 6167は、Java Message Service 1.0のためのURIスキームを定義しています。このRFCの目的は、JMSメッセージブローカーへの接続を簡単にするための標準化を提供することです。
Internet Engineering Task Force (IETF) M. Phillips
Request for Comments: 6167 P. Adams
Category: Informational IBM
ISSN: 2070-1721 D. Rokicki
Software AG
E. Johnson
TIBCO
April 2011
URI Scheme for Java(tm) Message Service 1.0
Java（TM）メッセージサービス1.0のURIスキーム
Abstract
概要
This document defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS). It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMS URI is not compatible with previously existing, but unregistered, "jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances.
このドキュメントでは、Java（TM）メッセージングサービス（JMS）で使用される接続と宛先アドレスを指定するために、RFC 3986で定義されているユニフォームリソース識別子（URI）の形式を定義します。もともとは特定の用途向けに設計されていましたが、JMSプロバイダーへの接続とJMS宛先へのアクセスを説明するためにJMS URIが必要な場合は一般に適用されます。このJMS URIの構文は、以前に存在するが、登録されていない「JMS」URIスキームと互換性がありません。ただし、本明細書に記載されているスキームの表現性は、既存のすべての状況の要件を満たす必要があります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6167.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6167で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
2. URI Scheme Name .................................................5
3. Syntax of a JMS URI .............................................5
4. URI Scheme Semantics ............................................5
4.1. Shared Parameters ..........................................6
4.2. "jndi" Variant .............................................7
4.3. Vendor Destination Names -- Variants "queue" and "topic" ..11
4.4. Custom Parameters .........................................12
5. Encoding Considerations ........................................13
6. Applications/Protocols That Use the JMS URI ....................13
7. Interoperability Considerations ................................13
8. Security Considerations ........................................14
8.1. Reliability and Consistency ...............................14
8.2. Malicious Construction ....................................14
8.3. Back-End Transcoding ......................................15
8.4. Semantic Attacks ..........................................15
8.5. Other Security Concerns ...................................16
9. IANA Considerations ............................................16
9.1. URI Scheme Registration ...................................16
9.2. "jms" URI Scheme Registries ...............................17
10. Contributors ..................................................18
11. Acknowledgements ..............................................19
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
The "jms" URI scheme is used to designate a javax.jms.Destination object and an associated javax.jms.ConnectionFactory object [JMS], and, optionally, to provide additional information concerning the way that the Destination object is to be used. Probably the most common, and certainly the most compatible, way in Java to retrieve such Destinations is via Java Naming and Directory Information (JNDI) [JNDI] methods. So as to extend compatibility to existing vendor mechanisms beyond JNDI lookup, the JMS URI syntax allows variants on the core syntax. The variant exists as an explicit part of the syntax so that tools that are otherwise unfamiliar with the variant can recognize the presence of a URI with an alternate interpretation.
「JMS」URIスキームは、javax.jms.destinationオブジェクトと関連するjavax.jms.ConnectionFactoryオブジェクト[JMS]を指定するために使用され、オプションでは、宛先オブジェクトの使用方法に関する追加情報を提供するために使用されます。おそらく、そのような目的地を取得するJavaで最も一般的で、そして確かに最も互換性のある方法は、Javaの命名およびディレクトリ情報（JNDI）[JNDI]メソッドを介してです。JNDIルックアップを超えて既存のベンダーメカニズムと互換性を拡張するために、JMS URI構文はコア構文のバリアントを許可します。バリアントは構文の明示的な部分として存在するため、バリアントに慣れていないツールは、別の解釈でURIの存在を認識できます。
In its simplest and most interoperable form, this URI scheme starts with "jms:jndi:" plus a JNDI name for a Destination. Since interaction with some resources might require JNDI contextual information or JMS header fields and properties to be specified as well, the "jndi" variant of the "jms" URI scheme includes support for supplying this additional JNDI information as query parameters.
最も単純で最も相互運用可能な形式では、このURIスキームは「JMS：JNDI：」から始まり、宛先のJNDI名です。一部のリソースとの相互作用には、JNDIコンテキスト情報またはJMSヘッダーフィールドとプロパティも指定する必要があるため、「JMS」URIスキームの「JNDI」バリアントには、クエリパラメーターとしてこの追加のJNDI情報を提供するためのサポートが含まれます。
While the "jndi" variant provides compatibility, vendors can define additional variants. This specification defines three variants: "jndi", "queue", and "topic". Vendors defining additional variants are strongly encouraged to register them with IANA as documented in Section 9.2.1.
「JNDI」バリアントは互換性を提供しますが、ベンダーは追加のバリアントを定義できます。この仕様では、「JNDI」、「キュー」、および「トピック」の3つのバリエーションを定義します。追加のバリアントを定義するベンダーは、セクション9.2.1に記載されているように、IANAに登録することを強くお勧めします。
While the "jms" URI scheme allows the location of network resources, it does not map to a single underlying protocol, unlike most other URI schemes that do so. Instead, it achieves interoperability through the use of a common Java-based API [JAVA] for messaging. Because of this, interoperability is dependent upon the implementation of the API and its capabilities; two implementations of JMS might or might not interoperate in practice. Furthermore, it might be impractical to use JMS URIs in non-Java environments.
「JMS」URIスキームはネットワークリソースの位置を許可しますが、他のほとんどのURIスキームとは異なり、単一の基礎となるプロトコルにマッピングされません。代わりに、メッセージングに一般的なJavaベースのAPI [Java]を使用することにより、相互運用性を実現します。このため、相互運用性はAPIの実装とその機能に依存します。JMSの2つの実装は、実際に相互運用する場合と相互運用する場合があります。さらに、非ジャバ環境でJMS URIを使用することは非現実的かもしれません。
As a consequence of building upon an API, rather than a protocol, the utility of a JMS URI depends on the context in which it is used. That context includes agreement on the same JMS provider or underlying protocol; agreement on how to look up endpoints (JNDI); and, when using serialized Java object messages, sufficiently similar Java Class environments that serialized objects can be appropriately read and written. Users of this scheme need to establish the necessary shared-context parts as just enumerated -- a context that can span the globe, or merely a small local network. With that shared context, this URI scheme enables endpoint identification in a uniform way, and the means to connect to those endpoints.
JMS URIの有用性は、プロトコルではなくAPIに基づいて構築された結果、使用されるコンテキストに依存します。そのコンテキストには、同じJMSプロバイダーまたは基礎となるプロトコルに関する合意が含まれます。エンドポイントを検索する方法に関する合意（JNDI）;また、シリアル化されたJavaオブジェクトメッセージを使用する場合、シリアル化されたオブジェクトを適切に読み書きできるほど類似したJavaクラス環境を十分に類似しています。このスキームのユーザーは、必要な共有コンテキストパーツを列挙しているだけで確立する必要があります。これは、グローブにまたがる可能性のあるコンテキスト、または単なる小さなローカルネットワークです。その共有コンテキストにより、このURIスキームは、エンドポイントの識別を均一な方法で可能にし、それらのエンドポイントに接続する手段を可能にします。
The key words "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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
All syntax descriptions use the ABNF specified by [RFC5234], "Augmented BNF for Syntax Specifications: ABNF".
すべての構文の説明は、[RFC5234]で指定されたABNFを使用し、「構文仕様：ABNFのためにBNFの増強」。
Note that some examples in this document wrap long JMS URIs for readability. The line breaks are not part of the actual URIs.
このドキュメントのいくつかの例は、読みやすさのために長いJMS URIをラップすることに注意してください。ラインブレークは実際のURIの一部ではありません。
The name of the URI scheme is "jms".
URIスキームの名前は「JMS」です。
The following ABNF describes the "jms" scheme URI syntax:
次のABNFは、「JMS」スキームURI構文について説明しています。
jms-uri = "jms:" jms-variant ":" jms-dest
[ "?" param *( "&" param ) ]
jms-variant = segment-nz-nc
jms-dest = segment-nz ; specific meaning per variant
jms-dest = segment-nz;バリアントごとの特定の意味
param = param-name "=" param-value
param = param-name "=" param-value
param-name = 1*(unreserved / pct-encoded)
param-value = *(unreserved / pct-encoded)
segment-nz-nc = <as defined in RFC 3986>
path-rootless = <as defined in RFC 3986>
unreserved = <as defined in RFC 3986>
pct-encoded = <as defined in RFC 3986>
The URIs are percent-encoded UTF-8 [RFC3629]. Please see Section 5 of this document for encoding considerations.
URIは、パーセントエンコードされたUTF-8 [RFC3629]です。このドキュメントのセクション5を参照してください。
JMS URIs are used to locate JMS [JMS] Destination resources and do not specify actions to be taken on those resources. Operations available on JMS Destinations are fully and normatively defined by the JMS specification and as such are out of scope for this URI specification.
JMS URISは、JMS [JMS]宛先リソースを見つけるために使用され、それらのリソースで実行されるアクションを指定しません。JMS宛先で利用可能な操作は、JMS仕様によって完全かつ規範的に定義されているため、このURI仕様の範囲外です。
The required portions of the syntax include the terminal of "jms" for the URI scheme name; the <jms-variant> element to indicate the variant of the scheme; and the <jms-dest> element, which identifies the Destination based on the chosen variant. For the <jms-variant> element, this document defines three values: "jndi", "queue", and "topic". All the terminals resulting from <jms-variant> and <jms-dest> production rules are case-sensitive.
構文の必要な部分には、URIスキーム名の「JMS」の端子が含まれます。スキームのバリアントを示す<jms-variant>要素。選択したバリアントに基づいて宛先を識別する<jms-dest>要素。<JMS-Variant>要素の場合、このドキュメントは「JNDI」、「Queue」、および「トピック」の3つの値を定義します。<jms-variant>および<jms-dest>の生産ルールから生じるすべての端子は、ケースに敏感です。
Parameters further refine how to locate and use the Destination. The parameter names and values are case-sensitive. They can occur in any order, and each parameter name SHOULD NOT appear more than once. In the event that a parameter appears multiple times, all but the last instance of the parameter MUST be ignored. For comparison purposes, the absence of a parameter does not mean the same thing as a URI with a parameter set to a default value, due to the potential variation in default values as determined by the context of a specific use.
パラメーターは、宛先を見つけて使用する方法をさらに絞り込みます。パラメーター名と値はケースに敏感です。それらは任意の順序で発生する可能性があり、各パラメーター名は複数回表示されてはなりません。パラメーターが複数回表示された場合、パラメーターの最後のインスタンスを除くすべてを無視する必要があります。比較のために、パラメーターがないことは、特定の使用のコンテキストによって決定されるデフォルト値の潜在的な変動のため、パラメーターをデフォルト値に設定したURIと同じものを意味するものではありません。
Each variant can have query parameters specific to that variation. All such variant-specific parameters SHOULD use the name of the variant as the prefix to the parameters. For example, a vendor-specific variant of "vnd.example.ex" might also define a parameter with a name like "vnd.example.exParameter". Parameters that apply across multiple variants -- perhaps because they are generally applicable, such as JMS settings -- MUST NOT have a name that starts with the name of any known variant. This pattern enables tools that are otherwise unfamiliar with a particular variant to distinguish those parameters that are specific to a variant from those that are more generally applicable.
各バリアントには、そのバリエーションに固有のクエリパラメーターを持つことができます。このようなバリアント固有のパラメーターはすべて、バリアントの名前をパラメーターのプレフィックスとして使用する必要があります。たとえば、「vnd.example.ex」のベンダー固有のバリアントは、「vnd.example.exparameter」などの名前のパラメーターを定義する場合があります。複数のバリアントに適用されるパラメーター - おそらく、JMS設定など、一般的に適用可能であるため、既知のバリアントの名前から始まる名前を持ってはなりません。このパターンは、特定のバリアントに不慣れなツールを可能にし、バリアントに固有のパラメーターとより一般的に適用可能なパラメーターを区別します。
Examples of the URI scheme include:
URIスキームの例は次のとおりです。
jms:jndi:SomeJndiNameForDestination? jndiInitialContextFactory= com.example.jndi.JndiFactory&priority=3
JMS：JNDI：somejndinamefordestination？jndiinitialcontextfactory = com.example.jndi.jndifactory＆priority = 3
jms:queue:ExampleQueueName?timeToLive=1000
In addition to the required particles, the "jms" URI scheme supports the following shared parameters, which are available to all variants. These parameters correspond to headers and properties on the JMS Messages to be sent. For the parameters deliveryMode, timeToLive, and priority, the default values might be specified in the context of a specific use, for example by environment variables, or in the configuration of a particular network application. JMS also defines default values for these properties. The context default is hereby defined as the default value in the context of a specific use, or the JMS default for a particular property if the context does not define a default.
必要な粒子に加えて、「JMS」URIスキームは、すべてのバリアントが利用できる次の共有パラメーターをサポートしています。これらのパラメーターは、送信されるJMSメッセージのヘッダーとプロパティに対応します。パラメーター配信モード、タイムトリブ、および優先度の場合、デフォルト値は、環境変数などの特定の使用のコンテキスト、または特定のネットワークアプリケーションの構成で指定される場合があります。JMSは、これらのプロパティのデフォルト値も定義します。コンテキストのデフォルトは、特定の使用のコンテキストのデフォルト値として定義されます。コンテキストがデフォルトを定義していない場合、特定のプロパティのJMSデフォルトです。
Indicates whether the request message is persistent or not. This property corresponds to the JMS message header field "JMSDeliveryMode" defined in Section 3.4.2 of the JMS 1.1 specification [JMS]. The value of this parameter MUST be "PERSISTENT" or "NON_PERSISTENT". If this parameter is not specified, then the context default MUST be used.
The lifetime, in milliseconds, of the request message, specified as a decimal number. This property corresponds to the JMS Time-To-Live value defined in Section 4.8 of the JMS 1.1 specification. If this parameter is not specified, then the context default MUST be used.
数ミリ秒単位でのリクエストメッセージの寿命は、小数点として指定されています。このプロパティは、JMS 1.1仕様のセクション4.8で定義されているJMSからliveまでの値に対応しています。このパラメーターが指定されていない場合、コンテキストのデフォルトを使用する必要があります。
The JMS priority associated with the request message. As per Section 3.4.10 of the JMS 1.1 specification, this MUST be a value between 0 and 9 inclusive, specified as a decimal number. This corresponds to the JMS message header field "JMSPriority". If this parameter is not specified, then the context default MUST be used.
リクエストメッセージに関連付けられたJMSの優先度。JMS 1.1仕様のセクション3.4.10によると、これは10〜9の包括的値であり、小数点として指定されている必要があります。これは、JMSメッセージヘッダーフィールド「jmspriority」に対応します。このパラメーターが指定されていない場合、コンテキストのデフォルトを使用する必要があります。
This property corresponds to the JMS message header field "JMSReplyTo" defined in Section 3.4.6 of the JMS 1.1 specification. As interpreted by the particular variant, this property value specifies the JMS Destination object to which a response message ought to be sent.
このプロパティは、JMS 1.1仕様のセクション3.4.6で定義されているJMSメッセージヘッダーフィールド「JMSReplyto」に対応しています。特定のバリアントで解釈されるように、このプロパティ値は、応答メッセージが送信されるべきJMS宛先オブジェクトを指定します。
The "jndi" variant implies the use of JNDI for discovering the Destination object. When this is specified as the variant, the <jms-dest> portion of the syntax is the name for JNDI lookup purposes. Additional JNDI-specific parameters can be specified. The JNDI-specific parameters SHOULD only be processed when the URI variant is "jndi".
「JNDI」バリアントは、宛先オブジェクトを発見するためのJNDIの使用を意味します。これをバリアントとして指定する場合、構文の<JMS-Dest>部分はJNDIルックアップの目的の名前です。追加のJNDI固有のパラメーターを指定できます。JNDI固有のパラメーターは、URIバリアントが「JNDI」の場合にのみ処理する必要があります。
Specifies the JNDI name of the Java class (see Section 3.8, "Identifiers", of [JLS] for the specification of a legal Java class name) providing the connection factory.
接続工場を提供するJAVAクラスのJNDI名を指定します（法的Javaクラス名の仕様については[JLS]のセクション3.8、[JLS]を参照）。
Specifies the fully qualified Java class name of the "InitialContextFactory" implementation class to use.
使用する「initialContextFactory」実装クラスの完全に適格なJavaクラス名を指定します。
Specifies the JNDI provider URL, in a form consistent with javax.naming.spi.NamingManager.getURLContext(String scheme, Hashtable environment) as defined in the JNDI specification [JNDI].
JNDI仕様[JNDI]で定義されているように、JNDIプロバイダーURLを指定します。
It is possible that connecting to a JNDI provider requires additional parameters. These parameters can be passed in as custom parameters (see Section 4.4). To identify a custom parameter as JNDI specific, the parameter name needs to start with the prefix "jndi-".
JNDIプロバイダーに接続するには、追加のパラメーターが必要である可能性があります。これらのパラメーターは、カスタムパラメーターとして渡すことができます（セクション4.4を参照）。JNDI固有のカスタムパラメーターを識別するには、パラメーター名をプレフィックス「JNDI-」から始める必要があります。
For example, if the JNDI provider requires a parameter named "com.example.jndi.someParameter", you can supply the parameter in the URI as: jndi-com.example.jndi.someParameter=someValue
たとえば、JNDIプロバイダーが「com.example.jndi.someparameter」という名前のパラメーターを必要とする場合、URIのパラメーターをjndi-com.example.jndi.someparameter = somevalueとして提供できます。
To perform a lookup based on a "jndi" variant URI using Java APIs, an application might start by creating a JNDI InitialContext object. The InitialContext object can then be used to look up the JMS ConnectionFactory object (using the "jndiConnectionFactoryName" URI parameter), the target JMS Destination object (using the <jms-dest> portion of the JMS URI), and the "replyToName" JMS Destination object (if the "replyToName" parameter is specified on the URI). The application creates the InitialContext object by first setting up two properties: "Context.INITIAL_CONTEXT_FACTORY", with the value of the jndiInitialContextFactory JMS URI parameter; and "Context.PROVIDER_URL", with the value of the jndiURL URI parameter; and then passing the two properties to the InitialContext constructor.
Java APIを使用して「JNDI」バリアントURIに基づいてルックアップを実行するには、JNDI initialContextオブジェクトを作成することからアプリケーションが開始される場合があります。次に、initialContextオブジェクトを使用して、JMS ConnectionFactoryオブジェクト（「jndiconnectionFactoryName」URIパラメーターを使用）、ターゲットJMS宛先オブジェクト（jms uriの<jms-dest>部分を使用）、および「ReplyToname」JMSを検索することができます。宛先オブジェクト（「ReplyToname」パラメーターがURIで指定されている場合）。このアプリケーションは、JNDIInitialContextFactory JMS URIパラメーターの値で、最初に2つのプロパティを最初に2つのプロパティを設定して作成します。jndiurl uriパラメーターの値を持つ「Context.provider_url」。次に、2つのプロパティをInitialContextコンストラクターに渡します。
To locate a connection factory or Destination object, the application passes the name of the object into the InitialContext.lookup() method.
接続ファクトリまたは宛先オブジェクトを見つけるには、アプリケーションはオブジェクトの名前をinitialContext.lookup（）メソッドに渡します。
For example, the JMS URI...
たとえば、JMS URI ...
jms:jndi:REQ_QUEUE
?jndiURL=file:/C:/JMSAdmin
&jndiInitialContextFactory
=com.sun.jndi.fscontext.RefFSContextFactory
&jndiConnectionFactoryName=CONNFACT
&replyToName=RESP_QUEUE
...would be used by the following (non-normative) code sample to locate and retrieve a JMS ConnectionFactory called "CONNFACT", and JMS Destinations called "REQ_QUEUE" and "RESP_QUEUE", from a file-system JNDI context called "c:/JMSAdmin".
...「connfact」と呼ばれるJMS ConnectionFactoryと「req_queue」と「resp_queue」と呼ばれるJMS宛先を見つけて取得するために、次の（非規範的）コードサンプルで使用されます。：/jmsadmin "。
/*
* Preconditions on URI:
* - portion <jms-dest> has been parsed into variable "jms_dest"
* - parameters "jndiConnectionFactoryName",
* "jndiInitialContextFactory", "replyToName", and "jndiURL" have
* been parsed into variables of the same name.
*/
Hashtable environment = new Hashtable();
environment.put(Context.INITIAL_CONTEXT_FACTORY,
jndiInitialContextFactory);
environment.put(Context.PROVIDER_URL, jndiURL);
/*
* Create File-System Initial Context
*/
Context ctx = new InitialContext(environment);
/*
* Now get the JMS ConnectionFactory and Destination. These will
* be used later on in the application to create the JMS
* Connection and send/receive messages.
*/
ConnectionFactory jmsConnFact = (ConnectionFactory)
ctx.lookup(jndiConnectionFactoryName);
Destination requestDest = (Destination) ctx.lookup(jms_dest);
Destination replyDest = (Destination) ctx.lookup(replyToName);
The ConnectionFactory is used to create a Connection, which itself is used to create a Session. The Session can then be used to create the MessageProducer, which sends messages to the target Destination; and the MessageConsumer, which receives messages from the replyToName Destination (as shown in the following code extract).
ConnectionFactoryは、セッションを作成するために使用される接続を作成するために使用されます。セッションを使用して、メッセージプロデューサーを作成し、ターゲットの宛先にメッセージを送信します。ReplyTonameの宛先からメッセージを受信するMessageCosumer（次のコード抽出に示すように）。
/*
* Create a producer to send a message to the request Destination
* that was specified in the URI, then create the message, setting
* the replyToName Destination in the message to the one specified
* in the URI, and send it.
*/
MessageProducer producer = sess.createProducer(requestDest);
BytesMessage reqMsg = sess.createBytesMessage();
reqMsg.setJMSReplyTo(replyDest);
producer.send(reqMsg);
/*
* Create a consumer to get a message from the replyToName
* Destination using a selector to get the specific response to
* this request. The responder sets the correlation ID of the
* response to the message ID of the request message.
*/
MessageConsumer consumer = sess.createConsumer(replyDest,
"JMSCorrelationID = '" + reqMsg.getJMSMessageID() + "'");
Message respMsg = (Message) consumer.receive(300000);
Any parameters with a prefix of "jndi-" MUST be used to set custom properties when establishing a connection to the JNDI provider. The name of the custom property is derived by removing the "jndi-" prefix from the URI parameter name, and the value of the property is the value of the parameter.
「jndi-」のプレフィックスを持つパラメーターは、JNDIプロバイダーへの接続を確立するときにカスタムプロパティを設定するために使用する必要があります。カスタムプロパティの名前は、URIパラメーター名から「jndi-」プレフィックスを削除することで導出され、プロパティの値はパラメーターの値です。
For example, the JMS URI...
たとえば、JMS URI ...
jms:jndi:REQ_QUEUE
?jndiURL=file:/C:/JMSAdmin
&jndiInitialContextFactory
=com.sun.jndi.fscontext.RefFSContextFactory
&jndiConnectionFactoryName=CONNFACT
&jndi-com.example.jndi.someParameter=someValue
...instructs the consumer to use the following properties to connect to the JNDI provider:
...消費者に、次のプロパティを使用してJNDIプロバイダーに接続するように指示します。
java.naming.provider.url=file:/C:/JMSAdmin java.naming.factory.initial= com.sun.jndi.fscontext.RefFSContextFactory com.example.jndi.someParameter=someValue
java.naming.provider.url = file：/c：/jmsadmin java.naming.factory.initial = com.sun.jndi.fscontext.reffscontextfactory com.example.jndi.someparameter = somevalue
The JMS Session object provides a means to directly access Queues and Topics. Specifically, it has the methods Session.createQueue(String name) and Session.createTopic(String name). These methods can be used to "create" the Java representation of an existing JMS Topic or Queue.
JMSセッションオブジェクトは、キューとトピックに直接アクセスする手段を提供します。具体的には、メソッドsession.createqueue（string name）とsession.createTopic（string name）があります。これらの方法は、既存のJMSトピックまたはキューのJava表現を「作成」するために使用できます。
Since the Session interface requires external knowledge about whether a given name relates to a Queue or Topic, rather than introducing one new variant, this section defines two variants. A JMS URI can indicate which of these methods to use by specifying the appropriate variant -- either "queue" or "topic". For example:
セッションインターフェイスでは、特定の名前が1つの新しいバリアントを導入するのではなく、キューまたはトピックに関連するかどうかについての外部知識が必要なため、このセクションでは2つのバリアントを定義します。JMS URIは、適切なバリアント（「キュー」または「トピック」）を指定することにより、これらの使用方法のどれを使用するかを示すことができます。例えば：
jms:queue:ExampleQueueName
JMS：キュー：ExampleQueuename
to identify a JMS Queue Destination, and
JMSキューの宛先を識別するには
jms:topic:ExampleTopicName
JMS：トピック：ExampleTopicName
to identify a JMS Topic Destination.
JMSトピックの宛先を特定します。
JMS only specifies one way to obtain the names used by these APIs. With a JMS Queue or Topic available, an implementation can call Queue.getQueueName() or Topic.getTopicName(), respectively, both of which return a String object. To create a correct corresponding URI, the resulting string MUST use standard URI escape mechanisms so that the resulting characters conform to the production <jms-dest>.
JMSは、これらのAPIで使用されている名前を取得する1つの方法のみを指定します。JMSキューまたはトピックが利用可能な場合、実装はそれぞれqueue.getuename（）またはtopic.getTopicName（）を呼び出すことができます。どちらも文字列オブジェクトを返します。正しい対応するURIを作成するには、結果の文字列が標準のURIエスケープメカニズムを使用して、生成<JMS-Dest>に適合するようにする必要があります。
When used with the "queue" and "topic" variants, the replyToName parameter, specified in Section 4.1.4, always refers to a name of a JMS Queue to look up via the Session.createQueue() method, or its equivalent. For either variant, if a JMS Topic is instead required as a response Destination, a JMS URI can employ the "topicReplyToName" parameter. This parameter defines a name to look up with the Session.createTopic() method, or its equivalent.
「キュー」および「トピック」バリアントとともに使用する場合、セクション4.1.4で指定されたReplyTonameパラメーターは、常にsession.createqueue（）メソッドを介して検索するJMSキューの名前を指します。いずれかのバリアントの場合、JMSトピックが応答宛先として必要な場合、JMS URIは「TopicReplytoname」パラメーターを使用できます。このパラメーターは、session.createTopic（）メソッドまたはその等価物で検索する名前を定義します。
A JMS URI MUST NOT specify both a "topicReplyToName" and a "replyToName" parameter.
JMS URIは、「トピックReplytoname」と「ReplyToname」パラメーターの両方を指定してはなりません。
Using the Session.createQueue() and Session.createTopic() methods assumes that a client program has already obtained a Session object. Where does that Session object come from -- how does a client get it? One way to get a Session is simply to access vendor-specific APIs.
session.createqueue（）およびsession.createTopic（）メソッドを使用すると、クライアントプログラムが既にセッションオブジェクトを取得していると想定しています。そのセッションオブジェクトはどこから来たのですか？クライアントはどのようにそれを取得しますか？セッションを取得する1つの方法は、単にベンダー固有のAPIにアクセスすることです。
Another way to get a Session object is to simply revert to using JNDI. That is, if a Session is not available to the client from some other context, the "queue" and "topic" variants MAY reuse the URL parameters specified in Section 4.2.1, "JNDI Parameters". Via JNDI, those parameters will identify a ConnectionFactory, which can then be used to obtain a Session object.
セッションオブジェクトを取得する別の方法は、JNDIの使用に戻すことです。つまり、セッションが他のコンテキストからクライアントが利用できない場合、「キュー」と「トピック」バリアントは、セクション4.2.1「JNDIパラメーター」で指定されたURLパラメーターを再利用できます。JNDIを介して、これらのパラメーターはConnectionFactoryを識別し、セッションオブジェクトを取得するために使用できます。
Combining the "queue" and "topic" variants with JNDI lookup for an implementation of ConnectionFactory raises an important consideration for JMS URI clients. Once clients employ JNDI for one part of discovering a Destination, they almost certainly could use a vendor-neutral JNDI lookup for a Destination object itself, rather than using vendor-specific means. As a result, clients need to carefully consider whether it makes sense to use JNDI for one part of this problem, without using it for the other.
「キュー」と「トピック」バリエーションをJNDI検索のためのJNDIルックアップと組み合わせることで、JMS URIクライアントに重要な考慮事項が得られます。クライアントが目的地を発見する部分にJNDIを使用すると、ベンダー固有の手段を使用するのではなく、宛先オブジェクト自体にベンダーに中立なJNDIルックアップを使用することができます。その結果、クライアントは、他の問題に使用せずに、この問題の一部にJNDIを使用することが理にかなっているかどうかを慎重に検討する必要があります。
The JMS specification clearly identifies the two methods on the Session interface as returning vendor-specific names for Destinations. Consequently, users of the "jms" URI scheme ought to carefully consider when these two variants might be employed. If users plan on switching between JMS vendors, they might also need to plan on regenerating resources that contain URIs in this vendor-specific form.
JMS仕様は、セッションインターフェイス上の2つのメソッドを、目的地のベンダー固有の名前を返すものとして明確に識別します。その結果、「JMS」URIスキームのユーザーは、これら2つのバリアントがいつ使用されるかを慎重に検討する必要があります。ユーザーがJMSベンダー間の切り替えを計画している場合、このベンダー固有のフォームにURIを含むリソースの再生を計画する必要がある場合もあります。
A JMS vendor can provide alternate ways to obtain the names that can be passed to Session.createQueue() and Session.createTopic(). When using names derived from those alternate means, users of this URI specification are encouraged to verify that the obtained names work as expected in all circumstances.
JMSベンダーは、session.createqueue（）およびsession.createTopic（）に渡すことができる名前を取得する代替方法を提供できます。これらの代替手段から派生した名前を使用する場合、このURI仕様のユーザーは、取得した名前があらゆる状況で予想されるように機能することを確認するように推奨されます。
The set of parameters is extensible. Any other vendor- or application-defined parameter can be supplied, in the URI, by passing it as <param-name>=<param-value>, just like the set of well-known parameters.
パラメーターのセットは拡張可能です。他のベンダーまたはアプリケーション定義のパラメーターは、よく知られているパラメーターのセットと同様に、<param-name> = <param-value>として渡すことにより、URIで提供できます。
WARNING: Vendors and applications MUST NOT include sensitive information (such as authorization tokens) in a URI. Other means of authorization, authentication, and identification ought to be used. Also see the security discussion below about properties that might be duplicated as JMS message properties.
警告：ベンダーとアプリケーションは、URIに機密情報（認証トークンなど）を含めてはなりません。許可、認証、および識別の他の手段を使用する必要があります。また、JMSメッセージプロパティとして複製される可能性のあるプロパティに関する以下のセキュリティディスカッションも参照してください。
The "jms" URI scheme distinguishes between <unreserved> characters and <pct-encoded> characters, as defined in [RFC3986]. Apart from these encoding considerations, the characters "?" and "&" MUST be encoded when they appear within the <jms-dest> particle (for example, a JNDI name) or in query parameters. The character ":" SHOULD be escaped when appearing in the <jms-dest> portion of the syntax.
[jms "URIスキームは、[RFC3986]で定義されているように、<unsherved>文字と<pct-encoded>文字を区別します。これらのエンコードの考慮事項とは別に、文字「？」および「＆」は、<jms-dest>粒子（たとえば、JNDI名）内またはクエリパラメーター内に表示されるときにエンコードする必要があります。文字 "："は、構文の<jms-dest>部分に表示されるときに逃げる必要があります。
Conversions to and from Internationalized Resource Identifiers (IRIs) follow the rules of RFC 3987, Sections 3.1 and 3.2. As per Sections 1.2-c. and 6.4 of [RFC3987], all parts of the JMS URI MUST use the UTF-8 encoding when converting to and from the IRI format.
国際化されたリソース識別子（IRIS）との間の変換は、RFC 3987、セクション3.1および3.2の規則に従います。セクション1.2-Cに従って。[RFC3987]の6.4、JMS URIのすべての部分は、IRI形式との間で変換するときにUTF-8エンコードを使用する必要があります。
A variety of vendors provide implementations of the JMS Service Provider Interface (SPI). These products interoperate at the API level, in the Java programming language.
さまざまなベンダーがJMSサービスプロバイダーインターフェイス（SPI）の実装を提供します。これらの製品は、Javaプログラミング言語でAPIレベルで相互運用します。
Some vendors have provided additional products that interoperate with their own SPI implementations. These extensions might also be able to make use of this URI scheme.
一部のベンダーは、独自のSPI実装と相互操作する追加の製品を提供しています。これらの拡張機能は、このURIスキームを利用できる場合もあります。
The vendors working on this URI scheme are also working on a specification for carrying SOAP messages over their respective implementations of JMS [SOAP-JMS]. In addition, the Service Component Architecture Bindings technical committee (TC) [SCA-TC] at OASIS employs the "jms" URI scheme to identify JMS Destinations in [SCA-JMS].
このURIスキームに取り組んでいるベンダーは、JMS [SOAP-JM]のそれぞれの実装においてSOAPメッセージを携帯するための仕様にも取り組んでいます。さらに、OASISのサービスコンポーネントアーキテクチャバインディングステクニカル委員会（TC）[SCA-TC]は、[JMS] URIスキームを採用して[SCA-JMS]のJMS宛先を特定します。
This "jms" URI scheme focuses on identifying a JMS Destination object, and some characteristics of communication using that Destination, and specifically excludes any notion of describing how JMS itself is implemented and how it delivers messages. As a consequence of this focus, interoperability concerns are limited to how implementations obtain and use a Destination object.
この「JMS」URIスキームは、JMS宛先オブジェクトの識別と、その目的地を使用した通信のいくつかの特性に焦点を当てており、JMS自体がどのように実装され、どのようにメッセージを配信するかを説明するという概念を具体的に除外します。この焦点の結果として、相互運用性の懸念は、実装が宛先オブジェクトを取得および使用する方法に限定されます。
This scheme definition describes three variants for obtaining a Destination. These variants achieve their aims with the use of JNDI and JMS APIs, with no new APIs or protocols defined here. As a consequence of using JNDI and JMS, interoperability concerns might arise if implementations do not conform to the specifications for those APIs. Further, the use of Java, and JNDI in particular, means that the configuration of the execution environment and the use of Java ClassLoaders can affect the interpretation of any given URI.
このスキーム定義では、宛先を取得するための3つのバリアントが記述されています。これらのバリアントは、JNDIおよびJMS APIを使用して目的を達成し、ここでは新しいAPIやプロトコルは定義されていません。JNDIおよびJMSを使用した結果、実装がそれらのAPIの仕様に準拠していない場合、相互運用性の懸念が生じる可能性があります。さらに、特にJavaおよびJNDIの使用は、実行環境の構成とJavaクラスローダーの使用が、特定のURIの解釈に影響を与える可能性があることを意味します。
Consumers of these URIs are urged to consider the scope and consistency of the environment across which these URIs will be shared.
これらのURIの消費者は、これらのURIが共有される環境の範囲と一貫性を考慮するように促されています。
As described in Section 4, others can define additional variants, which provide the means to describe how to look up JMS Destination objects in a manner specific to some environment. For any new variant, the shared parameters defined in Section 4.1 MUST have the same meaning in that variant as they do here. That way, tools and people can safely copy these parameters between environments. Note that while additional variants might seem more flexible, employing variants not defined here might make it more difficult to switch to an alternate JMS provider.
セクション4で説明されているように、他のものは追加のバリアントを定義できます。これは、一部の環境に固有の方法でJMS宛先オブジェクトを検索する方法を説明する手段を提供します。新しいバリアントの場合、セクション4.1で定義されている共有パラメーターは、ここで行うのと同じ意味を持つ必要があります。そうすれば、ツールと人々は環境間でこれらのパラメーターを安全にコピーできます。追加のバリアントはより柔軟に見えるかもしれませんが、ここで定義されていないバリアントを使用すると、代替JMSプロバイダーに切り替えることがより困難になる可能性があることに注意してください。
Section 7 of [RFC3986] identifies some of the security concerns that ought to be addressed by this specification.
[RFC3986]のセクション7では、この仕様で対処すべきセキュリティ上の懸念の一部を特定しています。
This specification identifies only the variant (<jms-variant>) and variant-specific details (<jms-dest>) as an essential part of the URI. For reliability and consistency purposes, these variants are the only part that can reasonably be expected to be stable. Other optional JMS configuration and message properties indicated as URI parameters, like "timeToLive", can reasonably be determined by the sender of a message, without affecting the recipient. Insofar as a recipient might wish to dictate certain parameters, such as the "jndiConnectionFactoryName", those parameters can be specified.
この仕様は、Variant（<JMS-Variant>）とバリアント固有の詳細（<JMS-Dest>）のみをURIの重要な部分として識別します。信頼性と一貫性の目的のために、これらのバリアントは、安定していると合理的に期待できる唯一の部分です。「Timetolive」のようなURIパラメーターとして示される他のオプションのJMS構成とメッセージプロパティは、受信者に影響を与えることなく、メッセージの送信者によって合理的に決定できます。受信者が「jndiconnectionFactoryName」などの特定のパラメーターを指示したい場合は、これらのパラメーターを指定できます。
A malicious consumer of a service using a JMS URI could send, as part of a JMS message, a URI with a parameter such as "timeToLive" with a value specified in the URI that differs from the corresponding JMS message property ("JMSExpiration" header field, in this example). In the case of such messages with such URIs, recipients are strongly cautioned to avoid applying processing logic based on particular URI parameters. Discrepancies in the message could be used to exploit differences in behavior between the selectors that a JMS-based application might use to affect which messages it sees, and the processing of the rest of the application. As defined in this document, the parameters of concern include:
JMS URIを使用したサービスの悪意のある消費者は、JMSメッセージの一部として、対応するJMSメッセージプロパティ（「jmsexpiration」ヘッダーとは異なるURIで指定された値を持つパラメーターを持つURIを送信できます。この例ではフィールド）。そのようなURIを使用したこのようなメッセージの場合、受信者は特定のURIパラメーターに基づいて処理ロジックの適用を避けるために強く警告されています。メッセージの不一致を使用して、JMSベースのアプリケーションが見ているメッセージに影響を与えるために使用できるセレクター間の動作の違いを活用して、アプリケーションの残りの部分の処理に使用できます。このドキュメントで定義されているように、懸念のパラメーターには次のものが含まれます。
deliveryMode
配信モード
timeToLive
有効期間
priority
優先順位
Message senders are strongly urged to remove from the URI extra parameters like the above in environments where the data will be redundant with information specified elsewhere in the JMS message.
メッセージ送信者は、JMSメッセージの他の場所で指定された情報でデータが冗長になる環境で、上記のようなURI追加パラメーターから削除することを強く求められます。
Any use of additional parameters, either as a part of a definition of a new variant or for more general use, SHOULD also specify whether those parameters ought to be removed by a sender as specified here. If a recipient is aware of the "jms" URI scheme, and it receives a message containing a JMS URI, it MUST ignore or discard parameters that it does not recognize.
新しいバリアントの定義の一部として、またはより一般的な使用のために、追加のパラメーターを使用すると、ここで指定されているように送信者がそれらのパラメーターを削除する必要があるかどうかも指定する必要があります。受信者が「JMS」URIスキームを認識し、JMS URIを含むメッセージを受信した場合、認識されないパラメーターを無視または破棄する必要があります。
A third party could intercept and replace a URI containing any of the JMS/JNDI configuration parameters, such as "jndiConnectionFactoryName", "jndiInitialContextFactory", or "jndiURL". As these parameters can affect how an implementation establishes an initial connection, such parameters could be used as a means to subvert communications. This could possibly result in re-routing communications to third parties, who could then monitor sent messages. Clients SHOULD NOT use these URI parameters unless assured of their validity in trusted environments.
サードパーティは、「jndiconnectionfactoryname」、「jndiinitialcontextfactory」、または「jndiurl」など、JMS/JNDI構成パラメーターを含むURIを傍受して交換できます。これらのパラメーターは、実装が初期接続を確立する方法に影響を与える可能性があるため、そのようなパラメーターは通信を覆す手段として使用できます。これにより、サードパーティへの通信の再ルーティングが発生する可能性があり、サードパーティは送信されたメッセージを監視できます。クライアントは、信頼できる環境での有効性を保証しない限り、これらのURIパラメーターを使用しないでください。
This specification, in using the URI specification and building around the JMS specification, has no particular transcoding issues. Any such issues are problems with the underlying implementation of Java and the Java Messaging Service being employed.
この仕様は、URI仕様を使用してJMS仕様の周りに構築する際に、特定のトランスコーディングの問題はありません。そのような問題は、Javaの基礎となる実装と雇用されているJavaメッセージングサービスの問題です。
A possible semantic attack on the "jndi" variant could be accomplished by replacing characters of the JMS URI from one language with equivalent-looking characters from another language, known as an "Internationalized Domain Name (IDN) homograph attack" [HOMOGRAPH]. This kind of attack could occur in a variety of ways. For example, if an environment allows for the automatic registration of JNDI Destination names, a malicious actor could register and then publicize an alternate of an existing Destination name. Such an environment ought to prevent the use of homograph equivalents, perhaps by restricting allowed characters, so that clients do not accidentally send their requests to unintended Destinations.
「JNDI」バリアントに対するセマンティック攻撃の可能性は、「国際化ドメイン名（IDN）ホモグラフ攻撃」[ホモグラフ]として知られる別の言語の同等の文字に、ある言語のJMS URIの文字を置き換えることで達成できます。この種の攻撃は、さまざまな方法で発生する可能性があります。たとえば、環境がJNDIの宛先名の自動登録を許可している場合、悪意のあるアクターが登録してから既存の宛先名の代替を公開することができます。このような環境は、おそらく許可された文字を制限することにより、ホモグラフの同等物の使用を防ぐ必要があります。そうすれば、クライアントは誤って意図しない目的地にリクエストを送信しません。
The "queue" and "topic" variants are subject to the same concerns as the "jndi" variant. In addition, because the Destination names are vendor defined, URIs employing these two variants might employ special characters that significantly change the meaning of the URI. It is possible that the introduction of a single character -- difficult for a human to notice -- might dramatically change the intended meaning of a URI. In situations where this might be an issue, users of this URI are urged to strongly consider the "jndi" variant instead.
「キュー」および「トピック」バリアントは、「JNDI」バリアントと同じ懸念事項の対象となります。さらに、宛先名はベンダーで定義されているため、これらの2つのバリアントを採用するURIは、URIの意味を大幅に変える特殊文字を採用する可能性があります。単一のキャラクターの導入は、人間が気付くのが難しい - は、URIの意図された意味を劇的に変える可能性があります。これが問題になる可能性のある状況では、このURIのユーザーは、代わりに「JNDI」バリアントを強く検討するように促されます。
This specification does not define or anticipate any use for IP addresses as part of the URI, so no issues around IP addresses, rare or otherwise, are raised by this specification.
この仕様では、URIの一部としてIPアドレスの使用を定義または予測するものではないため、この仕様によってIPアドレスの問題はまれであるかどうかは問題ありません。
This specification does not define any characteristics of a "jms" scheme URI that contain sensitive information.
この仕様は、機密情報を含む「JMS」スキームURIの特性を定義しません。
IANA registered the Java Message Service URI scheme described in this document, according to the following scheme registration request, using the template from [RFC4395]:
IANAは、[RFC4395]のテンプレートを使用して、次のスキーム登録要求に従って、このドキュメントに記載されているJavaメッセージサービスURIスキームを登録しました。
o URI scheme name: jms
o URIスキーム名：JMS
o Status: Provisional
o ステータス：暫定
o URI scheme syntax: See Section 3
o URIスキーム構文：セクション3を参照してください
o URI scheme semantics: See Section 4
o URIスキームセマンティクス：セクション4を参照してください
o Encoding considerations: See Section 5
o 考慮事項のエンコード：セクション5を参照してください
o Applications/protocols that use this URI scheme name: See Section 6
o このURIスキームを使用するアプリケーション/プロトコル名：セクション6を参照してください
o Interoperability considerations: See Section 7 o Security considerations: See Section 8
o 相互運用性の考慮事項：セクション7を参照oセキュリティに関する考慮事項：セクション8を参照してください
o Contact: See the Authors' Addresses section
o 連絡先：著者のアドレスセクションを参照してください
o References: See the References section
o 参照：参照セクションを参照してください
Per this URI scheme, IANA has created a registry for possible "variants". IANA can reject obviously bogus registrations.
このURIスキームに従って、IANAは「バリアント」の可能性のあるレジストリを作成しました。IANAは明らかに偽の登録を拒否できます。
This registry provides a listing of "jms" URI scheme variants. Variant names beginning with "vnd." are reserved for vendor extensions. Such variants should follow a pattern of vnd.<vendorname>.<label>. The <vendorname> corresponds to the iana-vendor-tag production from [RFC6075], and vendor.<vendorname> must already be registered in the Application Configuration Access Protocol (ACAP) Vendor Subtree. The <label> is chosen by said vendor.
このレジストリは、「JMS」URIスキームバリアントのリストを提供します。「VND」から始まるバリアント名。ベンダーエクステンション用に予約されています。このようなバリアントは、vndのパターンに従う必要があります。<vendorname>。<label>。<vendorname>は、[RFC6075]のIANA-Vendor-TAGプロダクションに対応し、ベンダー。<Vendorname>は、アプリケーション構成アクセスプロトコル（ACAP）ベンダーサブツリーに既に登録する必要があります。<label>は、上記のベンダーによって選択されます。
All variant names are to be registered on a first come, first served basis.
すべてのバリアント名は、先着順で登録されます。
Variants must conform to the "jms-variant" production above. Since variants occur in URIs, they ought to be short, and MUST NOT be more than forty characters in length.
バリアントは、上記の「JMS変数」生産に準拠する必要があります。バリアントはURISで発生するため、短くするべきであり、長さが40文字以上であってはなりません。
This document defines the "jndi", "queue", and "topic" variants initially included in the registry.
このドキュメントでは、「JNDI」、「キュー」、および「トピック」バリアントを最初にレジストリに定義します。
This template describes the fields that must be present to register a new variant for use in a JMS URI.
このテンプレートは、JMS URIで使用するための新しいバリアントを登録するために存在する必要があるフィールドを説明しています。
To: iana@iana.org Subject: Registration of JMS URI variant name
宛先：iana@iana.org件名：jms uriバリアント名の登録
JMS URI variant name: Variants must conform to the "jms-variant" production above. Since variants occur in URIs, they ought to be short, and MUST NOT be more than forty characters in length.
JMS URIバリアント名：バリアントは、上記の「JMS-Variant」生産に準拠する必要があります。バリアントはURISで発生するため、短くするべきであり、長さが40文字以上であってはなりません。
Description: A description of the purpose of the variant being registered.
説明：登録されているバリアントの目的の説明。
Contact Information: Name(s) and email address(es) to contact for more information about this registration.
連絡先情報：この登録の詳細については、お問い合わせください。
Description URL: If available, a URL for a document describing the details of how the variant works.
説明URL：利用可能な場合、バリアントの仕組みの詳細を説明するドキュメントのURL。
Comments: Any comments the requester thinks are relevant to this request.
コメント：リクエスターがこのリクエストに関連していると考えるコメント。
Change Controller: Contact information for the person who controls further changes to this variant definition.
Change Controller：このバリアント定義をさらに変更する人の連絡先情報。
Once a JMS URI variant registration has been published by IANA, the change controller can request a change to its definition. The change request follows the same procedure as the registration request.
JMS URIバリアント登録がIANAによって公開されると、変更コントローラーはその定義の変更を要求できます。変更要求は、登録要求と同じ手順に従います。
The change controller of a JMS URI variant can pass responsibility for the JMS URI variant to another person or agency by informing IANA; this can be done without discussion or review.
JMS URIバリアントの変更コントローラーは、IANAに通知することにより、JMS URIバリアントの責任を他の人または代理店に渡すことができます。これは、議論やレビューなしで行うことができます。
JMS URI variant registrations MUST NOT be deleted; mechanisms that are no longer believed appropriate for use can be marked as obsolete in the Comment field.
JMS URIバリアント登録を削除してはなりません。使用に適していないメカニズムは、コメントフィールドで時代遅れとしてマークされる可能性があります。
In exceptional circumstances, the IESG can reassign responsibility for a JMS URI variant.
例外的な状況では、IESGはJMS URIバリアントの責任を再割り当てできます。
The IESG is considered to be the owner of all JMS URI variants that are on the IETF Standards Track.
IESGは、IETF標準トラックにあるすべてのJMS URIバリアントの所有者であると考えられています。
The authors gratefully acknowledge the contributions of:
著者は、次の貢献に感謝しています。
Phil Adams International Business Machines Corporation EMail: phil_adams@us.ibm.com
Phil Adams International Business Machines Corporation Email：phil_adams@us.ibm.com
Glen Daniels WSO2 EMail: glen@wso2.com
グレンダニエルズWSO2メール：glen@wso2.com
Peter Easton Progress Software EMail: peaston@progress.com Tim Frank Software AG. EMail: tim.frank@softwareag.com
Peter Easton Progress Software Email：peaston@progress.comティムフランクソフトウェアAG。メール：tim.frank@softwareag.com
Lei Jin BEA Systems, Inc. until March 2007
Lei Jin Bea Systems、Inc。2007年3月まで
Eric Johnson TIBCO Software Inc. EMail: eric@tibco.com
Eric Johnson Tibco Software Inc.メール：eric@tibco.com
Vinod Kumar BEA Systems, Inc. until May 2007
Vinod Kumar Bea Systems、Inc。2007年5月まで
Amelia A. Lewis TIBCO Software Inc. EMail: alewis@tibco.com
Amelia A. Lewis Tibco Software Inc.メール：Alewis@tibco.com
Roland Merrick International Business Machines Corporation until June 2009
Roland Merrick International Business Machines Corporation 2009年6月まで
Mark Phillips International Business Machines Corporation EMail: m8philli@uk.ibm.com
Mark Phillips International Business Machines Corporation Email：m8philli@uk.ibm.com
Derek Rokicki Software AG. EMail: derek.rokicki@softwareag.com
Derek RokickiソフトウェアAG。メール：derek.rokicki@softwareag.com
Stephen Todd International Business Machines Corporation until April 2007
Stephen Todd International Business Machines Corporation 2007年4月まで
Dongbo Xiao Oracle Corp. EMail: dongbo.xiao@oracle.com
Dongbo Xiao Oracle Corp.メール：dongbo.xiao@oracle.com
Prasad Yendluri Software AG. EMail: prasad.yendluri@softwareag.com
Prasad YendluriソフトウェアAG。メール：prasad.yendluri@softwareag.com
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
OracleとJavaは、Oracleおよび/またはその関連会社の登録商標です。他の名前は、それぞれの所有者の商標である場合があります。
[JLS] Sun Microsystems, Inc., "The Java Language Specification, Third Edition", January 2005, <http://java.sun.com/docs/books/jls/third_edition/html/ j3TOC.html>.
[JLS] Sun Microsystems、Inc。、「The Java Language Specification、Third Edition」、2005年1月、<http://java.sun.com/docs/books/jls/third_edition/html/ j3toc.html>。
[JMS] Hapner, M., Burridge, R., Sharma, R., Fialli, J., and K. Stout, "Java Message Service", April 2002, <http://java.sun.com/products/jms/>.
[JMS] Hapner、M.、Burridge、R.、Sharma、R.、Fialli、J。、およびK. Stout、「Javaメッセージサービス」、2002年4月、<http://java.sun.com/products/jms/>。
[JNDI] Sun Microsystems, Inc., "Java Naming and Directory Interface Application Programming Interface", July 1999, <http://java.sun.com/products/jndi/docs.html>.
[JNDI] Sun Microsystems、Inc。、「Java Naming and Directory Interface Application Programming Interface」、1999年7月、<http://java.sun.com/products/jndi/docs.html>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395] Hansen、T.、Hardie、T.、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC6075] Cridland, D., "The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry", RFC 6075, December 2010.
[RFC6075] Cridland、D。、「インターネットが割り当てられた番号局（IANA）アプリケーション構成アクセスプロトコル（ACAP）ベンダーサブツリーレジストリ」、RFC 6075、2010年12月。
[HOMOGRAPH] "IDN Homograph attack", 2011, <http://en.wikipedia.org/ w/index.php?title=IDN_homograph_attack&oldid=416746950>.
[ホモグラフ]「IDNホモグラフ攻撃」、2011年、<http://en.wikipedia.org/ w/index.php？title = idn_homograph_attack＆oldid = 416746950>。
[JAVA] Oracle Corporation, "Oracle Technology for Java Developers", 2011, <http://www.oracle.com/technetwork/java/index.html>.
[Java] Oracle Corporation、「Java開発者向けOracle Technology」、2011、<http://www.oracle.com/technetwork/java/index.html>。
[SCA-JMS] Holdsworth, S. and A. Karmarkar, "Service Component Architecture JMS Binding Specification Version 1.1", November 2010, <http://docs.oasis-open.org/opencsa/ sca-bindings/sca-jmsbinding-1.1-spec.html>.
[SCA-JMS] Holdsworth、S。およびA. Karmarkar、「サービスコンポーネントアーキテクチャJMSバインディング仕様バージョン1.1」、2010年11月<http://docs.oasis-open.org/opencsa/ sca-bindings/sca-jmsbinding-1.1-spec.html>。
[SCA-TC] "OASIS Service Component Architecture / Bindings (SCA-Bindings) TC", <http://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=sca-bindings>.
[SCA-TC] "OASISサービスコンポーネントアーキテクチャ/バインディング（SCAバインディング）TC"、<http://www.oasis-open.org/committees/ tc_home.php？wg_abbrev = sca-bindings>。
[SOAP-JMS] Adams, P., Easton, P., Johnson, E., Merrick, R., and M. Phillips, "SOAP over Java Message Service 1.0", October 2010, <http://www.w3.org/TR/2010/WD-soapjms-20101026/>.
[SOAP-JMS] Adams、P.、Easton、P.、Johnson、E.、Merrick、R。、およびM. Phillips、「Soap over Java Message Service 1.0」、2010年10月、<http：//www.w3.org/tr/2010/wd-soapjms-20101026/>。
Authors' Addresses
著者のアドレス
Mark Phillips International Business Machines Corporation Hursley House, Hursley Park Winchester, Hampshire SO21 2JN United Kingdom
マークフィリップスインターナショナルビジネスマシンコーポレーションハーズリーハウス、ハーズリーパークウィンチェスター、ハンプシャーSO21 2JNイギリス
EMail: m8philli@uk.ibm.com
Phil Adams International Business Machines Corporation 11501 Burnet Rd. Austin, TX 78758 United States
Phil Adams International Business Machines Corporation 11501 Burnet Rd。テキサス州オースティン78758アメリカ合衆国
EMail: phil_adams@us.ibm.com
Derek Rokicki Software AG. 11700 Plaza America Drive Reston, VA 20190 United States
Derek RokickiソフトウェアAG。11700プラザアメリカドライブレストン、バージニア州20190米国
EMail: derek.rokicki@softwareag.com
Eric Johnson TIBCO Software Inc. 3303 Hillview Avenue Palo Alto, CA 94304 United States
Eric Johnson Tibco Software Inc. 3303 Hillview Avenue Palo Alto、CA 94304米国
EMail: eric@tibco.com