[Standards-JIG] query component in XMPP URIs
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.
Jabber Software Foundation
More information about the Standards