[jdev] Authority component in xmpp: URIs

[Peter Saint-Andre]

Massimiliano Mirra wrote:
> On Thu, Feb 26, 2009 at 12:26 AM, Peter Saint-Andre
> stpeter-at-stpeter.im |jdev2| <...> wrote:
>> Massimiliano Mirra wrote:
>>> Are these two URIs equivalent?
>>>
>>>   xmpp:foo at bar.org
>>>   xmpp:///foo@bar.org (notice triple slash)
>> No, they are not. In fact, the second one is not even a valid XMPP URI
>> because an XMPP URI with an authority component is constructed as follows:
>>
>> xmpp://authcomp/node@host
>>
>> Where "authcomp" cannot be empty, because it too is of the form
>> node at host.
> 
> That's what I feared.  I guess I'll have to pinch my nose real hard
> here because apparently Mozilla can parse URIs in the form of foo:bar
> but turns them into foo:///bar internally.

Ick.

>> If I had my way, we would remove the authority component from XMPP URIs
>> entirely, because they are extremely confusing and unnecessary. Perhaps
>> we can do that with rfc5122bis. :)
> 
> I guess you say so because you're thinking of the scenario
> (admittedly, the most common) where a web page points to an
> XMPP entity.  The page would have no knowledge of the account the
> visitor is going to use to interact with that entity.
> 
> On the other hand I'm thinking of the scenario where a URI is
> generated on the client side to uniquely identify an entity.  The
> account information in this case is available and relevant:
> xmpp://joe@home/mom@home is very different than
> xmpp://cto@bigcorp/mom@home.  Imagine saving those as one-click
> shortcuts.  Without the authority part, the client would have to ask
> the user what account to use.  It could save the account-entity
> association in some proprietary way, but the URI seems
> more elegant and portable to me.

Well, so the authority component is not confusing for you and it's
necessary for your use cases. So I won't agitate for removing it. :)

> Anyway, thanks for clarifying. :)

Sure thing!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20090225/a2a8fe8c/attachment-0003.bin>