[Standards] XMPP URI usage in "HTTP over XMPP"

Peter Waher Peter.Waher at clayster.com
Wed Jul 10 03:53:53 UTC 2013


Hello Ralph

Thanks for your mail. You're absolutely correct. It was sloppy of me to propose a URI scheme with the same name as the previous xmpp scheme. I'm sorry.

I've therefore renamed the scheme to httpx (§4.3.1.1 ff). This URI scheme is through to work seamlessly with existing applications, without requiring changing the web applications themselves (except if full URL's including schemes are used inside the application).

I've also added an URI Scheme Registration Template to the document (§8.1), as per BCP 35, that we can mail to IANA to register the new provisional URI scheme, when the XSF has approved the proposal and moved it to experimental.

I've attached the latest revision for your revision.

Sincerely,
Peter Waher


-----Original Message-----
From: Ralph Meijer [mailto:ralphm at ik.nu] 
Sent: den 4 juli 2013 09:00
To: XMPP Standards
Subject: [Standards] XMPP URI usage in "HTTP over XMPP"

Hi,

The usage of the xmpp URI scheme in the "HTTP over XMPP" proposal does not conform to the syntax and semantics defined in RFC 5122. In the following I will use URI terminology as defined in RFC 3986 (URI: 
Generic Syntax) to explain how XMPP URIs are structured.

The syntax of any URI is as follows:


          foo://example.com:8042/over/there?name=ferret#nose
          \_/   \______________/\_________/ \_________/ \__/
           |           |            |            |        |
        scheme     authority       path        query   fragment
           |   _____________________|__
          / \ /                        \
          urn:example:animal:ferret:nose

In XMPP URIs, we the define the different components as follows:

  * The authority component is used to denote the entity to authenticate
    as (localpart at domain), before processing the rest of the URI.
  * The path component is the target entity to be communicated with.
  * The query component is for specific interaction semantics and
    subaddressing.

Usually, the authority component is omitted. In this case, the entity used for authentication is not specified, and assumed to be whatever the processing application chooses from its configuration. An example is:

     <xmpp:ralphm at ik.nu>

This is just a reference to my JID. Another example includes a suggested
interaction:

     <xmpp:ralphm at ik.nu?message>

The result of clicking on a link pointing to the URI above could be opening up a message entry dialog to send a message to my JID, using a pre-defined account (or allowing the user to select on in the dialog).

However, if a specific entity is required to be used for authentication, an authority component may be included:

     <xmpp://guest@example.com/ralphm@ik.nu?message>

This requires the application to connect to example.com, authenticate as guest at example.com and then send the message upon completing the dialog.


Back to "HTTP over XMPP", I believe that in general, an authority 
component is not required. One of the examples in the pro-XEP made into 
a proper XMPP URI would probably look like this:

    <xmpp:httpServer at clayster.com/api?;p1=a&p2=b>

Note that due to hysterical reasons, there is a semicolon directly 
following the question mark. The space in between is reserved for 
specifying the so-called querytype, as registered with the XMPP 
Registrar [1]. An example is:

    <xmpp:pubsub.ik.nu?pubsub;node=test>

This points to a Publish-Subscribe node named 'test'.

It might be useful to define such a querytype for "HTTP over XMPP", too.


[1] <http://xmpp.org/registrar/querytypes.html>

-- 
ralphm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130710/7b2ecff7/attachment.html>


More information about the Standards mailing list