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

I can confirm that TIBCO doesn't have any planned variants.

I'm going to pull together some text for the registration question.  
Hopefully I'll get something out today, but it might be tomorrow.

If you can, once I send it out, please respond quickly, on the off 
chance that I can get a draft submitted before the IETF cutoff.

-Eric.

On 10/21/10 6:36 AM, Phil Adams wrote:
> Eric,
> From my standpoint I don't see a need for any variants other than 
> "jndi", at least within the WebSphere products.
>
> Phil
> ________________________________________________________________________________
> Phil Adams
> WebSphere Development - Web Services
> IBM Austin, TX
> email: phil_adams@us.ibm.com
> office: (512) 286-5041  (tie-line 363-5041)
> mobile: (512) 750-6599
>
>
>
> From: 	Eric Johnson <eric@tibco.com>
> To: 	Amelia A Lewis <alewis@tibco.com>
> Cc: 	SOAP-JMS <public-soap-jms@w3.org>
> Date: 	10/20/2010 04:30 PM
> Subject: 	Re: Notes on IANA registration of variants for JMS URI scheme
> Sent by: 	public-soap-jms-request@w3.org
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi Amy,
>
> An important question, which I'm thinking we should explicitly ask of
> this group.
>
> Given an actual RFC for JMS URI, would others on this list need use of
> "variants" not currently specified?
>
> If yes, can you provide any details about what that variant might be?
>
> -Eric.
>
> On 10/20/10 11:37 AM, Amelia A Lewis wrote:
> > 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/
> >>
> >>
>
>