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

 Hi Bjoern,

Thanks for the quick response.

On 09/21/2010 11:06 AM, Bjoern Hoehrmann wrote:
> * 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
>                        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>                        ...' .../>
>
> 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
>
>   data:image/png;base64,xxxxxxxxxxxxxxxxxxxxxxxxx%20%20...

What you're pointing out appears to be an artifact of the "data" scheme,
when used in conjunction with xlink:href [1], and base64 encoding. 
Looking at the xlink:href specification, that specification specifically
allows for line breaks like the above, because it defines how the URI
should be pre-processed before being checked as a valid URI.  Putting in
the line-breaks changes the URI's strict meaning (comparison would fail,
I suspect), however, the base64 encoding discards them, apparently this
happens to all just work out.

The jms scheme, having not said anything differently from the base URI
RFC, would of course treat all spaces as part of the data, so if you
wrap a JMS URI inside xlink:href, you'd be changing the meaning of the URI.

Also, if xlink:href is a special case (and it make be, because it is
effectively trying to allow for IRIs before there were such things), it
doesn't make sense to use a JMS URI scheme in conjunction with
xlink:href, in the same way it wouldn't make sense to use a "mailto:"
URI - a JMS URI identifies a destination for communication, and isn't a
reference to the "contents" of that destination.

> 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
>                  &amp;jndiInitialContextFactory=com.sun.jndi....
>                  &amp;jndiConnectionFactoryName=CONNFACT
>                  &amp;jndi-com.example.jndi.someParameter=someValue"/>
>
> ... where there are similar rules for the interpretation of the "foo"
> attribute as there are for XLink, i.e., this ends up being
>
>   jms:jndi:REQ_QUEUE?jndiURL=file:/C:/JMSAdmin%20%20...
>
> 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.

I've not found any other URI scheme that mentions this (including the
"data" scheme),  so I really don't see that introducing it here makes
sense.  I didn't even see it in the "data:" scheme.  I'd really love an
example...

-Eric.

[1] http://www.w3.org/TR/xlink/#link-locators

Received on Tuesday, 21 September 2010 18:46:33 UTC