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:22:26 GMT
Sorry that's ALAN's work!
Many apologies
John

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