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
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.
本文档定义了RFC3986中定义的统一资源标识符（URI）的格式，用于指定Java（tm）消息传递服务（JMS）中使用的连接和目标地址。它最初是为特定用途而设计的，但通常适用于需要JMS URI来描述与JMS提供程序的连接以及对JMS目标的访问的任何地方。此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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以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
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”、“队列”和“主题”。强烈鼓励定义其他变体的供应商向IANA注册，如第9.2.1节所述。
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的两个实现在实践中可能互操作，也可能互操作。此外，在非Java环境中使用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.
作为基于API而非协议构建的结果，JMS URI的实用性取决于使用它的上下文。该上下文包括对同一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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
All syntax descriptions use the ABNF specified by [RFC5234], "Augmented BNF for Syntax Specifications: ABNF".
所有语法描述都使用[RFC5234]，“语法规范的扩充BNF:ABNF”指定的ABNF。
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-uri = "jms:" jms-variant ":" jms-dest
[ "?" param *( "&" param ) ]
jms-variant = segment-nz-nc
jms-variant = segment-nz-nc
jms-dest = segment-nz ; specific meaning per variant
jms dest=段nz；每个变体的具体含义
param = param-name "=" param-value
参数=参数名称“=”参数值
param-name = 1*(unreserved / pct-encoded)
param-name = 1*(unreserved / pct-encoded)
param-value = *(unreserved / pct-encoded)
param-value = *(unreserved / pct-encoded)
segment-nz-nc = <as defined in RFC 3986>
segment-nz-nc = <as defined in RFC 3986>
path-rootless = <as defined in RFC 3986>
path-rootless = <as defined in RFC 3986>
unreserved = <as defined in RFC 3986>
unreserved = <as defined in RFC 3986>
pct-encoded = <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 URI用于定位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>元素，该元素基于所选变量标识目的地。对于<jmsvariant>元素，本文档定义了三个值：“jndi”、“queue”和“topic”。由<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.expParameter”的参数。跨多个变量应用的参数（可能是因为它们通常是适用的，例如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
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消息的头和属性。对于参数deliveryMode、timeToLive和priority，可以在特定用途的上下文中指定默认值，例如通过环境变量，或者在特定网络应用程序的配置中指定。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.
指示请求消息是否持久。此属性对应于JMS 1.1规范[JMS]第3.4.2节中定义的JMS消息头字段“JMSDeliveryMode”。此参数的值必须为“PERSISTENT”或“NON_PERSISTENT”。如果未指定此参数，则必须使用上下文默认值。
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生存时间值。如果未指定此参数，则必须使用上下文默认值。
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节，该值必须是0到9（含0到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的参数。仅当URI变量为“JNDI”时，才应处理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节“标识符”）。
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提供程序URL，格式与JNDI规范[JNDI]中定义的javax.naming.spi.NamingManager.getURLContext（字符串方案，哈希表环境）一致。
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.
要使用JavaAPI基于“jndi”变量URI执行查找，应用程序可以从创建jndi InitialContext对象开始。然后可以使用InitialContext对象查找JMS ConnectionFactory对象（使用“jndiConnectionFactoryName”URI参数）、目标JMS目标对象（使用JMS URI的<JMS dest>部分）和“replyToName”JMS目标对象（如果在URI上指定了“replyToName”参数）。应用程序通过首先设置两个属性来创建InitialContext对象：“Context.INITIAL\u Context\u FACTORY”，其值为jndiInitialContextFactory JMS URI参数；和“Context.PROVIDER_URL”，以及JNDIROL URI参数的值；然后将这两个属性传递给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
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".
…将由以下（非规范性）代码示例用于从名为“c:/JMSAdmin”的文件系统JNDI上下文中查找和检索名为“CONNFACT”的JMS连接工厂以及名为“REQ_QUEUE”和“RESP_QUEUE”的JMS目的地。
/*
* 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);
/*
* 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用于创建连接，连接本身用于创建会话。然后可以使用会话创建MessageProducer，它将消息发送到目标目的地；以及MessageConsumer，它从replyToName目的地接收消息（如下面的代码摘录所示）。
/*
* 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);
/*
* 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
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（字符串名称）和Session.createTopic（字符串名称）两种方法。这些方法可用于“创建”现有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:
由于会话接口需要关于给定名称是否与队列或主题相关的外部知识，而不是引入一个新变量，因此本节定义了两个变量。JMS URI可以通过指定适当的变量“队列”或“主题”来指示要使用哪些方法。例如：
jms:queue:ExampleQueueName
jms:queue:ExampleQueueName
to identify a JMS Queue Destination, and
标识JMS队列目标，以及
jms:topic:ExampleTopicName
jms:topic: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使用的名称的方法。在JMS队列或主题可用的情况下，实现可以分别调用Queue.getQueueName（）或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不能同时指定“topicReplyToName”和“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（）方法假定客户机程序已经获得了会话对象。会话对象从何而来--客户端是如何获得它的？获取会话的一种方法就是访问特定于供应商的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查找结合起来以实现ConnectionFactory，这为JMS URI客户端提出了一个重要的考虑因素。一旦客户机将JNDI用于发现目的地的一部分，他们几乎可以肯定地对目的地对象本身使用与供应商无关的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规范清楚地将会话接口上的两个方法标识为返回特定于供应商的目的地名称。因此，“JMS”URI方案的用户应该仔细考虑何时使用这两个变体。如果用户计划在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.
参数集是可扩展的。可以在URI中提供任何其他供应商或应用程序定义的参数，方法是将其作为<param name>=<param value>传递，就像一组已知参数一样。
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.
如[RFC3986]中所定义，“jms”URI方案区分<unreserved>字符和<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.
国际资源标识符（IRI）之间的转换遵循RFC 3987第3.1节和第3.2节的规则。根据第1.2-c节。和[RFC3987]中的6.4节，在与IRI格式进行转换时，JMS URI的所有部分都必须使用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-JMS]上承载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.
此方案定义描述了获取目的地的三种变体。这些变体通过使用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.
本规范仅将变量（<jms variant>）和特定于变量的详细信息（<jms dest>）标识为URI的基本部分。出于可靠性和一致性目的，这些变体是唯一可以合理预期稳定的部件。其他可选的JMS配置和作为URI参数指示的消息属性，如“timeToLive”，可以由消息的发送方合理地确定，而不会影响接收方。只要收件人希望指定某些参数，例如“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的恶意服务使用者可能会发送一个URI，该URI包含一个参数（如“timeToLive”），该参数在URI中指定的值与相应的JMS消息属性不同（在本例中为“JMSexPrivation”头字段）。对于具有此类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.
强烈建议消息发送者从URI中删除额外的参数，如上述环境中的数据将与JMS消息中其他地方指定的信息冗余。
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.
第三方可以拦截并替换包含任何JMS/JNDI配置参数的URI，如“jndiConnectionFactoryName”、“jndiInitialContextFactory”或“JNDIRIL”。由于这些参数会影响实现如何建立初始连接，因此这些参数可以用作破坏通信的手段。这可能导致将通信重新路由到第三方，第三方随后可以监视发送的消息。除非确保这些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,
对“jndi”变体可能的语义攻击可以通过将一种语言的JMS URI字符替换为另一种语言的等效字符来实现，称为“国际化域名（IDN）同形词攻击”[同形词]。这种攻击可能以多种方式发生。例如
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目标名称，恶意参与者可能会注册并公布现有目标名称的替代名称。这样的环境应该防止使用同形异义词等价物，可能是通过限制允许的字符，这样客户端就不会意外地将其请求发送到意外的目的地。
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”变体受到相同的关注。此外，由于目标名称由供应商定义，因此使用这两种变体的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.
本规范未定义或预期IP地址作为URI的一部分的任何用途，因此本规范未提出有关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 互操作性注意事项：参见第7节
o Security considerations: See Section 8
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供应商标签生产，供应商。<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变体”产品。因为变体出现在URI中，所以它们应该很短，长度不能超过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变体”产品。因为变体出现在URI中，所以它们应该很短，长度不能超过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.
更改控制器：控制此变量定义的进一步更改的人员的联系信息。
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.
一旦IANA发布了JMS URI变体注册，变更控制器就可以请求对其定义进行变更。变更请求遵循与注册请求相同的程序。
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
菲尔·亚当斯国际商用机器公司电子邮件：菲尔_adams@us.ibm.com
Glen Daniels WSO2 EMail: glen@wso2.com
Glen Daniels WSO2电子邮件：glen@wso2.com
Peter Easton Progress Software EMail: peaston@progress.com
Peter Easton Progress软件电子邮件：peaston@progress.com
Tim Frank Software AG. EMail: tim.frank@softwareag.com
蒂姆·弗兰克软件公司。电子邮件：蒂姆。frank@softwareag.com
Lei Jin BEA Systems, Inc. until March 2007
雷进东亚系统有限公司，截止2007年3月
Eric Johnson TIBCO Software Inc. EMail: eric@tibco.com
Eric Johnson TIBCO软件公司电子邮件：eric@tibco.com
Vinod Kumar BEA Systems, Inc. until May 2007
Vinod Kumar BEA系统公司，截至2007年5月
Amelia A. Lewis TIBCO Software Inc. EMail: alewis@tibco.com
Amelia A.Lewis TIBCO软件公司电子邮件：alewis@tibco.com
Roland Merrick International Business Machines Corporation until June 2009
罗兰·梅里克国际商用机器公司，至2009年6月
Mark Phillips International Business Machines Corporation EMail: m8philli@uk.ibm.com
马克·菲利普斯国际商用机器公司电子邮件：m8philli@uk.ibm.com
Derek Rokicki Software AG. EMail: derek.rokicki@softwareag.com
德里克·罗基奇软件公司。电子邮件：德里克。rokicki@softwareag.com
Stephen Todd International Business Machines Corporation until April 2007
Stephen Todd国际商用机器公司，至2007年4月
Dongbo Xiao Oracle Corp. EMail: dongbo.xiao@oracle.com
东博肖甲骨文公司邮箱：东博。xiao@oracle.com
Prasad Yendluri Software AG. EMail: prasad.yendluri@softwareag.com
Prasad Yendluri软件公司。电子邮件：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.，“Java语言规范，第三版”，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命名和目录接口应用程序编程接口”，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，“统一资源标识符（URI）：通用语法”，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:ABNF”，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 60752010年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\u同形图\u攻击&oldid=416746950>。
[JAVA] Oracle Corporation, "Oracle Technology for Java Developers", 2011, <http://www.oracle.com/technetwork/java/index.html>.
[JAVA]Oracle公司，“面向JAVA开发人员的Oracle技术”，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绑定/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消息服务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
马克·菲利普斯国际商业机器公司英国汉普郡温彻斯特赫斯利公园赫斯利大厦
EMail: m8philli@uk.ibm.com
EMail: m8philli@uk.ibm.com
Phil Adams International Business Machines Corporation 11501 Burnet Rd. Austin, TX 78758 United States
菲尔·亚当斯国际商用机器公司美国德克萨斯州奥斯汀伯内特路11501号，邮编：78758
EMail: phil_adams@us.ibm.com
EMail: phil_adams@us.ibm.com
Derek Rokicki Software AG. 11700 Plaza America Drive Reston, VA 20190 United States
德里克·罗基奇软件公司。美国弗吉尼亚州雷斯顿美国大道11700号广场，邮编：20190
EMail: derek.rokicki@softwareag.com
EMail: derek.rokicki@softwareag.com
Eric Johnson TIBCO Software Inc. 3303 Hillview Avenue Palo Alto, CA 94304 United States
Eric Johnson TIBCO软件公司，美国加利福尼亚州帕洛阿尔托市Hillview大道3303号，邮编94304
EMail: eric@tibco.com
EMail: eric@tibco.com