[Standards-JIG] XMPP URIs was: Two questions regarding JEP-0124HTTP Binding
Mridul.Muralidharan at Sun.COM
Fri Dec 2 15:27:52 UTC 2005
The 124 spec mentions that the route attribute should follow the
syntax as specified in ref 11.
This reference seems to be MIA (reason mentioned as ref 12 I guess ?).
JEP 147 which seems to talk about related subject - is it correct to
assume that this is what is going to be the definition for XMPP URI/IRI ?
If yes , then I am wondering how 124 , which is a draft standard , could
depend on an expirimental JEP.
Peter Saint-Andre wrote On 11/30/05 03:21,:
> Ian Paterson wrote:
>>> Let's say I connect to http://proxy.saint-andre.com/ (my personal
>>> HTTP binding proxy) and I use it to log in to my stpeter at jabber80.com
>>> account at port 443 rather than 5222.
>>> So we're currently saying that I would tell my proxy this:
>>> Which we hope means "connect to jabber80.com over a TCP connection on
>>> port 443 and expect to communicate via XMPP, pretty please" but in
>>> fact (per Section 2.8 of draft-saintandre-xmpp-iri) means "connect to
>>> your usual XMPP server and generate an XMPP stanza based
>>> on application inputs and then send that stanza to jabber80.com
>> The extra features that draft-saintandre-xmpp-iri adds to a simple
>> URI/IRI are important and good. They go well beyond what is possible
>> with other URI specs like 'mailto' and 'http'. For example, there is no
>> need for contextual information like the HTML: <FORM method="post"
>> However, IMHO it should *also* be possible to use a URI simply to
>> identify a resource. AFAIK that is the fundamental property of any URI
> It *is* possible. The URI xmpp:memberbot at jabber.org identifies a bot
> that is used for voting by members of the Jabber Software Foundation.
> The URI xmpp:jdev at conference.jabber.org identifies a multi-user chat
> room that is popular among developers. The URI xmpp:jabber80.com
> identifies a Jabber server that happens to communicate over HTTP ports
> (not standard XMPP ports) so that those behind XMPP-unfriendly firewalls
> can use Jabber. Presumably such URIs MUST NOT include a port if standard
> XMPP ports are to be used. Thus the following are, I think, non-sensical
> as URIs when used as mere identifiers:
> xmpp:memberbot at jabber.org:5222
> xmpp:jdev at conference.jabber.org:5222
> What about jabber80.com? It doesn't communicate on the standard XMPP
> ports. So is the following identifier confusing?
> Well, it *is* an XMPP server, so identifying it that way seems OK. If
> you attempt to interact with that server following the procedures in
> draft-saintandre-xmpp-iri then you will be fine if both the client and
> server also support SRV records as specified in RFC 3920, since you'll
> find out it uses port 80 rather than port 5222 for client-to-server
> However, if jabber80.com does not support SRV records (or clients that
> wish to connect to it do not support SRV lookups) then we have a
> problem, because we need to specify the port, like so:
> I get a bit queasy about that because it seems unnecessary -- indeed,
> the more I think about it the less I think it's a good idea to modify
> the XMPP URI scheme in order to accommodate servers and clients that
> don't support SRV records. Is there another use case I'm missing? (BTW,
> I'd bet the IESG won't like adding port to the XMPP URI scheme, either,
> since they'll say "well, you already have a well-defined mechanism for
> discovering the port via SRV records, why are you putting that in the
> URI scheme?" So I'd rather just avoid that IESG feedback if I can...)
> I realize that previously I was fine with this (we added it to version
> 1.2 of JEP-0124 with a note about modifying the URI draft), but at this
> point I'd be more comfortable in JEP-0124 to make the 'route' attribute
> specify a "hostport" such as jabber80.com:443 (see RFC 3261 for the
> definition of a hostport).
More information about the Standards