Re: Notes on IANA registration of variants for JMS URI scheme

I thought that the reason for specifying variants was because several 
of the vendors in the consortium had private, existing schemes, which 
could be effectively "grandfathered" by prefixing with "jms:"?

Amy!
On Wed, 20 Oct 2010 11:20:04 -0700, Eric Johnson wrote:
> My action 218 [1] is to report back to the group on options for IANA 
> registration of variants in the JMS URI scheme.
> 
> In case you're curious, you can look at the long list of current 
> registrations [4].
> The registration question is governed by RFC 5226 [2].
> 
> One option - a "delegated" namespace - think Java package names, or 
> DNS names (where the IANA only manages the top level).
> 
> Another option - one or more designated experts that will review 
> proposed registrations.
> 
> The IANA defines the following "policy" definitions for ways to treat 
> registration [3]:
> 
>    * private use
>    * experimental use
>    * hierarchical allocation
>    * first-come, first-served
>    * expert review
>    * specification required
>    * RFC required
>    * IETF review
>    * standards action
>    * IESG approval
> 
> We can divide up the "space" of possible registered variants, for 
> example defining a prefix for variants like "x-" which defines 
> "private use" or "experimental use", and perhaps everything else 
> comes under "specification required."
> 
> My suggestion:
> Since we do not expect any further registration of JMS variants, in a 
> sense, it almost doesn't matter what we choose.  It seems like a 
> combination of first-come, first-served registration, coupled with an 
> "x-" prefix for experimental use will provide appropriately low 
> overhead.
> 
> Thoughts?
> 
> If we follow my suggestion, I suggest the following changes to the spec:
> 
> In section 4:
> After:
> The three recognized variants (<jms-variant> above) are "jndi", 
> "queue", and "topic".
> 
> ... add:
> Variant names starting with "x-" are reserved for experimental use.
> 
> Also, section 9 needs changes, but depending on what we decide above, 
> that will affect what we put there.
> 
> -Eric.
> 
> [1] http://www.w3.org/2002/ws/soapjms/tracker/actions/218
> [2] http://tools.ietf.org/html/rfc5226
> [3] http://tools.ietf.org/html/rfc5226#section-4.1
> [4] http://www.iana.org/protocols/
> 
> 
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 20 October 2010 18:38:06 UTC