[Jabber-IETF] internationalization/localization

Richard Dobson richard at dobson-i.net
Wed Oct 16 03:28:08 CDT 2002


Yea exactly, there is no point adding all that logic just to save a couple
of bytes here and there, if we were worried about that sort of thing we
wouldnt be using XML now would we :)

Richard

----- Original Message -----
From: "Joe Hildebrand" <JHildebrand at jabber.com>
To: "Jabber" <jabber-ietf at jabber.org>
Sent: Wednesday, October 16, 2002 1:01 AM
Subject: RE: [Jabber-IETF] internationalization/localization


> 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
> high-bandwidth.
>
> --
> 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
> >
> _______________________________________________
> Jabber-IETF mailing list
> Jabber-IETF at jabber.org
> http://jabber.org/cgi-bin/mailman/listinfo/jabber-ietf
>




More information about the xmppwg mailing list