[Standards-JIG] Re: [Members] Re: MOTION: JEP-0106 (JID Escaping)
richard at dobson-i.net
Mon Mar 29 13:21:36 UTC 2004
> > Why not? If you are supporting backwards compatibility you would only
> > support escaping of characters you absolutely need to (in MSN transport
> > would be the '@' to start with), you would not support a blanket
> > start with as that would be silly because it wouldnt work.
> But if client unescapes that it should un-%-escape all characters which
> can be unescaped or the use of "standard" escaping makes no sense.
I was not talking about clients, I was talking about the MSN transport, and
as far as transports go clients do not need to do any escaping or unescaping
etc at this stage, and if they want to I would expect that until the
majority of MSN transports are upgraded to support the new escaping methods
that clients would need backwards compatible code too which as this problem
only affects the MSN transport shouldnt be too much of a hardship. But as it
stands I am not aware of any clients that do any escaping or unescaping of
MSN transport addresses themselves currently as jabber:iq:gateway (even tho
some want it depresiated, and some dont) handles all that for the client at
the only stage it needs to be done at the moment (the adding of a transport
contact), so as things stand at the moment there is no set requirement for
clients to do any escaping yet (if we keep jabber:iq:gateway for the moment
as some others have argued we should anyway).
Also the use of "standard" escaping only refers to following the industry
standard by using '%' as the escaping specifier and not '#' as is stated in
JEP-0106, the rest of that JEP is fine all except for the specifier. Using
"standard" escaping as I have already said does not mean we are have to
implement the entire spec, we only need use what we need at this stage, just
like we did with SOCKS5 in bytestreams (we didnt implement the entire spec
in that now did we).
More information about the Standards