[Standards-JIG] Re: [xmppwg] query component in XMPP URIs

Peter Saint-Andre stpeter at jabber.org
Thu Sep 30 15:52:54 UTC 2004


On Tue, Sep 28, 2004 at 04:24:08PM -0700, JD Conley wrote:

> I've got a couple of other use cases for URIs (for your #4 -- other
> kinds of shortcuts):
> 1) Advertise a Bytestream (JEP-0095/96/65/47/etc)
> 	xmpp:user at example.com/resource?bytestream&streamid=12345
> 2) Join a conference room (JEP-0045).
> 	xmpp:room at conference.example.com/nickname?join&password=xxxyyy

Thanks for the additional use cases. I'd forgotten about the "join a
room" use case, but it's one I've heard mentioned before.

> The Jabber Registrar seems like the best place for URIs dealing with
> JEPs such as MUC and bytestreams.  On the other hand, IMHO, query
> components that are pure XMPP, such as generic message, presence, and IQ
> should be handled by the IANA.  That seems to be how everything else is
> dealt with.

Two registry locations seems unnecessarily confusing to me.

> Key/Value pairs are familiar to developers and end users alike.  I don't
> see any reason not to stick with them.  I haven't seen any use cases
> that don't fit into the pattern.

Agreed. I will work to define the ABNF for that today or tomorrow.

/psa

> > -----Original Message-----
> > From: Peter Saint-Andre [mailto:stpeter at jabber.org]
> > Sent: Tuesday, September 28, 2004 3:14 PM
> > To: standards-jig at jabber.org; xmppwg at jabber.org
> > Subject: [xmppwg] query component in XMPP URIs
> > 
> > (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:
> > 
> > http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-uri-05.txt
> > 
> > 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
> > (JEP-0077).
> > 
> > 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
> > xmpp:pubsub.example.com?node=foo
> > xmpp:example.com?iq&type=get&xmlns=jabber:iq:register
> > 
> > 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:
> > 
> > http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
> > 
> > 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":
> > 
> > http://www.w3.org/TR/html401/interact/forms.html#control-name
> > http://www.w3.org/TR/html401/interact/forms.html#current-value
> > http://www.w3.org/TR/html401/interact/forms.html#successful-controls
> > 
> > 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
> > 
> > --
> > Peter Saint-Andre
> > Jabber Software Foundation
> > http://www.jabber.org/people/stpeter.php
> > 
> > _______________________________________________
> > xmppwg mailing list
> > xmppwg at jabber.org
> > http://mail.jabber.org/mailman/listinfo/xmppwg
> 
> 

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php




More information about the Standards mailing list