Subject: [Uri-review] Submitted jms scheme - draft-merrick-jms-iri-00.txt - request for further review...

From: Eric Johnson <[email-masked]>
Date: Wed, 14 Nov 2007 08:55:06 -0800

As per IETF process, and per Martin Duerst's previous suggestion on this
mailing list, we have submitted our proposed jms URI scheme as an
internet draft.

You may have already reviewed this specification, or perhaps you were
waiting until we properly submitted it to [email-masked].  If
the latter, we have now done so:

https://datatracker.ietf.org/drafts/draft-merrick-jms-iri/

We welcome any and all feedback you might have.

Thanks.
-Eric Johnson

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Nov 2007 11:08:25 -0800

Hi Eric,
	Going through the document, I did see some areas where clean-up
would be useful.  First, the document appears to register a URI scheme
and an IRI scheme; it's probably best to call that out in the title and abstract.
A reference to RFC 4395/BCP 115 is probably required, since it defines
the registration process for URIs. 
	In the document you say:

   The required particles in the JMS IRI are the scheme name ("jms"),
   the variant identifier, and the "jms-dest" portions.  The two
   recognized variants (jms-variant above) are "jndi", and "context".
   The "jms-dest" portion identifies the JMS destination object in a way
   that is determined by the particular variant.

The description of those two variant identifiers as "recognized"
seems to treat them as tokens.  Would a token registry for variant
identifiers enhance the interoperability of the result?  As it
stands now, the variants are defined by isegment-nz-nc, which
seems to mean minting a new variant will be trivial.  Is that
needed, or would an IANA first-come-first-served registry be
better?

I found the following:

   Each variant may have query parameters specific to that variation.
   All such parameters that cannot be shared across schemes should use
   the name of the variant as the prefix to the parameters.  Parameters
   that apply across multiple variants, perhaps because they are
   generally applicable, such as JMS settings, should not have any
   particular prefix, and should not begin with any known prefix.  This
   latter convention enables tools that are otherwise unfamiliar with a
   particular variant to recognize that a particular IRI includes
   parameters specific to that variant.

somewhat hard to parse. I believe it would be clearer to introduce the idea of
shared parameters first, then discuss the variant-specific variants.  

In the discussion of shared parameters, it is not clear whether this list
is exhaustive and, if not, how anything gets added.  Would a revision
of the registration document be required?  A registry and expert review?
Something else?   The baseline assumption would be revision of the registration
document, I believe, if you don't specify something else.

Is there a citation for 4.2.1.3.  jndiURL?  What schemes are permitted,
for example, and are there any other syntax constraints?

I tend to think the information in 4.2.2. belongs in an appendix,
since it is not really about the construction of the IRI/URI,but
how to resolve them within a specific context.

In 4.4, you say:

 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.

It might be cleaner to say "param-name=param-value", since that is how the ABNF
is written.  Keyword appears nowhere else in the document.

Why is:

_Warning_: Vendors and applications SHOULD NOT include sensitive
   information (such as authorization tokens) in an IRI.

at a SHOULD strength level?

In section 5, you say:

Conversions to URIs should employ the UTF-8 encoding.

This sort of seems like you're starting with RFC 3987 section 3.1's mapping
process and starting at step 2.1.  Wouldn't a reference to that mapping
process be sufficient here?  Why wouldn't you start from the top?

This may also be important when considering Section 7.  You say:

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 could affect the
   interpretation of a particular IRI.

The mapping process in RFC 3987, Section 3.1 is intended to produce URIs,
which do have an interoperable wire-level representation.  To avoid this
interoperability problem, could you not require the mapping to be performed
when the IRI changes context?  There are URIs where the dereferencing
is known to be affected by the local context (http://localhost/  ), but seeing
a scheme where there are named parameters, a way of establishing a
variant context, and still no expectation of interoperability because
of runtime execution differences is worrying. 

In section 8, you say:

    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
   "jndiConnectionFactoryName", those parameters can be specified.

I don't understand what you mean by the recipient dictating certain parameters.
Do you mean that in a protocol exchange, the lack of these parameters will cause
the recipient to reject the protocol message containing this uri/iri?  I assume
it is then up to the API to indicate what the missing parameters are? 

There are a couple of elements within the security considerations that concern
me:

   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 from the IRI extra
   parameters like the above in environments where the data will be
   redundant with information specified elsewhere in the JMS message.

This sounds as if you are saying to recipients that they should ignore parameters
when they appear to be redundant to similar data in the base messages.  The
advice to senders to avoid silly states where these don't match sounds good, but
I'm not sure how the recipient behavior works when dealing with variants.
Are you assuming that this advice is only valid for shared parameters, and is not
more general?

In describing the semantic attacks, you say:

A possible semantic attack on the "jndi" variant could be
   accomplished by replacing characters of a JNDI 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 JNDI 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.

why is this just an issue for the jndi destination name and not for other
parameters, like the replytoName or jndiUrl?  Preventing
the use of homograph equivalents is also a fairly difficult and onerous
task when the full UCS is permitted; this is one of the reasons that
the use of mapping to URIs tends to be encouraged in IETF protocol
slots.  They are less human friendly, but the ladder of comparison for
them is fairly well known and the limitations remove many homographs.
Is that an option for comparison here?

You say:

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

Could IP addresses not appear in a parameter?  How does the parameter production
prevent this, if so?

In the acknowledgements, you describe the individuals as contributors.  A
contributors section is also permitted, if you would prefer
to use it instead of or in addition to acknowledgements.

				regards,
					Ted Hardie

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Nov 2007 13:05:28 -0700

> and an IRI scheme; it's probably best to call that out in the title and abstract.

As I learned when I wrote RFC 4622, there is no such thing as an IRI
scheme. Just register the URI scheme and provide appropriate details
about how it's used with IRIs.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 15 Nov 2007 08:37:23 +0100

Peter Saint-Andre wrote:

> As I learned when I wrote RFC 4622, there is no such thing
> as an IRI scheme. Just register the URI scheme and provide
> appropriate details about how it's used with IRIs.

RFC 3987 uses the term 'scheme' many times, it's just the 
same 'scheme' as in RFC 3986.  And of course there's only a
IANA registry for URI schemes.

 Frank

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Nov 2007 07:39:39 -0700

> IANA registry for URI schemes.

If a scheme falls in the forest but the IANA doesn't register it, does
it make a sound?

You are right that, to be precise, according to the IANA one does not
register an IRI scheme because there is no registry for IRI schemes,
there is only a registry for URI schemes. Ted noted that this draft
"appears to register a URI scheme and an IRI scheme" but as far as I can
see the IANA won't do anything with the registration of an IRI scheme.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/