my fault, i was thinking in another way where
XEP 166 - represent the core protocol with details on messages , not scenarios
and XEP-0208 - call flows with jingle ( more scenarios )
thanx
unni
On Nov 12, 2007 9:20 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Unnikrishnan V wrote:
> > It
Unnikrishnan V wrote:
> It will be nice if you can shed more light on this modification ( need
> for modification ). Reason i felt is, we already have XEP-0208:
> Bootstrapping Implementation of Jingle which is very incomplete. My 2
> cents for Scenarios for various session flows goes to XEP-208
It will be nice if you can shed more light on this modification ( need
for modification ). Reason i felt is, we already have XEP-0208:
Bootstrapping Implementation of Jingle which is very incomplete. My 2
cents for Scenarios for various session flows goes to XEP-208 than
XEP-0166 . XEP-0166 sho
Dave Cridland wrote:
> On Mon Nov 12 22:39:19 2007, Richard Dobson wrote:
>>> I don't see an attribute 'cid' in the HTML/XHTML specs.
>>
>> Yea its a MIME multipart/related thing rather than HTML specifically.
>
> No, that'd be a cid scheme URI, surely? There's nothing in
> multipart/related at al
On Mon Nov 12 22:39:19 2007, Richard Dobson wrote:
I don't see an attribute 'cid' in the HTML/XHTML specs.
Yea its a MIME multipart/related thing rather than HTML
specifically.
No, that'd be a cid scheme URI, surely? There's nothing in
multipart/related at all about HTML, it's only used a
Alexander Gnauck wrote:
> Tomasz Sterna schrieb:
>> Oh. I realized that I'm being to sparse.
>>
>> I meant, "stopping reading for a while".
>> If you allow 10kb per second, you just read no more than 10kb in a
>> second and pause. Then after one second read another no more than 10kb.
>>
>> The TCP
Tomasz Sterna schrieb:
Oh. I realized that I'm being to sparse.
I meant, "stopping reading for a while".
If you allow 10kb per second, you just read no more than 10kb in a
second and pause. Then after one second read another no more than 10kb.
The TCP buffering, timeouts and retransmission will
In working on a mapping [1] of XMPP chat sessions to the Message Session
Relay Protocol [2], I discovered that the use of a element in
XEP-0155 is problematic:
http://www.xmpp.org/extensions/xep-0155.html
This usage is disallowed when initiating a session negotiation but
allowed when rejecting a
I don't see an attribute 'cid' in the HTML/XHTML specs.
Yea its a MIME multipart/related thing rather than HTML specifically.
Richard
Peter Saint-Andre schrieb:
If there is interest in such an extension, I will write up a spec for it.
yes there is, +1 from me.
Alex
Tomasz Sterna wrote:
> Dnia 09-11-2007, Pt o godzinie 16:55 -0700, Peter Saint-Andre pisze:
>> And there's always
>> http://wiki.jabber.org/index.php/XHTML_Inband_Images
>> too (I haven't looked at that in a while, but we might want a way to
>> refer to the element from within the same stanza via
Rachel Blackman wrote:
>
> On Nov 9, 2007, at 3:55 PM, Peter Saint-Andre wrote:
>
>> Peter Saint-Andre wrote:
>>> XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Data Element
Abstract: This document specifies a method
Andreas Monitzer wrote:
> On Nov 10, 2007, at 00:38, Peter Saint-Andre wrote:
>
>>> URL: http://www.xmpp.org/extensions/inbox/data-element.html
>>
>> See, that was easy, wasn't it? ;-)
>
> I can see three issues here:
> 1. Your extension doesn't have any namespace
Right, I wrote it up too fast,
On Sat Nov 10 02:07:08 2007, Justin Karneges wrote:
On Friday 09 November 2007 3:35 pm, Dave Cridland wrote:
> ubiquitous encryption
Best laugh of the day!
Oh, I'm not laughing.
Other protocols have been fighting this battle for years. Is XMPP
so much different? I can see the headlines:
14 matches
Mail list logo
