[Standards] JID Escaping

Peter Saint-Andre stpeter at jabber.org
Mon Jul 30 19:57:05 UTC 2007


Matthias Wimmer wrote:

> I am not at all against reconsidering which characters are allowed in
> the node part of a JID. But if we go the proposed way, I think we are
> going the wrong way.
> 
> I think the arguments against this way already have been said. In short:
> - We are used to type in full JIDs as a whole for addressing. 

We are?!?

I have never seen a Jabber client that expects you to type in a full JID
in order to (say) send someone a message or add someone to your roster.
That's always done based on bare JID (user at host).

> Therefore
> with full escaping (including '@' and '/' ) we get ambiguous addresses.

That is true for full JIDs. But typically these are not shown to the end
user and I have never seen a way for a client to accept these for things
like sending message or roster additions.

> - \20stpeter at jabber.org is an allowed JID by XMPP, but somehow
> prohibited by JID escaping XEP. It is not very clear how to handle this
> when doing unescaping. Not unescaping? Then we need an exception for the
> escaping rules again, that when reescaping, this does not have to be
> encoded as \2f20stpeter at jabber.org.

Yes, that case is messy. We added it to XEP-0106 mostly to handle an odd
gateway case for LDAP, not native XMPP addresses. I'm open to removing
it for native addresses.

> Given that a proper way to do JID escaping at this level (introducing
> new characters) whould require a very big list of exceptions and
> recommondations on how to do it. - Not the way good standards are made.
> Even if we would manage to get the standard without bugs, I am sure,
> that sooner or later there would be clients not doing everything
> correctly and having problems with one of the three problem cases
> mentioned above.
> 
> That's why my recommendation is:
> - Use XEP-0106 only for gatewaying external identifiers to traditional
> JID addresses, but don't to unescaping at any other point then the
> gateway again. (Especially not in clients or other user interfaces.)

What would you call the case of re-using an existing identifier (e.g.,
email address) as a JID? Is that "gatewaying"?

> - For introducing needed characters in node parts (e.g. the "'" indeed
> is a good example what could be needed) find a better and cleaner way to
> introduce them.
> 
> May proposal for the second part (introducing new characters at the node
> part) would be to go the same way as the IETF is currently going with
> the local-part of internationalized e-mail addresses: Just extend the
> standard to allow them. This could be very easily done by RFC3920bis. We
> would just define a new stream feature (e.g. "<extended-addresses/>")
> that signals the other end of an xmpp stream, that the extended range of
> characters is allowed in the node part. If a from-JID (a to-JID probably
> never has to be delivered to such a host) containing such characters
> would have to be delivered to a host not offering <extended-addresses/>
> the message would have to be either bounced or the sending server would
> map the address using it's own an build in mapping. (Which again would
> not be unmapped by the receipient. So receipients on servers that do not
> upgrade to <extended-addresses/> would see mapped addresses, while the
> new addresses would get delivered natively to servers supporting them.)
> 
> Going that way would AFAICS only require us to define a new stringprep
> profile allowing the new characters as well as defining the new stream
> feature. - I consider this to be cleaner, easier to implement and being
> more solid.

Alternatively we could define version 2 of nodeprep so that the desired
characters are allowable.

Peter

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070730/8972c952/attachment.bin>


More information about the Standards mailing list