[standards-jig] JIDs (JEP-0029)

Craig ckaes at jabber.com
Mon Apr 29 23:58:36 UTC 2002

'Server' involves quite a lot.  For the most part, I expect both
versions of jabberd/jsm/tc cope w/ enormous resources.  I used to try w/
a few K of random text and the only thing that really blew up was
Gabber.  When I'd chat with folks, it'd fill up all their virtual
desktops with the chat window ;-)  (Note: this has been fixed.)  In
order to cope with this, jabberd/jsm/tc all deal with jids on the heap
-- even for error messages.  This is grossly inefficient.  I should be
able to sprintf the jid into a templated error message in a buffer on
the stack and send that out.  I shouldn't have to malloc every time.

That's not the biggest issue, though.  The bigger problem comes in
trying to store JIDs into a database and then search on them.  In order
to be able to search reasonably efficiently, it'd be really nice to be
able to fit a resource intoa VarChar[256], rather than a BLOB or a CLOB
where, depending upon database used, is either grossly ineffecient or
impossible to search.

xdb_oracle (j.inc) and xdb_sql (j.org) both assume jid is < 256 bytes.
  That's _full jid_ (my JEP recommends 768 bytes for full).  It looks
like xdb_sql (.org) takes this one step further -- assuming resource is
32 bytes or less.  Longer ones would be truncated.  This would affect
rosters, offline messages, etc.  Offline isn't so bad -- you'd just be
unable to reply -- roster would be worse since you'd never send presence
to the right place except on probes.  Of course the probe would fail to
match so never mind....  Does the open source ldap module allow anything
beyond auth?  If so, expect the same behavior on anything involving jids


Dave wrote:

 >Well, what currently happens if somebody tries to use a resource of 
that lenght?  Do the behaviors of JINC's and our servers differ?
 >Dave Cohen <dave at dave.tj>
 >Craig wrote:
 >>Bytes instead of characters because it is much easier to check for.
 >> UTF-8 will allow is 1 byte, 2 byte, 3 byte, 4 byte, and 5 byte
 >>(including header byte) characters.  I don't want everybody to have to
 >>necessarily have to fully validate the encoding just to verify correct #
 >>of characters.  Let the parser take care of validation.
 >>Two solid technical reasons for limiting resource:
 >>1)  In order to perform JID manipulations safely, one cannot use stack
 >>space if there is no limit.  This forces temporary calculations onto the
 >>heap which is just stupid in terms of cost.
 >>2)  As a fixed length character field, it is more database schema
 >>friendly.  If I can have Hume's _Treatise of Human Nature_ as my
 >>resource, then the only way you can store that w/out truncating it is to
 >>store it as a BLOB or CLOB.  Try searching that efficiently!
 >>Thomas Muldowney wrote:
 >>>I would personally like to see a note about why we want to limit
 >>>resources to 256 bytes.  Is there a solid technical reason?  Also, why
 >>>256 bytes?  Would it also be more beneficial to replace all references
 >>>to bytes with characters, since we should not be speaking in storage
 >>>On Mon, 2002-04-29 at 11:00, Peter Saint-Andre wrote:
 >>>>Craig Kaes has submitted a JEP that seeks to fully define what a Jabber
 >>>>Identifier is. Note that this JEP includes changes to some of the 
 >>>>(implementation-specific) features of JIDs, such as the fact that right
 >>>>now there is no limit on the length of a resource. You can review 
the JEP
 >>>>Peter Saint-Andre
 >>>>email+jabber: stpeter at jabber.org
 >>>>weblog: http://www.saint-andre.com/blog/
 >>>>Standards-JIG mailing list
 >>>>Standards-JIG at jabber.org
 >>>Standards-JIG mailing list
 >>>Standards-JIG at jabber.org
 >>Standards-JIG mailing list
 >>Standards-JIG at jabber.org
 >Standards-JIG mailing list
 >Standards-JIG at jabber.org

More information about the Standards mailing list