qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Proposal to unify qpid and AMQP URL formats.
Date Tue, 10 Feb 2009 21:21:25 GMT
Very well considered, and highly flexible.Compatible with where AMQP1.0 is
heading (wrt TLS handling -- balance of opinion is that TLS will be on the
same port, as it would be for Kerberos based encryption).

Missed out a TLS example:

amqp+tls://foo:bar@tcp:host1:1234/vhost?clientid=baz

Which you'd actually need to establish a TLS tunnel before sending those
clear text credentials!

The only one that seems really strange is the example with "host?retry=3",
it may make sense, but it may just be something no one ever uses.

On Internet connections, or people with suitably well configured DNS, the
protocol will use SRV records if present on DNS to do server and protocol
selection.

I'm +1 for Aidan's work here.
John


2009/2/10 Alan Conway <aconway@redhat.com>

> Aidan Skinner wrote:
>
>> On Tue, Feb 10, 2009 at 4:08 PM, Alan Conway <aconway@redhat.com> wrote:
>>
>>  Does anyone care to jot down what an SSL amqp URL should look like? Would
>>> it
>>> be  ssl:host:port or tcp+ssl:host:port or tcp+tls ... I'm not well up on
>>> the
>>> ins and outs here.
>>>
>>
>> amqps:// and fail if it can't negotiate ssl?
>>
>>
> The question is, should SSL be a separate protocol or a separate URL
> scheme, i.e.:
>  amqps://tcp:myhost:1234 ; ssl as URL scheme
>  amqp://ssl:myhost:1234 ; ssl as protocol
> (other candidates for the protocol tag might be tls, tcp+tls, tcp+ssl...)
>
> Assuming we eventually want to support sctp, infiniband and other protocols
> what does it mean to say amqps://sctp:... or amqps://ib:...? Do we try to
> re-interpret the "s" in "amqps" to be meaningful for every protocol
> supported, or make it illegal to mix amqps: with non-TCP protcols? Making
> SSL a separate protocol rather than a separate URL scheme avoids these
> questions.
>
> I'm on the fence for now, any other opinions?
>
> * Proposal to unify Qpid and AMQP URL addressing.
>
> The Qpid M4 Java and C++ clients use different URL formats.
>
> Java  uses: http://cwiki.apache.org/qpid/connection-url-format.html
>
> C++ uses the AMQP 0-10 format:
> http://jira.amqp.org/confluence/download/attachments/720900/amqp.0-10.pdf?version=1section
9.1.2
>
> The AMQP 0-10 format only provides protocol address information for a
> (list of) brokers. The Qpid M4 Java format provides additional options
> for connection properties (user, password, vhost etc.)
>
> * Proposed URL syntax
>
> This following proposal combines the features of both formats,
> intended to be a unified format for Qpid and the basis of a proposal
> to the AMQP working group.
>
> Note: terms not defined below (uric, pchar, digit, alpha, host, scheme) are
> taken from http://tools.ietf.org/html/rfc3986
>
> <code>
> ; URL begins with optional user identification and list of  protocol
> addresses.
> amqp_url       = "amqp://" [ userpass ] broker_addr [ vhost ]
> userpass       = user [ ":" pass ] "@"
> user           = *pchar
> pass           = *pchar
> broker_addr    = addr *( "," addr )
> addr           = prot_addr [ options ]
> prot_addr      = tcp_prot_addr | other_prot_addr
> vhost          = "/" *pchar [ options ]
>
> ; TCP is the default protocol
> tcp_prot_addr  = tcp_id tcp_addr
> tcp_id         = "tcp:" / ""    ; tcp is the default
> tcp_addr       = [ host [ ":" port ] ]
> host           = ; see http://tools.ietf.org/html/rfc3986
> port           = *DIGIT
>
> ; Other protcol address formats can be specified by the standard or by
> implementations.
> ;  They must conform to this grammar:
> other_prot_addr= other_prot_id ":" *pchar
> other_prot_id  = scheme
>
> ; Options can be added to individual addresses or to the vhost.
> options        = "?" option *( ";" option )
> option         = name "=" value
> name           = *pchar
> value          = *pchar
> </code>
>
> Options can be applied to the entire connection or to a specific
> protocol addresses, providing a flexible way to extend the URL
> syntax. The AMQP standard will define some options, implementations
> may define proprietary options. Implementations should ignore any
> option they do not recognize.
>
> Reserved characters in option values must be percent-encoded as per
> http://tools.ietf.org/html/rfc3986.
>
> The meaning of the userpass information depends on the security mechanism
> in use. Security mechanisms should use the userpass information from the
> URL if it is appropriate but may ignore it and acquire authentication
> information in some other way. If there is no security mechanism the
> userpass information is ignored.
>
> TODO need to define:
>  - protocol address formats and options for other transports - ssl/tsl,
> infiniband, vm...
>  - standard options for values in the standard connection negotiation.
>  - qpid proprietary options (e.g. JMS clientid?)
>
> * Examples
>
> # Connect to default vhost and default AMQP port on host1 via TCP.
> amqp://host1
>
> # Connect to port 1234, virtual host "vhost" passing username "foo",
> # password "bar" and a Qpid JMS client-id.
> amqp://foo:bar@tcp:host1:1234/vhost?clientid=baz
>
> # Connect to the first of host1,host2,host3 that succeeds, retry each
> twice.
> # retry property at connection level is applied to all addresses.
> amqp://host1,host2,host3/?retry=2
>
> # Connect to the first of host1, host2, host3 that succeeds, retry host2
> twice.
> amqp://host1,host2?retry=2,host3
>
> * Differences from current formats
>
> ** Differences from AMQP 0-10 format
>
> AMQP 0-10 did not have an initial // after amqp: The justification was
> that that the // form is only used for URIs with hierarchical
> structure as per http://tools.ietf.org/html/rfc2718
>
> This proposal does use amqp:// because in fact the URL does specify a
> simple 1-level hierarchy of address/vhost. In the future this
> hierarchy could be extended to address objects within a vhost such as
> queues, exchanges etc. The // syntax is also more familiar for a URL.
>
> A parser for the above format can also parse AMQP 0-10 URLs by
> relaxing the grammer as follows:
>
> amqp_url       = "amqp:" [ "//" ] [ userpass ] broker_addr [ vhost ]
>
>
> ** Differences from Qpid Java format
>
> Addresses are at the start of the URL rather than in the "brokerlist"
> option.
>
> Option format is ?foo=bar;x=y rather than ?foo='bar'&x='y'. The use of
> "'" quotes is not common for URI query strings, see
> http://en.wikipedia.org/wiki/Query_string.
> The use of "&" as a separator creates problems, see
> http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2
>
> user, pass and clientid are options rather than having a special place at
> the front of the URL.
> clientid is a Qpid proprietary property and user/pass are not relevant in
> all authentication schemes.
>
> Qpid M4 Java URLs requires the brokerlist option, so this is an easy
> way to detect a Qpid M4 URL vs. a URL as defined here and parse
> accordingly.
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message