RFC 6167

URI Scheme for Java(tm) Message Service 1.0

📅 published April 2011, from ietf

RFC 6167: URI Scheme for Java(tm) Message Service 1.0 🎀

Okay bestie, let's start with the title block 💖

  • Who wrote it: M. Phillips (IBM), P. Adams (IBM), D. Rokicki (Software AG), and E. Johnson (TIBCO) 🧚
  • Category: Informational. It is not a Standards Track spec, just published for info 📚
  • Date: April 2011 🌸
  • Stream and ISSN: IETF, ISSN 2070-1721 ✨
  • Obsoletes or updates: The title block doesn't list any, so nothing is replaced or updated here 💅

Abstract

Okay so this doc defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, and they're used to point at connections and destination addresses in the Java(tm) Messaging Service (JMS) 🦋 It was first made for specific use cases, but it's giving "works everywhere" energy. Any time you need a JMS URI to describe a connection to a JMS provider and reach a JMS Destination, this is your spot 🎀

Heads up: the syntax here is not compatible with older "jms" URI schemes that existed but were never registered 🙈 Still, the expressiveness of this scheme should cover everything people were doing before 💖

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes only 📚

It is a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

For the current status, any errata, and how to send feedback, head over to http://www.rfc-editor.org/info/rfc6167 🌈

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅

Some material in this document may come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside it either. The exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌸

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 ✨

Okay so the "jms" URI scheme is how you point at a javax.jms.Destination object and an associated javax.jms.ConnectionFactory object [JMS]. You can also, optionally, add extra info about how that Destination is supposed to be used 💖 In Java, the most common and definitely the most compatible way to grab these Destinations is through Java Naming and Directory Information (JNDI) [JNDI] lookups 🌸

BUT, not every vendor sticks to JNDI, so the JMS URI syntax lets you have variants of the core syntax to support existing vendor mechanisms beyond JNDI lookup 🦋 The variant is part of the syntax on purpose, so that tools which don't know about a variant can still spot that a URI has an alternate interpretation. Very thoughtful, iykyk 🧚

In its simplest and most interoperable form, the URI starts with jms:jndi: followed by a JNDI name for a Destination 💅 Sometimes interacting with a resource needs extra JNDI context info or JMS header fields and properties too, so the "jndi" variant can take that additional JNDI info as query parameters 🎀

The "jndi" variant gives you compatibility, but vendors are free to define additional variants. This spec defines three: "jndi", "queue", and "topic" 👑 Vendors who make new variants are strongly encouraged to register them with IANA, as explained in Section 9.2.1 💜

Here's the tea: the "jms" URI scheme can point to network resources, but it doesn't map to one single underlying protocol the way most other URI schemes do ☕ Instead, interoperability comes from a common Java-based API [JAVA] for messaging. Because of that, interop depends on how the API is implemented and what it can do, so two JMS implementations might or might not actually work together in practice 😭 It may also be impractical to use JMS URIs outside of Java environments 🙈

Since this is built on an API rather than a protocol, how useful a JMS URI is depends on the context it's used in 💀 That context includes agreeing on the same JMS provider or underlying protocol, agreeing on how to look up endpoints (JNDI), and, when you're sending serialized Java object messages, having Java Class environments similar enough that serialized objects can be read and written properly 🔥 Users of this scheme need to set up those shared-context parts I just listed. That context could span the whole globe, or just a small local network 🌍 With that shared context in place, this URI scheme gives you a uniform way to identify endpoints and a way to connect to them ✨

1.1. Requirements Notation

Here's how the key words work: the 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] 🤓

All syntax descriptions use the ABNF specified by [RFC5234], "Augmented BNF for Syntax Specifications: ABNF" 💖

Also, some examples here wrap long JMS URIs so they're easier to read. The line breaks are not part of the actual URIs, so don't copy them in 🙈

2. URI Scheme Name 🦋

The name of the URI scheme is "jms" 💅

3. Syntax of a JMS URI 🎀

Here's the ABNF that describes the "jms" scheme URI syntax 🧚

jms-uri = "jms:" jms-variant ":" jms-dest
   [ "?" param *( "&" param ) ]

jms-variant = segment-nz-nc

jms-dest = segment-nz ; specific meaning per variant

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]. For encoding considerations, see Section 5 of this document 🌸

4. URI Scheme Semantics 👑

JMS URIs are used to locate JMS [JMS] Destination resources. They don't specify any actions to take on those resources 💅 What you can do with a JMS Destination is fully and normatively defined by the JMS specification, so it's out of scope for this URI spec 📚

The required parts of the syntax are the "jms" scheme name at the start, the <jms-variant> element that says which variant you're using, and the <jms-dest> element that identifies the Destination based on that variant ✨ This doc defines three <jms-variant> values: "jndi", "queue", and "topic". All the terminals that come out of the <jms-variant> and <jms-dest> production rules are case-sensitive, so be careful with your capitals bestie 🙈

Parameters help refine how you locate and use the Destination 🎀 Parameter names and values are case-sensitive too. They can show up in any order, and each parameter name SHOULD NOT appear more than once 😭 If a parameter does show up multiple times, all but the last instance MUST be ignored 💀 When comparing, a missing parameter is not the same as a URI where that parameter is set to a default value, because defaults can vary depending on the context of a specific use 🔥

Each variant can have its own query parameters. All of those variant-specific parameters SHOULD use the variant's name as a prefix 🦋 For example, a vendor-specific variant called "vnd.example.ex" might also define a parameter named "vnd.example.exParameter" 🧚 Parameters that apply across multiple variants (like JMS settings, since they're generally applicable) MUST NOT have a name that starts with the name of any known variant 💖 This is what lets tools that don't know a particular variant tell apart the parameters that belong to a variant from the ones that are more broadly applicable. Iconic design, no notes 👑

Here are some examples of the URI scheme 🌈

jms:jndi:SomeJndiNameForDestination?
   jndiInitialContextFactory=
   com.example.jndi.JndiFactory&priority=3

jms:queue:ExampleQueueName?timeToLive=1000

4.1. Shared Parameters ✨

Okay bestie, so on top of the required particles, the "jms" URI scheme also has some shared parameters 💅 that work for every single variant. They line up with the headers and properties on the JMS Messages that get sent. For deliveryMode, timeToLive, and priority, the default values can be set by the context, like with environment variables or in the config of a particular network app 🧚. JMS has its own defaults for these properties too. So the "context default" means the default in the context of a specific use, or the JMS default for that property if the context doesn't define one 🫶.

4.1.1. deliveryMode

Basically this one tells you whether the request message is persistent or not 💾. It corresponds to the JMS message header field "JMSDeliveryMode", which is 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 isn't specified, then the context default MUST be used 🙈.

4.1.2. timeToLive

This is the lifetime of the request message, in milliseconds, written as a decimal number ⏳. It corresponds to the JMS Time-To-Live value from Section 4.8 of the JMS 1.1 specification. If this parameter isn't specified, then the context default MUST be used 🌸.

4.1.3. priority

This is 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, written as a decimal number. It corresponds to the JMS message header field "JMSPriority". If this parameter isn't specified, then the context default MUST be used 👑.

4.1.4. replyToName

This one 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, the value specifies the JMS Destination object that a response message ought to be sent to. It's giving "where do I reply" energy 💌.

4.2. "jndi" Variant

The "jndi" variant means you're using JNDI to discover the Destination object 🔍. When this is the variant, the <jms-dest> part of the syntax is the name used for JNDI lookup purposes. You can also add some extra JNDI-specific parameters ✨. The JNDI-specific parameters SHOULD only be processed when the URI variant is "jndi".

4.2.1. JNDI Parameters

4.2.1.1. jndiConnectionFactoryName

This specifies the JNDI name of the Java class providing the connection factory 🏭. (See Section 3.8, "Identifiers", of [JLS] for the specification of a legal Java class name, bestie, it's a whole thing 🤓.)

4.2.1.2. jndiInitialContextFactory

This specifies the fully qualified Java class name of the "InitialContextFactory" implementation class to use 🧩.

4.2.1.3. jndiURL

This specifies the JNDI provider URL 🌐. It's written in a form consistent with javax.naming.spi.NamingManager.getURLContext(String scheme, Hashtable environment), as defined in the JNDI specification [JNDI].

4.2.1.4. Additional JNDI Parameters

Sometimes connecting to a JNDI provider needs extra parameters too 🥹. You can pass these in as custom parameters (see Section 4.4). To mark a custom parameter as JNDI specific, its parameter name needs to start with the prefix "jndi-" 🏷️.

For example, if the JNDI provider needs a parameter named "com.example.jndi.someParameter", you can supply it in the URI like this: jndi-com.example.jndi.someParameter=someValue 💖

4.2.2. Example of Performing a JNDI Lookup

Okay so, to do 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. Then it passes the two properties to the InitialContext constructor 🧁.

To locate a connection factory or Destination object, the application passes the name of the object into the InitialContext.lookup() method 🔎.

For example, the 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" 🗂️.

/*
 * 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) 📨.

/*
 * 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);

4.2.2.1. Performing a JNDI Lookup with Custom Parameters

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 comes from removing the "jndi-" prefix from the URI parameter name, and the value of the property is the value of the parameter 💫.

For example, the JMS URI...

jms:jndi:REQ_QUEUE
  ?jndiURL=file:/C:/JMSAdmin
  &jndiInitialContextFactory
  =com.sun.jndi.fscontext.RefFSContextFactory
  &jndiConnectionFactoryName=CONNFACT
  &jndi-com.example.jndi.someParameter=someValue

...tells the consumer to use the following properties to connect to the JNDI provider 🫧:

java.naming.provider.url=file:/C:/JMSAdmin
java.naming.factory.initial=
  com.sun.jndi.fscontext.RefFSContextFactory
com.example.jndi.someParameter=someValue

4.3. Vendor Destination Names -- Variants "queue" and "topic"

The JMS Session object gives you a way 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 🌈.

Since the Session interface needs outside knowledge about whether a given name is a Queue or a Topic, this section defines two variants instead of introducing one new variant 🧠. A JMS URI can indicate which of these methods to use by specifying the appropriate variant, either "queue" or "topic". For example:

jms:queue:ExampleQueueName

identifies a JMS Queue Destination, and

jms:topic:ExampleTopicName

identifies a JMS Topic Destination 🎯.

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, and both 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> 🔐.

4.3.1. Treatment of replyToName Parameter

When used with the "queue" and "topic" variants, the replyToName parameter (specified in Section 4.1.4) always refers to the name of a JMS Queue to look up via the Session.createQueue() method, or its equivalent 📬. For either variant, if a JMS Topic is required as a response Destination instead, a JMS URI can use the "topicReplyToName" parameter. This parameter defines a name to look up with the Session.createTopic() method, or its equivalent 📣.

A JMS URI MUST NOT specify both a "topicReplyToName" and a "replyToName" parameter. Don't double up, bestie 🚫💅

4.3.2. Obtaining a Session via JNDI

Using the Session.createQueue() and Session.createTopic() methods assumes that a client program has already obtained a Session object 🫠. So where does that Session object come from? How does a client get it? One way is simply to access vendor-specific APIs 🏢.

Another way to get a Session object is to just revert to using JNDI 🔄. That is, if a Session isn't 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 🧚‍♀️.

Combining the "queue" and "topic" variants with JNDI lookup for an implementation of ConnectionFactory raises an important consideration for JMS URI clients ⚠️. Once clients use JNDI for one part of discovering a Destination, they almost certainly could use a vendor-neutral JNDI lookup for the Destination object itself, rather than 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 💭✨.

4.3.3. Limitations of "queue" and "topic" 🫶

okay so the JMS spec is super clear that the two methods on the Session interface hand back vendor-specific names for Destinations 💅 so bestie, anyone using the jms URI scheme should really think hard about when these two variants are worth it 🤔 if you're planning to hop between JMS vendors, you might also need to plan on regenerating any resources that hold URIs in this vendor-specific form 🔄

a JMS vendor can offer other ways to get names that can be passed to Session.createQueue() and Session.createTopic() ✨ when you use names from those other routes, users of this URI spec are encouraged to double-check that the names actually work as expected in all circumstances 👀 no skipping the check, periodt 💀

4.4. Custom Parameters 🎀

the set of parameters is extensible, and it's giving total freedom 🦋 any other vendor- or application-defined parameter can go in the URI by passing it as <param-name>=<param-value>, just like the well-known parameters 🌈

⚠️ 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. 🙈

5. Encoding Considerations 🌸

the jms URI scheme tells apart <unreserved> characters and <pct-encoded> characters, as defined in [RFC3986] 🧚 apart from these encoding considerations, the characters "?" and "&" MUST be encoded when they show up within the <jms-dest> particle (for example, a JNDI name) or in query parameters 🔐 and the character ":" SHOULD be escaped when it appears in the <jms-dest> portion of the syntax 💖

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 ✨ non-negotiable, bestie 😤

6. Applications/Protocols That Use the JMS URI 🦋

a bunch of vendors make implementations of the JMS Service Provider Interface (SPI) 💜 these products interoperate at the API level, in the Java programming language 🍓

some vendors have also shipped extra products that work with their own SPI implementations ✨ these extensions might be able to use this URI scheme too 🌟

the vendors working on this URI scheme are also working on a specification for carrying SOAP messages over their own implementations of JMS [SOAP-JMS] 📦 plus, the Service Component Architecture Bindings technical committee (TC) [SCA-TC] at OASIS uses the jms URI scheme to identify JMS Destinations in [SCA-JMS] 👑

7. Interoperability Considerations 🧚

this jms URI scheme is all about identifying a JMS Destination object, plus some characteristics of communicating using that Destination 🎯 it specifically does NOT describe how JMS itself is implemented or how it delivers messages 🙅‍♀️ so interoperability concerns are limited to how implementations obtain and use a Destination object 💅

this scheme defines three variants for getting a Destination 🌈 they hit their goals using JNDI and JMS APIs, with no new APIs or protocols defined here ✨ but since JNDI and JMS are involved, interoperability problems might pop up if implementations don't conform to the specs for those APIs 😬 and because it's Java (JNDI especially), the configuration of the execution environment and the use of Java ClassLoaders can change how any given URI gets interpreted 🫠

consumers of these URIs are urged to think about the scope and consistency of the environment where the URIs will be shared 👀

as Section 4 describes, others can define additional variants 🦄 these provide ways 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 🫶 just note that while extra variants might seem more flexible, using variants not defined here might make it harder to switch to an alternate JMS provider 😩

8. Security Considerations 🔥

Section 7 of [RFC3986] identifies some of the security concerns this specification ought to address 🛡️ this one's serious, so pay attention, iykyk 🥹

8.1. Reliability and Consistency 💅

this specification only identifies the variant (<jms-variant>) and the variant-specific details (<jms-dest>) as an essential part of the URI 💖 for reliability and consistency, these two are the only parts that can reasonably be expected to stay stable ✨ other optional JMS configuration and message properties that are indicated as URI parameters, like "timeToLive", can reasonably be determined by the sender of a message without affecting the recipient 🎀 and if a recipient wants to dictate certain parameters, like "jndiConnectionFactoryName", those parameters can be specified 🙌

8.2. Malicious Construction ⚠️

8.2.1. Recipient Concerns 😳

a malicious consumer of a service using a JMS URI could send, as part of a JMS message, a URI with a parameter like "timeToLive" whose value in the URI differs from the matching JMS message property (the JMSExpiration header field, in this example) 💀 so 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 a JMS-based application might use to decide which messages it sees, and the processing of the rest of the application 🕵️‍♀️ as defined in this document, the parameters of concern include:

  • deliveryMode
  • timeToLive
  • priority

message senders are strongly urged to remove extra parameters like the above from the URI in environments where the data would be redundant with info specified elsewhere in the JMS message 🧹

any use of additional parameters, whether as 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 📝 and if a recipient knows about the jms URI scheme and gets a message containing a JMS URI, it MUST ignore or discard any parameters it does not recognize 🗑️

8.2.2. Sender Concerns 🫣

a third party could intercept and replace a URI containing any of the JMS/JNDI configuration parameters, like "jndiConnectionFactoryName", "jndiInitialContextFactory", or "jndiURL" 😱 since these parameters can affect how an implementation sets up its initial connection, they could be used to subvert communications 🐍 this could possibly re-route communications to third parties, who could then monitor sent messages 👁️ so clients SHOULD NOT use these URI parameters unless they're assured of their validity in trusted environments 🔒

8.3. Back-End Transcoding 🧃

this specification uses the URI specification and builds around the JMS specification, so it has no particular transcoding issues 🙂 any issues like that are problems with the underlying implementation of Java and the Java Messaging Service being used 🤷‍♀️

8.4. Semantic Attacks 🎭

a possible semantic attack on the "jndi" variant could happen by swapping characters in the JMS URI from one language with equivalent-looking characters from another language, known as an "Internationalized Domain Name (IDN) homograph attack" [HOMOGRAPH] 😵 this could happen in a bunch of ways 🫠 for example, if an environment allows automatic registration of JNDI Destination names, a malicious actor could register and then publicize a lookalike of an existing Destination name 👻 such an environment ought to prevent the use of homograph equivalents, maybe by restricting allowed characters, so clients don't accidentally send their requests to unintended Destinations 🙏

the "queue" and "topic" variants have the same concerns as the "jndi" variant 💜 on top of that, since Destination names are vendor defined, URIs using these two variants might include special characters that significantly change the meaning of the URI 🌀 it's possible that adding a single character, one that's hard for a human to notice, could totally change the intended meaning of a URI 😭 where that might be an issue, users of this URI are urged to strongly consider the "jndi" variant instead 💅

8.5. Other Security Concerns 🌙

this specification doesn't define or anticipate any use for IP addresses as part of the URI, so no issues around IP addresses, rare or otherwise, are raised here 🙃

this specification also doesn't define any characteristics of a "jms" scheme URI that contain sensitive information 🫶

9. IANA Considerations 📋

9.1. URI Scheme Registration 🦋

IANA registered the Java Message Service URI scheme described in this document, following the scheme registration request below, using the template from [RFC4395] ✨

o  URI scheme name: jms

o  Status: Provisional

o  URI scheme syntax: See Section 3

o  URI scheme semantics: See Section 4

o  Encoding considerations: See Section 5

o  Applications/protocols that use this URI scheme name: See
   Section 6

o  Interoperability considerations: See Section 7
o  Security considerations: See Section 8

o  Contact: See the Authors' Addresses section

o  References: See the References section

9.2. "jms" URI Scheme Registries 🗂️

per this URI scheme, IANA has created a registry for possible "variants" 💖 IANA can reject obviously bogus registrations 🙅‍♀️

9.2.1. JMS URI Variants 🌈

this registry lists "jms" URI scheme variants 📜 variant names beginning with "vnd." are reserved for vendor extensions 🎀 those should follow the pattern 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 🫡

all variant names are registered on a first come, first served basis 🏃‍♀️

variants must conform to the "jms-variant" production above 💅 since variants show up in URIs, they ought to be short, and they MUST NOT be more than forty characters in length ✂️

this document defines the "jndi", "queue", and "topic" variants, which are the ones initially included in the registry 👑

9.2.2. "jms" URI Scheme Variant Registration Template 💅

okay bestie, this is the template you fill out when you want a brand-new variant for a JMS URI 🦋 these are the fields that have to be in there:

To: iana@iana.org
Subject: Registration of JMS URI variant name

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.

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.

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.

9.2.3. Change Control 🔁

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, so no new hoops to jump through 💖

the change controller of a JMS URI variant can pass responsibility for it to another person or agency by informing IANA 🫶 this can be done without discussion or review, which is lowkey so convenient

JMS URI variant registrations MUST NOT be deleted 🙅‍♀️ instead, mechanisms that are no longer believed appropriate for use can be marked as obsolete in the Comment field 🪦

in exceptional circumstances, the IESG can reassign responsibility for a JMS URI variant 👑

the IESG is considered to be the owner of all JMS URI variants that are on the IETF Standards Track 🌸

10. Contributors 🫶

The authors gratefully acknowledge the contributions of:

Phil Adams
International Business Machines Corporation
EMail: phil_adams@us.ibm.com

Glen Daniels
WSO2
EMail: glen@wso2.com

Peter Easton
Progress Software
EMail: peaston@progress.com
Tim Frank
Software AG.
EMail: tim.frank@softwareag.com

Lei Jin
BEA Systems, Inc. until March 2007

Eric Johnson
TIBCO Software Inc.
EMail: eric@tibco.com

Vinod Kumar
BEA Systems, Inc. until May 2007

Amelia A. Lewis
TIBCO Software Inc.
EMail: alewis@tibco.com

Roland Merrick
International Business Machines Corporation until June 2009

Mark Phillips
International Business Machines Corporation
EMail: m8philli@uk.ibm.com

Derek Rokicki
Software AG.
EMail: derek.rokicki@softwareag.com

Stephen Todd
International Business Machines Corporation until April 2007

Dongbo Xiao
Oracle Corp.
EMail: dongbo.xiao@oracle.com

Prasad Yendluri
Software AG.
EMail: prasad.yendluri@softwareag.com

11. Acknowledgements 🌈

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. 💜

12. References 📚

12.1. Normative References

  • [JLS] Sun Microsystems, Inc., "The Java Language Specification, Third Edition", January 2005, <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/>.
  • [JNDI] Sun Microsystems, Inc., "Java Naming and Directory Interface Application Programming Interface", July 1999, <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.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
  • [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
  • [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC6075] Cridland, D., "The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry", RFC 6075, December 2010.

12.2. Informative References

Authors' Addresses ✨

Mark Phillips
International Business Machines Corporation
Hursley House, Hursley Park
Winchester, Hampshire  SO21 2JN
United Kingdom

EMail: m8philli@uk.ibm.com


Phil Adams
International Business Machines Corporation
11501 Burnet Rd.
Austin, TX  78758
United States

EMail: phil_adams@us.ibm.com


Derek Rokicki
Software AG.
11700 Plaza America Drive
Reston, VA  20190
United States

EMail: derek.rokicki@softwareag.com


Eric Johnson
TIBCO Software Inc.
3303 Hillview Avenue
Palo Alto, CA  94304
United States

EMail: eric@tibco.com
📦 where this page comes from