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

From: Eric Johnson <[email-masked]>
Date: Fri, 17 Sep 2010 14:15:40 -0700

Darts welcome:

http://tools.ietf.org/html/draft-merrick-jms-uri-09

This version addresses a bunch of concerns raised privately in email by 
members of the IETF, mostly around the question of how to compare two 
"jms" URIs, as well as removing non-normative uses of RFC 2119 language.

-Eric.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 20 Sep 2010 14:14:24 +0200

>"jms" URIs, as well as removing non-normative uses of RFC 2119 language.

It might be a good idea to specify whether (and if, how) white space in
parameter names and values (and so on) is significant. The identifiers
can apparently get rather long, and some implementations might ignore
for instance the space in `jms:x:y?z=%20example` to accomodate people
wrapping the identifiers (similarily, %00 and %0A may be an issue).
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Eric Johnson <[email-masked]>
Date: Tue, 21 Sep 2010 10:08:42 -0700

Hi Bhoern,

We discussed this in the SOAP-JMS working group, and don't quite
understand your concern.

As I understand it, URIs encode spaces as %20 in part to remove
ambiguity around situations where it might wrap.  For example

http://www.example.com/my
/service%20name

can unambiguously be understood (by a human, at least) as

http://www.example.com/my/service%20name

We also don't have a problem with parameter names or values having
spaces in them, and pretty much expect that they'll be preserved.  Seems
like we don't need to explicitly state that "parametername" is clearly
distinct from "parameter%20name".

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.

Thanks.

-Eric.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 21 Sep 2010 20:06:29 +0200

>We discussed this in the SOAP-JMS working group, and don't quite

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

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.

>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:[email-masked] · 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/

---

From: Eric Johnson <[email-masked]>
Date: Tue, 21 Sep 2010 11:46:38 -0700

Hi Bjoern,

Thanks for the quick response.

>                        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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.

> 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

---

From: Amelia A Lewis <[email-masked]>
Date: Tue, 21 Sep 2010 14:49:25 -0400

>                        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

! I wasn't aware that XLink mandated the transformation of spaces into 
www-url-encoded strings.

This particular sample works because the set of applications is known, 
and because the specified forms of encoding happen not to collide.  % 
is not in the base64 "alphabet".  If, instead of %20, the 
www-url-encoding used the (valid) alternative "+", the base64 encoded 
data would be corrupted (because the reverse transformation, '+' -> ' ' 
would remove information)

That is, at issue here is the encoding apparently mandated by XLink, 
not the data-scheme URL itself, which does not, I think, mandate how it 
is to be handled when encoded (the reference is to RFC 2045, part one 
of the MIME specification).  For that matter, if XLink had instead 
mandated the use of base64 or quoted-printable, the underlying base64 
representation would be corrupted (potentially ... at least by removing 
a required padding character that happens to precede a linefeed, at the 
end).  Unless there is a record of the transformations performed, in 
order, or an understanding of what they are, multiple transformations 
very well may fail to be reversed.  Only the application at the top 
level is likely to be able to disentangle this appropriately.

Depending upon application, the JMS URI may be encoded in a number of 
ways, and potentially multiply encoded.  It seems to me that it is out 
of scope for us to mandate how other specifications use our URI.  No?  
It should be handled "as a URI".  In XML, when a DTD defines the 
attribute type, CDATA (in which case normalization will happen, and 
embedded \n will become spaces, and multiple spaces will become single 
spaces), and when W3C XML Schema datatypes are used, AnyURI (probably; 
there may also be whitespace facets applied).  If using XLink, one 
presumably is aware that www-url-encoding is going to happen or is 
required to be applied, and so can perform the reverse operation.

So ... isn't this a concern at a higher layer than the URI 
specification layer?  The SOAP/JMS specification, for instance, might 
have to deal with encoding issues, but it seems as though the URI spec 
itself cannot.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
[email-masked]

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 21 Sep 2010 23:35:24 +0200

>have to deal with encoding issues, but it seems as though the URI spec 

It is uncommon for names and values to begin or end with white space
characters, but it is common to wrap long identifiers at the delimiters
between them. The concern is that some implementers may undo wrapping
at the wrong layer. To take an example from the draft

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

some implementations might end up treating that the same as

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

because that is what wrapping may translate to when moving from one
layer to the other without properly accounting for the wrapping. So
my comment was that it may be a good idea to include a brief note
about the significance of white space in the document, just like it
discusses case-sensitivity, default values, and ordering.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/