[Standards-JIG] query component in XMPP URIs

Peter Saint-Andre stpeter at jabber.org
Tue Sep 28 22:14:19 UTC 2004

(Cross-posted to xmppwg at jabber.org and standards-jig at jabber.org; 
posting to uri at w3.org will follow once we reach consensus.)

I'd like to get some consensus on potential uses of the query component 
in XMPP URIs before adding any more detailed information about it to 
draft-saintandre-xmpp-uri, the latest version of which is here:


Some of the uses I have seen mentioned are:

1. Suggesting a specialized interface for sending a message or presence 
information (e.g., "click here to send me a message").

1. Providing a shortcut to presence subscriptions (e.g., "click here to 
subscribe to my presence") or roster additions (e.g., "click here to 
add me to your contact list").

3. Identifying NodeIDs such as those used in JEP-0030 and JEP-0060 
(e.g., "click here to subscribe to a weather feed for your area").

4. Providing other kinds of shortcuts, such as for registration 

All of the proposed examples I have seen assume that the query 
component will contain name=value pairs as is familiar from certain 
HTTP URIs. For example (these are pseudo-URIs -- don't get hung up on 
the syntax yet):

xmpp:romeo at example.net?message
xmpp:juliet at example.org?presence&type=subscribe

On the Web, such name=value pairs are not a feature of the http: URI 
scheme, but instead are part of the HTML specification, specifically 
the encoding in a URI of data that conforms to the 
application/x-www-form-urlencoded MIME type:


So the familiar name=value syntax is actually tied to HTML forms, where 
each name is a "control name" and each value is a "current value" in 
the context of a "successful control":


It seems that people are comfortable with the name=value style of query 
component syntax, which is perhaps a valuable consideration but not 
necessarily the best reason to retain it. In particular, whereas the 
names in an HTTP URI are all control names whose context is an HTML 
form, in the suggested XMPP URIs the names are, variously, XMPP stanza 
types (message, presence, iq), attributes of those stanzas 
(type=subscribe), disco/pubsub nodes used in addressing, XML namespace 
names, child elements of the stanzas, and perhaps much else besides. 
This is a motley collection of things, not the well-scoped (if 
flexible) context provided by HTML forms.

That said, I'm not opposed to specifying that the query component of an 
XMPP URI must be a series of name=value pairs, as long as we have a 
mechanism for keeping track of known query names and thus avoiding 
collisions in the context of public protocols (what people do with 
private protocol extensions is less important, IMHO). One possible 
mechanism is registration with the IANA or the Jabber Registrar (I'd 
prefer the latter, since it seems to me that most such uses will 
probably be quite application-specific and the IANA does not especially 
need additional burdens).

If we can reach consensus on our preferred approach, I will add the 
appropriate text and ABNF definition to draft-saintandre-xmpp-uri-06 
(i.e., the next release of this spec).

Feedback welcome as always.


Peter Saint-Andre
Jabber Software Foundation

More information about the Standards mailing list