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

Peter Saint-Andre stpeter at jabber.org
Tue Nov 29 21:51:39 UTC 2005


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

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20051129/66c21d16/attachment.bin>


More information about the Standards mailing list