Version 0.7 of XEP-0177 (Jingle Raw UDP Transport) has been released.
Abstract: This document defines a Jingle transport method that results in
sending data over a raw User Datagram Protocol (UDP) connection.
Changelog: More clearly specified the hit-or-miss nature of the transport;
corrected i
On Monday 25 June 2007 5:16 pm, Stefan Reuter wrote:
> Peter Saint-Andre wrote:
> > I think that searching or filtering is something we'd define on top of
> > archives. We might use XEP-0055 for that, or something else.
>
> Ok. I would really like to push this a bit as I regard searching as a
> cru
Peter Saint-Andre wrote:
> I think that searching or filtering is something we'd define on top of
> archives. We might use XEP-0055 for that, or something else.
Ok. I would really like to push this a bit as I regard searching as a
crucial feature to be up with the features clients currenlty implem
At ClueCon this week we'll have a roundtable discussion about Jingle:
http://www.cluecon.com/schedule.html
In preparation for that, I plan to review all the Jingle specs. But I'd
appreciate it if folks on this list could also point out where they
think we still have gaps. Personally I'd like to f
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
Stefan Reuter wrote:
> Hi,
>
> recently I started to develop a plugin for Openfire to support XEP-0136.
> One feature that I am missing in the spec is searching the archive.
> I would like to propose adding a "keyword" attribute to the list request
> for that purpose.
>
> Does that make sense to
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
12 matches
Mail list logo
