qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: Proposal to unify qpid and AMQP URL formats.
Date Wed, 11 Feb 2009 10:20:39 GMT
2009/2/10 John O'Hara <john.r.ohara@gmail.com>:
> 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

Not sure you need to have a TLS in the URL since it is negotiated on
initiating the connection (similarly to frame size and others) thus I
would have thought that it is more likely an option if anything - and
the client in general should know whether it wants TLS regardless of
which alternative broker it is connected to.  It really depends on the
use cases for these URLs which I'm not entirely clear on.

In 0-10 we had a special exchange to provide clients with a list of
alternative hosts onto which they might move their connections in the
case of failover.  As of yet this functionality is not in 1-0 draft
(since exchanges have been removed).  Further in this use case there
would not seem to be any need (and it fact it would be very
undesirable) to have the username/password in the URL.
Username/password is also somewhat authentication mechanism specific
(i.e. not all methods of authentication use username and password to
establish identity).

If we were only considering the "server sends a list of alternative
brokers to the client" case then we could (theoretically) have simpler
URLs that only speak of one host, and have the server send back a list
of them (rather than a more complicated compound URL containing many
hosts).  That leads me to believe that what we are trying to define is
also meant to apply more generally and be stored as application
configuration.

I think for this work to make it into the 1-0 spec we would need to
have a full description of the purpose and examples of use of the
proposed URLs as they related to the 1-0 model.  Further I am wary of
calling this the "AMQP" URL format.  As was pointed out to me
yesterday by Rafi, for e-mails the url most often used is the
mailto:foo@bar.com - we don't often talk about e-mail URLs for
connecting to your SMTP or POP3 servers.  By analogy the "AMQP" URL
would be amqp:queue@host ... and what is being described here is some
sort of AMQP Server Connection URL...

Having said all of that, the work here is good - and I am in favour of
it getting into AMQP 1-0 - I think we just need to work from the AMQP
side on what URLs we need and what the use cases are.


-- Rob

> 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
>>
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message