[Standards-JIG] XMPP URIs was: Two questions regarding JEP-0124HTTP Binding

Mridul Muralidharan 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:
>>>    route='xmpp:jabber80.com:443'
>>> 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"
>> enctype=...><INPUT>...
>> 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
>> scheme.
> 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?
> xmpp:jabber80.com
> 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 
> connections.
> 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:
> xmpp:jabber80.com:443
> 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).
> Peter

More information about the Standards mailing list