Michal 'vorner' Vaner wrote: > Hello > > On Mon, Jun 25, 2007 at 09:20:19AM -0600, Peter Saint-Andre wrote: >>> I just do not like setting hard limits in protocol when they do not come >>> out from the logic. I accept there is no need for such long names now >>> and probably will not be at any time, >> Why design for something that is not needed and never will be needed? > > There was probably. I know, if someone needed it, it would be abuse of > the roster for something else... but if it would be his own server, why > to forbid him to use longer names than <insert any value>.
If we say that the length SHOULD NOT be more than XXXX characters then
servers can override that recommendation if they really want to. But
IMHO they should have a good reason to do so.
>>> but if I ask why on earth 1023?
>> I proposed 1023. Feel free to propose something else.
>
> No, I mean why any actual number of anyones choice.
It's not like this is completely subjective. Mostly I was thinking about
database storage of rosters. It would be helpful for server developers
to know that roster item handles and roster group names won't need to be
more than XXXX characters / octets / bytes long. This would help client
developers too (no need for a round trip).
>>> Is there a limit for size of EMail in the
>>> protocol? No, there isn't, if the server considers it to be "too big",
>>> it tells you. But the "too big" grows with time, varies by the server
>>> and so on.
>> There are no hard limits on stanza sizes in XMPP. But it seems
>> reasonable to perhaps limit the size of roster item handles and group names.
>>
>> Naturally you might want longer limits, but IMHO they are not needed.
>> What's the use case for infinitely long roster item handles and roster
>> group names? These are supposed to be user-friendly, human-readable text
>> that an IM user can use to sort and organize roster items.
>
> No, I do not fight for bigger number in the protocol. I try to tell that
> it would be nice to leave the actual number on the
> admins/implementators.
If it's a SHOULD then you have flexibility.
>>> And as I said, if there is a problem with roster items, is there problem
>>> with private storage, privacy list and so on? Will all of them be
>>> limited?
>>>
>>> What is the problem with saying the server can have a limit and deny to
>>> perform such crazy operation.
>> The "group name too big" and "roster item handle too big" error cases
>> will be specified in rfc3920bis (they were not specified in RFC 3920).
>
> Wouldn't be forbidden enough? Someone who tries to store his hdd as a
> group name probably knows why. (And it can have some text in it too)
You don't understand the meaning of the XMPP <forbidden/> stanza error:
o <forbidden/> -- the requesting entity does not possess the
required permissions to perform the action; the associated error
type SHOULD be "auth".
> It would suit me more as a security consideration/implementation note or
> whatever. I hope the server can return forbidden now too, no?
Whatever. Look, I'm just trying to help developers here (isn't that was
documentation is for?). If you don't want to be helped then that's your
business.
Given the number of people who said "+1" I think developers would
appreciate some guidance in the spec on this issue. If we make it a
SHOULD then people who want really long roster item handles and roster
group names are free to do so.
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
