Richard Dobson wrote:
> One thing I was thinking of along these lines would be rather than set
> the sizes in this way regarding how clients would interact with the
> server, have a implementation guide for server developers to the
> recommended sizing for certain fields, not sure if the place for
Yes, it is a good idea to define more granular errors for these
conditions. I'll try to add those to the -04 draft, since I will
probably submit the -03 draft today and won't have time to do this
(mostly today I'm just going to check for egregious errors). The reason
for the hurry is that there'
Richard Dobson wrote:
>
>> In my working copy of rfc3921bis I have:
>>
>> ***
>>
>>The server SHOULD return a error to the client if the
>>roster set violates any of the following rules:
>>
>>1. The element MAY contain a 'name' attribute, but the value
>>of the 'name' attrib
Hello
On Fri, Jul 06, 2007 at 10:54:01AM +0100, Richard Dobson wrote:
> It would be handy to also specify an extended additional error along with
> the so that the client can know what part of the roster item
> is wrong which would add to the flexibility, e.g. xmlns="urn:xmpp:roster:errors
In my working copy of rfc3921bis I have:
***
The server SHOULD return a error to the client if the
roster set violates any of the following rules:
1. The element MAY contain a 'name' attribute, but the value
of the 'name' attribute SHOULD NOT be more than 1023 characters
Dnia 05-07-2007, czw o godzinie 16:49 -0600, Peter Saint-Andre
napisał(a):
> > If the server could handle and client knows it could handle, it could
> > use longer names.
>
> How does the client know?
It tried to put a long name in a minute ago and it succeeded.
> > "640KB SHOULD be enough for
>
> 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 i
We're talking about a handle for an IM contact or the name of a roster
group here, not the functioning of a complete operating system. Get
some
perspective.
As some perspective, the three longest proper names I know of are
places:
Krungthepmahanakornamornratanakosinmahintarayutthayamahadi
I see we're still painting the bike shed here...
Tomasz Sterna wrote:
> Dnia 25-06-2007, pon o godzinie 09:52 -0600, Peter Saint-Andre
> napisał(a):
>> If we say that the length SHOULD NOT be more than characters
>
> I would rather phrase it, that the client MAY NOT expect server to
> handle
Dnia 25-06-2007, pon o godzinie 09:52 -0600, Peter Saint-Andre
napisał(a):
> If we say that the length SHOULD NOT be more than characters
I would rather phrase it, that the client MAY NOT expect server to
handle names longer than characters.
If the server could handle and client knows i
Joe Hildebrand wrote:
>
> On Jul 4, 2007, at 8:34 AM, Richard Dobson wrote:
>
>> It is, but given the reason for it that its for database
>> implementation constraints (i.e. edging towards implementation specific)
>
> I would argue that with PEP, and the access control models that it has,
> alth
On Jul 4, 2007, at 8:34 AM, Richard Dobson wrote:
It is, but given the reason for it that its for database
implementation constraints (i.e. edging towards implementation
specific)
I would argue that with PEP, and the access control models that it
has, although this may be implementation-
The server needs these limits in order to figure out how to size
database tables, so there exists a reason. Given that constraint,
there are two paths to go down:
1) specify a maximum length
2) specify a way for the client to find out the maximum length
either way, you need to specify what h
On Jul 4, 2007, at 6:59 AM, Remko Tronçon wrote:
I agree with Michal on this one. IMO, ad-hoc limits like these have no
place in a protocol standard (especially not in a flexible one like
XMPP), because there is nothing 'logic' about them. You are limiting
the use of your protocol for no real r
Hi,
I agree with Michal on this one. IMO, ad-hoc limits like these have no
place in a protocol standard (especially not in a flexible one like
XMPP), because there is nothing 'logic' about them. You are limiting
the use of your protocol for no real reason (except that today, most
clients don't ne
On Jun 24, 2007, at 5:21 PM, Matthias Wimmer wrote:
For JIDs: This all has been already solved with stringprep which
XMPP uses (i.e. Codepoints after stringprep normalization). For the
case of roster items: Characters as how they are sent be user user
that creates the roster item (i.e. Cod
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 tim
Mridul Muralidharan wrote:
>
> More important than the limits, imo, would be the error to be conveyed
> to the client in case it set's a roster item which violates the server
> policies on size.
> This could potentially be reused in other places as well ... is
> not-acceptable descriptive enough f
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 t
More important than the limits, imo, would be the error to be conveyed
to the client in case it set's a roster item which violates the server
policies on size.
This could potentially be reused in other places as well ... is
not-acceptable descriptive enough for this ?
If we specify this, the
Matthias Wimmer wrote:
> Hi Michal!
>
> Michal 'vorner' Vaner schrieb:
>> What is the problem with saying the server can have a limit and deny to
>> perform such crazy operation.
>
> Sounds reasonable. Roster items are not exchanged between servers,
Yet. :) What happens when we define shared ro
Michal 'vorner' Vaner wrote:
> Hello
>
> On Sun, Jun 24, 2007 at 11:01:26AM -0400, Andrew Plotkin wrote:
>> On Sun, 24 Jun 2007, Michal 'vorner' Vaner wrote:
>>
>>> And it would seem more reasonable to specify (or allow servers to do so)
>>> the limit of stanza? Because it is not only the roster
Joe Hildebrand wrote:
> What do you mean by character?
The operative question is, what does XML mean by character? Here
http://www.w3.org/TR/2000/WD-xml-2e-2814#dt-character seems to
define the scope:
***
[Definition: A character is an atomic unit of text as specified by
ISO/IEC 10646 [ISO/I
Hi Michal!
Michal 'vorner' Vaner schrieb:
> What is the problem with saying the server can have a limit and deny to
> perform such crazy operation.
Sounds reasonable. Roster items are not exchanged between servers, so it
seems we do not need a common limit. Each implementation could have it's
own
Hello
On Sun, Jun 24, 2007 at 11:01:26AM -0400, Andrew Plotkin wrote:
> On Sun, 24 Jun 2007, Michal 'vorner' Vaner wrote:
>
> > And it would seem more reasonable to specify (or allow servers to do so)
> > the limit of stanza? Because it is not only the roster then, but private
> > storage, priva
Hi Joe!
Joe Hildebrand schrieb:
What do you mean by character?
- Glyph?
- Codepoint?
Do you have to perform some sort of canonicalization before counting?
Combining characters make this particularly difficult, which is why we
settled on something easy to describe and understand in JIDs.
For
What do you mean by character?
- Glyph?
- Codepoint?
Do you have to perform some sort of canonicalization before counting?
Combining characters make this particularly difficult, which is why
we settled on something easy to describe and understand in JIDs.
On Jun 24, 2007, at 7:39 AM, Matthias
On Sun, 24 Jun 2007, Michal 'vorner' Vaner wrote:
And it would seem more reasonable to specify (or allow servers to do so)
the limit of stanza? Because it is not only the roster then, but private
storage, privacy lists...
If there must be a limit, then I think the limit should be enforcible by
On 24 Jun 2007, at 15:38, Michal 'vorner' Vaner wrote:
Do we really need to have the limitation in the protocol?
That would be the place to put it, I believe, yes.
/K
--
Kevin Smith
Psi XMPP client project leader - http://psi-im.org
Hello
On Sun, Jun 24, 2007 at 03:39:21PM +0200, Matthias Wimmer wrote:
> Joe Hildebrand schrieb:
> > +1 for limiting it.
> > However, 1024 octets please, rather than characters, like JIDs.
>
> +1 for limiting it
>
> ... but please based on characters, not on octets. (I also voted against
>
Hi Joe!
Joe Hildebrand schrieb:
+1 for limiting it.
However, 1024 octets please, rather than characters, like JIDs.
+1 for limiting it
... but please based on characters, not on octets. (I also voted against
limiting JIDs based on octets.)
Reasons:
- Modern database systems as well as mode
Peter Saint-Andre wrote:
Currently, the XML schema for the jabber:iq:roster namespace does not
limit the length of an item name or a group name. I think that might
cause problems. In particular I think it might be good to specify that:
1. The 'name' attribute can be a string between 0 and 1023 c
Hi,
Why do you want to limit it anyway? What problems do we have at the moment
with the unlimited length of strings?
cheers
Tobias
On 6/22/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
Currently, the XML schema for the jabber:iq:roster namespace does not
limit the length of an item name or
Hello
On Sat, Jun 23, 2007 at 08:11:58PM -0600, Peter Saint-Andre wrote:
> Michal 'vorner' Vaner wrote:
> > On Fri, Jun 22, 2007 at 03:07:05PM -0600, Peter Saint-Andre wrote:
> >> Currently, the XML schema for the jabber:iq:roster namespace does not
> >> limit the length of an item name or a group
On Jun 23, 2007, at 7:42 PM, Joe Hildebrand wrote:
However, 1024 octets please, rather than characters, like JIDs.
+1 on that over here. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
On Jun 23, 2007, at 8:11 PM, Peter Saint-Andre wrote:
Typically, both the handle (i.e., the value of the 'name'
attribute) and
the group name are stored in a database. If you can put the complete
text of RFC 3920 as the handle and the complete text of RFC 3921 as
the
group name, then those
Michal 'vorner' Vaner wrote:
> Hello
>
> On Fri, Jun 22, 2007 at 03:07:05PM -0600, Peter Saint-Andre wrote:
>> Currently, the XML schema for the jabber:iq:roster namespace does not
>> limit the length of an item name or a group name. I think that might
>> cause problems. In particular I think it m
Hello
On Fri, Jun 22, 2007 at 03:07:05PM -0600, Peter Saint-Andre wrote:
> Currently, the XML schema for the jabber:iq:roster namespace does not
> limit the length of an item name or a group name. I think that might
> cause problems. In particular I think it might be good to specify that:
>
> 1.
Currently, the XML schema for the jabber:iq:roster namespace does not
limit the length of an item name or a group name. I think that might
cause problems. In particular I think it might be good to specify that:
1. The 'name' attribute can be a string between 0 and 1023 characters in
length. [1]
2
39 matches
Mail list logo
