[Jabber-IETF] internationalization/localization

Joe Hildebrand JHildebrand at jabber.com
Tue Oct 15 19:01:14 CDT 2002

Um.  No.  I don't think I want that part of my system to keep track of who
I've sent packets to.  Memory footprint.

I don't see any "redundant" packets here.  It's quite possible that two
different messages that I send to you might be in different locales.

I'm not sure what the perf benefits of not including the attribute are,
unless you count the extra 14 bytes on each packet, and the very slight CPU
overhead of extra parsing.  

How about we add one more point:
6) If a client did not send an xml:lang attribute on the stream:stream, the
last-hop server that is about to deliver a packet to that client MAY strip
off xml:lang attributes on packets that it delivers to that client.

So, if you are a low-bandwidth client, don't send xml:lang, and you won't
get any.  Just connect to a server that has its default locale set to the
one you want, and everything works.  It's ok if servers send extra xml:lang
attributes between one another, since those connections tend to be

Joe Hildebrand

> -----Original Message-----
> From: Iain Shigeoka [mailto:iain.shigeoka at messaginglogic.com]
> Sent: Tuesday, October 15, 2002 4:30 PM
> To: Jabber; Marshall Rose
> Cc: JHildebrand at jabber.com
> Subject: Re: [Jabber-IETF] internationalization/localization
> On 10/15/02 2:52 PM, "Marshall Rose"
> <mrose+internet.ietf.jabber at dbc.mtview.ca.us> wrote:
> >> The problem is when we have s2s situations, including 
> using a GroupChat
> >> service on a remote server.  (Example: I access 
> jdev at conference.jabber.org
> >> from my jabber.com account).
> >> 
> >> It is likely that the remote service would want to know my 
> locale, so that
> >> the configuration information for rooms could be localized 
> for me.  How
> >> should it determine that?
> >> 
> >> Yes, you could argue that this should be the 
> responsibility of the groupchat
> >> protocol (which is not currently in scope for the IETF 
> work), but I think
> >> there is a generic problem here.
> >> 
> >> Let me try to boil a suggestion down to an algorithm that 
> a server could
> >> use:
> >> 1) The client SHOULD include xml:lang on stream:stream.
> >> 2) If server sees xml:lang on the stream:stream, it SHOULD 
> remember that
> >> value.
> >> 3) If the server does not receive an xml:lang from the 
> client, it SHOULD
> >> have a configurable default locale that it remembers instead.
> >> 4) For all packets, if the client does not send an 
> xml:lang attribute on the
> >> root tag of the packet, the server SHOULD apply its 
> remembered value.
> >> 5) If the client does send an xml:lang attribute on a 
> packet, the server
> >> MUST NOT modify or delete it.
> > 
> > well, this sounds like a reasonable way to proceed.
> It seems a bit noisy though. Redundant xml:lang info is going 
> to be every
> where and we could see significant performance benefits to 
> ignoring the
> suggestion. We don't want to encourage non-compliance. :)
> How about extending the idea of a default xml:lang from just 
> in the stream
> to once per jid/node:
> 1) Remain unchanged
> 2-3) remain unchanged
> 4a) Clients SHOULD send xml:lang in the first packet sent to 
> any particular
> jid since that jid became "available". Receivers can ask for default
> xml:lang info by just changing presence to unavailable, then back to
> available (in case the receiver go offline or forgets the 
> default xml:lang
> for a sender).
> 4b) For all packets, if the client does not send an xml:lang 
> attribute on
> the root tag of the packet AND if the packet is the first sent to a
> particular jid since it became "available", the server SHOULD 
> apply its
> remembered value.
> 5) remain unchanged
> 6) Every recipient SHOULD remember the last xml:lang value for packets
> coming from a particular jid. If any subsequent packets don't 
> contain a new,
> default xml:lang attribute, this remember value applies
> It's more bookkeeping for the server and compliant clients 
> but should cut
> down significantly on the xml:lang noise. Too complex?
> -iain

More information about the xmppwg mailing list