W3C home > Mailing lists > Public > public-soap-jms@w3.org > September 2010

Re: [Uri-review] New posting of the "jms" URI scheme

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 21 Sep 2010 20:06:29 +0200
To: Eric Johnson <eric@tibco.com>
Cc: SOAP-JMS <public-soap-jms@w3.org>, uri-review@ietf.org
Message-ID: <6oqh96l1ueqfflnfsu5e22abej534hrbja@hive.bjoern.hoehrmann.de>
* Eric Johnson wrote:
>We discussed this in the SOAP-JMS working group, and don't quite
>understand your concern.

Say you have a SVG vector graphic that embeds a PNG bitmap graphic. That
would look more or less like this:

  <svg ...>
    <image xlink:href='data:image/png;base64,xxxxxxxxxxxxxxxxxxxxxxxxx
                       ...' .../>

So you have a lot of spaces and line breaks. The XML specification de-
fines the line breaks are turned into spaces and the XLink specification
defines that spaces, being disallowed in proper resource identifiers,
are percent-encoded, so you get


Now Base64 does not allow spaces, and RFC 2045 addresses this by man-
dating that characters not part of the Base64 alphabet are ignored. So
this has well-defined behavior and works fine in implementations.

Now my concern is that "jms" identifiers may be used in a similar en-
vironment, and someone might embed them in an XML document like

   <example foo="jms:jndi:REQ_QUEUE?jndiURL=file:/C:/JMSAdmin

... where there are similar rules for the interpretation of the "foo"
attribute as there are for XLink, i.e., this ends up being


and some implementers of the scheme come across this, and then strip
the spaces so this kind of wrapping works properly, and other imple-
menters don't come across this kind of situation, and their imple-
mentation does not strip the spaces.

I am entirely ignorant about the details of the scheme, I just saw
the draft had a number of examples where the identifers are wrapped
across multiple lines, and checked if it said anything about handling
white space in identifiers. I could not find anything, so I wanted to
point that out.

>Are there other URI schemes that address the question of spaces in
>URIs?  Can you point to the text in those specs, so I can get a feel for
>the character possible textual changes we might make?  I just don't
>recall tripping over language like that before.

Saying that all white space is significant and must be passed on un-
modified to "the next layer" would work for me, to give an example.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 21 September 2010 18:07:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:22 UTC