Sorry that's ALAN's work! Many apologies John 2009/2/10 John O'Hara <john.r.oh...@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:b...@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 <acon...@redhat.com> > >> Aidan Skinner wrote: >> >>> On Tue, Feb 10, 2009 at 4:08 PM, Alan Conway <acon...@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: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. >> 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-subscr...@qpid.apache.org >> > >
