Thanks for the feedback, here's an updated proposal that takes on the
suggestions so far:
Aidan + Martin: using user:pass@ syntax.
Martin: updated the examples
Jonathan: added note on percent-encoding.
Other changes:
updated my references to the current URI spec http://tools.ietf.org/html/rfc3986
Went back to using "," rather than ";" separators for multiple addresses since
rfc3986 does include "," as a reserved separator character.
Any further comments before I send this to the AMQP working group?
Nice.
I assume URL encoding is used for spaces and such?
http://en.wikipedia.org/wiki/Query_string#URL_encoding
Jonathan
Martin Ritchie wrote:
2009/2/9 Aidan Skinner <ai...@apache.org>:
On Thu, Feb 5, 2009 at 9:53 PM, Alan Conway <acon...@redhat.com> wrote:
I really like the proposal, and I think having a standardised AMQP url
is a big win.
** 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
I hate that the java urls have both of those and am so glad to see
them going.
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.
I think we should probably use username:passw...@host syntax for this,
it's more inline with what other URL formats such as http and ftp. It
also has the advantage of being more obvious that you're including
authentication information so less prone to accidently leaking it when
cut and pasting urls. If they're not relevant in the negotiated authen
scheme then they can be dropped. I think it's useful to have the
ability to include them, though I would tend to discourage their usage
from a security PoV.
Putting clientid as a property makes sense.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Alan,
It is good that we are evolving the format to better adhere to
established standards and putting it forward to the AMQP-WG to become
the standard format. I don't think we should implement in the current
form until it is adopted by the AMQP-WG othewise we may have yet
another URL format to support.
One approach would be to use replace amqp:// with qpid:// if we want
to press ahead before ratification.
If I'm understanding correctly the examples should be formatted with
the amqp:// as follows. Though agree with Aidan that we should use a
'user:p...@host' format such as:
amqp://tcp:foo:b...@host1:1234/vhost?clientid=baz
* Examples
# Connect to vhost "/" and via default AMQP port on host1. TCP is the
default protoocl.
amqp://host1
# Connect to port 1234, virtual host "vhost" passing username,
password and a JMS client-id
# 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 hosts that succeeds, retry host2 twice.
amqp://host1;host2?retry=2;host3
Regards
Martin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
* 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=1
section 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:b...@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
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-subscr...@qpid.apache.org
