[standards-jig] JIDs (JEP-0029)

Dave dave at dave.tj
Tue Apr 30 14:05:20 UTC 2002


How about a C-sytle rule, where only the first <insert your favorite
number here> characters are significant?  People may want to be
able to have arbitrarily long resources, but I strongly doubt that
any normal person will try to put together two unique JIDs that don't
differ within the first 256 or so characters (not bytes - it's silly to
penalize international users just so devs don't have to allocate 5x as
much storage for resources ... personally, I don't really care too much
about this detail, though).

 - Dave


Craig wrote:
> 
> '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
> there.
> 
> --C
> 
> 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!
>  >>
>  >>--C
>  >>
>  >>Thomas Muldowney wrote:
>  >>
>  >>>Craig,
>  >>>
>  >>>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
>  >>>sizes.
>  >>>
>  >>>--temas
>  >>>
>  >>>
>  >>>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 
> current
>  >>>>(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
>  >>>>here:
>  >>>>
>  >>>>http://www.jabber.org/jeps/jep-0029.html
>  >>>>
>  >>>>Peter
>  >>>>
>  >>>>--
>  >>>>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
>  >>>>http://mailman.jabber.org/listinfo/standards-jig
>  >>>>
>  >>>
>  >>>_______________________________________________
>  >>>Standards-JIG mailing list
>  >>>Standards-JIG at jabber.org
>  >>>http://mailman.jabber.org/listinfo/standards-jig
>  >>>
>  >>
>  >>_______________________________________________
>  >>Standards-JIG mailing list
>  >>Standards-JIG at jabber.org
>  >>http://mailman.jabber.org/listinfo/standards-jig
>  >>
>  >
>  >_______________________________________________
>  >Standards-JIG mailing list
>  >Standards-JIG at jabber.org
>  >http://mailman.jabber.org/listinfo/standards-jig
>  >
> 
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list