IRI Scheme for Java Message Service 1.0 RC1
draft-merrick-XXX-00

Status of this Memo

This specification may change before final release and you are cautioned against relying on the content of this specification. The authors are currently soliciting your contributions and suggestions. Licenses are available for the purposes of feedback and (optionally) for implementation.

2. Copyright Notice

Copyright Notice (c) 2004-2006 BEA Systems Inc., International Business Machines Corporation, Sonic Software, and TIBCO Software Inc. All rights reserved. Permission to copy and display the JMS IRI Scheme Specification (the "Specification"), in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of the JMS IRI Scheme Specification, that you make:

A link or URL to the JMS IRI Scheme Specification at one of the Authors’ websites

The copyright notice as shown in the JMS IRI Scheme Specification.

BEA Systems Inc., International Business Machines Corporation, Sonic Software, and TIBCO Software Inc. (collectively, the "Authors") each agree to grant you a license, under royalty-free and otherwise reasonable, non-discriminatory terms and conditions, to their respective essential patent claims that they deem necessary to implement the JMS IRI Scheme Specification.

THE JMS IRI SCHEME SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE JMS IRI SCHEME SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE JMS IRI SCHEME SPECIFICATION.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the JMS IRI Scheme Specification or its contents without specific, written prior permission. Title to copyright in the JMS IRI Scheme Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

Abstract

This document defines the format of Internationalized Resource Identifiers (IRI) as defined in [RFC3987], for designating destination addresses used in the Java Messaging Service (JMS) [REF-JMS]. It was originally designed for particular uses, but should have general applicability, wherever a JMS IRI is needed to describe JMS connections. The syntax of 'jms' IRIs is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it.

Table of Contents

• 1.   Introduction
  • 1.1   Requirements notation
• 2.   IRI Scheme Name
• 3.   Syntax of a jms IRI
• 4.   IRI scheme semantics
  • 4.1   jms-dest
  • 4.2   connectionFactoryName
  • 4.3   initialContextFactory
  • 4.4   jndiURL
  • 4.5   deliveryMode
  • 4.6   timeToLive
  • 4.7   priority
  • 4.8   destinationType
  • 4.9   Custom parameters
• 5.   Encoding considerations
• 6.   Applications/protocols that use this IRI scheme name
• 7.   Interoperability considerations
• 8.   Security Considerations
  • 8.1   Reliability and Consistency
  • 8.2   Malicious Construction
  • 8.3   Back-end Transcoding
  • 8.4   Semantic Attacks
  • 8.5   Other Security Concerns
• 9.   IANA Considerations
• 10.   Acknowledgements
• 11.   References
  • 11.1   Normative References
  • 11.2   Informative References
• Authors' Addresses
• Intellectual Property and Copyright Statements

1. Introduction

The jms IRI scheme is used to designate the Java Naming and Directory Interface (JNDI) lookup name of a JMS Destination. In its simplest form, a jms IRI contains a textual representation of the key value used to retrieve a javax.jms.Destination via JNDI.

Interaction with some resources may require JNDI contextual information or JMS headers and properties to be specified as well, the jms IRI scheme includes support for supplying this information as parameters. The same mechanism is used to permit further extension of the jms IRI scheme.

1.1 Requirements notation

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].

2. IRI Scheme Name

The name of the IRI scheme is 'jms'.

3. Syntax of a jms IRI

The following ABNF describes the jms scheme IRI syntax:

    			
 jms-iri = "jms:" jms-dest [ '?' param  *([ '&' param ]) ]

 jms-dest = 1*(iunreserved | pct-encoded)

 param = param-name "=" param-value

 param-name = 1*(iunreserved | pct-encoded)

 param-value = *(iunreserved | pct-encoded)

 iunreserved = // as defined in RFC 3987

 pct-encoded = // as defined in RFC 3986

         

4. IRI scheme semantics

The only required particles in the jms-iri are the scheme name itself and the JMS Destination access key. JMS relies heavily on JNDI for interoperable functionality (vendor extensions may provide alternate means of acquiring a javax.jms.Destination, but only JNDI is interoperably specified). The major required particle in the IRI is the name of the Destination, which can then be looked up in a (prepared) JNDI repository.

In addition to the required particles, the jms IRI scheme supports the following "well-known" properties, which may be included as parameters in any order (following the '?' parameter-start indicator, and separated by '&'). This pattern is consistent with other non-hierarchical IRI specifications.

4.1 jms-dest

Taken from the grammar above, this specifies the JNDI name of the destination queue or topic

4.2 connectionFactoryName

Specifies the JNDI name of the Java class providing the connection factory.

4.3 initialContextFactory

Specifies the fully qualified Java class name of the "InitialContextFactory" implementation class to use.

4.4 jndiURL

Specifies the JNDI provider URL.

4.5 deliveryMode

Indicates whether the request message is persistent or not. This may be 2 ("persistent") or 1 ("non-persistent").

4.6 timeToLive

The lifetime, in milliseconds, of the request message.

4.7 priority

The JMS priority associated with the request message. As per section 3.4.10 of the JMS 1.1 specification this must be a number between 0 and 9, inclusive.

4.8 destinationType

Specifies whether the destination is a javax.jms.Queue or a javax.jms.Topic, with the value "queue" or "topic", respectively.

4.9 Custom parameters

The set of parameters is extensible. Any other vendor- or application-defined parameter may be supplied, in the IRI, by passing it as "keyword=value" just like the set of well-known parameters.

Warning: Vendors and applications SHOULD NOT include sensitive information (such as authorization tokens) in an IRI. Other means of authorization, authentication, and identification should be used. Also see the security discussion below about properties that may be duplicated as JMS message properties.

5. Encoding considerations

The jms IRI scheme distinguishes between "iunreserved" characters and "pct-encoded" characters, as defined in [RFC3987]. Apart from these encoding considerations, it may be necessary to encode the characters '?' and '&' appearing within the destinationName particle or in query parameters. The character ':' SHOULD be escaped, when appearing in a destinationName.

6. Applications/protocols that use this IRI scheme name

A variety of vendors provide implementations of the JMS Service Provider Interface. These products interoperate at the API level, in the Java[tm] programming language.

Some vendors have provided additional products which interoperate with their own SPI implementations. These extensions may also be able to make use of this IRI scheme.

7. Interoperability considerations

As JMS is an API rather than a protocol, it therefore specifies no interoperable wire-level representation. However, because the jms IRI scheme is defined with reference to the API, this lack of wire-level compatibility does not create an interoperability issue.

IRIs defined in this scheme are dependent upon the code and configuration executing in the runtime environment, which may present interoperability issues. In particular, the available classes and classloaders and the JNDI configuration will affect the interpretation of a particular IRI.

8. Security Considerations

Section 7 of [RFC3986] identifies some of the security concerns that should be identified in this specification.

8.1 Reliability and Consistency

This specification identifies only the destination ("jms-dest") as an essential part of the IRI. For reliability and consistency purposes, this is the only part that can reasonably be expected to be stable. Other optional JMS configuration and message properties, indicated as IRI parameters, like the "timeToLive", may reasonably be determined by the sender of a message, without affecting the recipient. Insofar as a recipient may wish to dictate certain parameters, such as the "connectionFactoryName", those parameters can be specified.

8.2 Malicious Construction

8.2.1 Recipient Concerns

A malicious consumer of a service using a JMS IRI could send, as part of a JMS message, an IRI with a parameter such as "timeToLive" with a value specified in the IRI that differs from the corresponding JMS message property ("JMSExpiration" header, in this example). In the case of such messages with such IRIs, recipients are strongly cautioned to avoid applying processing logic based on particular IRI parameters. Discrepancies could be used to exploit differences in behavior between the JMS transport layer and the processing logic on top of that layer. In the context of this specification, the parameters of concern include:

deliveryMode

timeToLive

priority

Message senders are strongly urged to remove extra parameters like the above in environments where the data will be redundant with information specified elsewhere in the JMS message.

8.2.2 Sender Concerns

A third party could intercept and replace an IRI containing any of the JMS/JNDI configuration parameters, including "connectionFactoryName", "initialContextFactory", "jndiURL". As these parameters may affect how an implementation establishes an initial connection, such parameters could be used as a means to alter how the communication is established. This could possibly result in re-routing communications to third-parties, who could then monitor sent messages. Clients should use these IRI properties only when assured of their validity in trusted environments.

8.3 Back-end Transcoding

This specification, in using the IRI specification, and building around the JMS specification, has no particular transcoding issues. Any such issues are problems with the underlying implementation of Java and Java Messaging Service being employed.

8.4 Semantic Attacks

A possible semantic attack could be accomplished by replacing characters of a destination name in one language with equivalent looking characters from another language, known as an "IDN homograph attack" (IDN) [REF-Homograph]. This kind of attack can work on a jms IRI for the destination name, and only when the JMS environment enables automated registration of JMS destinations. Such an environment should prevent the use of homograph equivalents, so that clients do not accidentally send their requests to unintended destinations.

8.5 Other Security Concerns

This specification does not allow for IP addresses, so no issues around IP addresses, rare or otherwise, are raised by this specification.

This specification does not define any characteristics of a jms scheme IRI that contain sensitive information.

9. IANA Considerations

This document has not yet been exhaustively checked for possible action by the IANA.

10. Acknowledgements

The authors gratefully acknowledge the contributions of: Phil Adams - International Business Machines Corporation - phil_adams@us.ibm.com; Glen Daniels - Sonic Software - gdaniels@sonicsoftware.com; Lei Jin - BEA Systems, Inc. - ljin@bea.com; Eric Johnson - TIBCO Software Inc. - eric@tibco.com; Vinod Kumar - BEA Systems, Inc. - vkumar@bea.com; Amelia A. Lewis - TIBCO Software Inc. - alewis@tibco.com; Roland Merrick - International Business Machines Corporation - roland_merrick@uk.ibm.com; Mark Phillips - International Business Machines Corporation - m8philli@uk.ibm.com; Stephen Todd - International Business Machines Corporation - stephen_todd@uk.ibm.com; and Dongbo Xiao - BEA Systems, Inc. - xiaod@bea.com.

This document was produced using the xml2rfc tool [RFC2629].

11. References

11.1 Normative References

11.2 Informative References

Authors' Addresses