Re: [amqp] AMQP Extension Registries

[Gordon Sim <gsim@redhat.com>]

On 02/29/2012 08:35 PM, Godfrey, Robert X wrote:
> There has been discussion on establishing a process by which AMQP 1.0
> extension mechanisms get added to the registries held at amqp.org. This
> has been discussed at the Member Section Action Group, and the following
> process has been proposed:
>
> We suggest that there should be two distinct mechanisms, one for the
> registration of extensions under a vendor’s own domain (using their IANA
> enterprise number for the numeric identifier, and their domain name for
> the symbolic identifier), and a separate process for the use of the AMQP
> domain (numeric id 0, symbolic amqp).
>
> The registration of extensions does not imply any sort of “blessing” on
> the part of the AMQP Member Section, or OASIS... it is simply provided
> as a resource to allow for information about extensions to be shared.
> Vendors may implement extensions and choose not to register them.
>
> For the first case we believe the process should simply be that the
> member wishing to register the extension should mail the Member Section
> with the details of the extension. Other members should then have 2
> weeks to raise any objections. Only two types of objections will be
> considered - 1) that there is insufficient documentation an end-user or
> another implementer to know how to use the extension or 2) that the
> extension is essentially identical to an existing extension
>
> For extensions in the amqp (numeric 0) domain - we believe that these
> should only be added as the result of the work of a TC and a formal vote
> on a proposal. Work in progress in a TC may be registered while the work
> is ongoing, but a warning that the details of the extension are subject
> to change should appear next to the registration details.
>
> All thoughts/comments on this proposed process would be appreciated,

This sounds generally good to me. My one suggestion would be to explore 
whether we could also offer a 'neutral' descriptor for unofficial 
(essentially experimental) extensions. E.g. x-amqp for the symbolic and 
perhaps 3284 (OASIS Consortium's PEN) for the numeric.

This could provide a middle ground between a 'vendor' defined extension 
and a full-blown, officially 'blessed' extension with the aim of 
encouraging cross-vendor extensions to emerge without the overhead of a 
full standard to begin with.

Such developments would be a very useful foundation for official 
extensions. By not appearing to be 'owned' by a vendor they might be 
more palatable to other interested parties (perhaps I am being overly 
sceptical here!).

The process would be similar to that you outline above. If a proposal 
for an unofficial extension was met with alternatives or alterations we 
could hopefully decide in an informal way whether to try and unify these 
or whether to give each scheme a unique descriptor and 'let the market 
decide'.

This might also mean that the interpretation of 'essentially identical' 
as applied to vendor registered extensions could be quite lax and 
therefore less heated and less likely to cause premature 'land grabs' 
(again, I apologise if this sounds like a rather pessimistic view of the 
nature of collaboration between commercial entities!).