[Members] MOTION: JEP-0106 (JID Escaping)

Richard Dobson richard at dobson-i.net
Fri Mar 26 04:15:56 CST 2004

> URI escaping cannot be used to escape '@' in JID node, because '@' is
> a forbidden character - encoded or not. We cannot assume JID is always
> URI-escaped, because then all not-ascii characters would have to be
> escaped too, and the whole Nodeprep would make no sense.

Can you point out where it says URI escaping cannot be used? (if this is the
case then it cannot be done the JEP-106 way either can it), also we do not
have to apply the full URI escaping specifications, we only need to reuse
the portions that are useful for us, just like we did with SOCKS5 in
bytestreams (we didnt reuse the entire spec of SOCK5 there), so there is no
problem about having to URI encode the entire JID because we dont have to,
we only need use it for encoding characters that are not allowed in the JID
node portion like '@'.

> JID is not URI, JID may written in an URI and then it has to be
> This is other level of escaping, than that used by transports.

Yea I know JID is not exactly a URI but as I said above we should be reusing
established standards wherever they apply which in this case standard URI
style escaping does apply, reading through JEP-106 it works virtually the
same as standard URI escaping should but instead uses a non standard '#' as
the escaping specifier and the only reason that the standard '%' was not
used is because if a bad implementation decision in the MSN transport, this
is what I am objecting to if you havent already realised, we shouldnt be
doing these 'quick fixes' that go against established standards when doing
it correctly and following standards would only cause short terms problems
because we should be looking at designing the protocol with the long term in
mind, and looking in the long term I see absolutely no reason so far that we
shouldnt be following standards and using '%' as the escaping specifier.

> If we don't want current escaping practices ('@' -> '%'), than we need
> some other escaping mechanism. URI-escaping could be, of course, reused,
> but then we would get things double-escaped when used in URI.

Now I hope you can see that things would not get double escaped, as we only
need reuse the aspects that are useful to use (again just like we did with


More information about the Members mailing list