On 8/17/07, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Here is my first attempt at summarizing the requirements for shared XML
editing applications such as whiteboarding. The use of must and should
is approximate. Not all of these requirements need to be addressed by a
single specification.
On Wednesday 08 August 2007 08:01, Alex Jones wrote:
On Tue, 2007-08-07 at 23:08 +0200, Tomasz Sterna wrote:
Dnia 07-08-2007, wto o godzinie 21:45 +0100, Alex Jones napisał(a):
And this is exactly the problem.
rsync -a /foo/ /bar/
find -name *foo*
Correct way of rendering these
On Thu, 2007-08-16 at 10:46 -0600, Peter Saint-Andre wrote:
Peter Saint-Andre wrote:
Ralph Meijer wrote:
On Thu, 2007-08-16 at 13:09 +0200, Magnus Henoch wrote:
Peter Saint-Andre [EMAIL PROTECTED] writes:
Andreas Monitzer wrote:
On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote:
Dnia 14-08-2007, wto o godzinie 18:45 +1000, Daniel Noll napisał(a):
Then again, another way to do it is render them hidden. It looks
mangled but
when you copy the text they will still go into the clipboard
It would make the parts when the attribute was applied unnecessary (code
parts,
good summary.
WRT: 19 and 20, by XML object are you referring to the entire document or a
specific element? if the later, then the entire document is also required.
For sending of the current state there must be a way to get the current
state without sending all the changes made to get to the
Ralph Meijer wrote:
On Thu, 2007-08-16 at 09:05 -0600, Peter Saint-Andre wrote:
Ralph Meijer wrote:
[..]
We used to have an explicit 'current' item identifier for the different
extended presence specs, but these seem to have been removed. I always
assumed extended presence to have a more
The storage:* namespaces are ugly and wrong. IMHO we should get rid of
them, and replace them with things like urn:xmpp:storage:bookmarks. At
the same time we could upgrade the relevant specs (or replacement specs)
to Standards Track.
The following specs use storage:* namespaces:
XEP-0008:
On Fri, 2007-08-17 at 09:30 -0600, Peter Saint-Andre wrote:
Ralph Meijer wrote:
On Thu, 2007-08-16 at 09:05 -0600, Peter Saint-Andre wrote:
Ralph Meijer wrote:
[..]
We used to have an explicit 'current' item identifier for the different
extended presence specs, but these seem to have
Am Freitag, den 17.08.2007, 09:50 -0600 schrieb Peter Saint-Andre:
The following specs use storage:* namespaces:
[...]
XEP-0145: Annotations
http://www.xmpp.org/extensions/xep-0145.html
state: Historical / Active
[...]
I propose that we write new specs to replace XEP-0048
Hi, I am wondering why the RFC (3921, 11.1) specifies If two or more available
resources have the same priority, the server MAY use some other rule (e.g.,
most recent connect time, most recent activity time, or highest availability as
determined by some hierarchy of show/ values) to choose
cJ wrote:
Hi, I am wondering why the RFC (3921, 11.1) specifies If two or more
available resources have the same priority, the server MAY use some
other rule (e.g., most recent connect time, most recent activity
time, or highest availability as determined by some hierarchy of
show/ values) to
Peter Saint-Andre wrote:
Ralph Meijer wrote:
I know item identifiers must be unique, but I was saying here is that
the XEP doesn't specify that a server needs to generate unique ids if
the publisher doesn't provide one.
OK we need to clarify that, then.
On 17 Aug 2007, at 18:23, Peter Saint-Andre wrote:
Kevin Smith wrote:
On 17 Aug 2007, at 16:50, Peter Saint-Andre wrote:
I propose that we write new specs to replace XEP-0048 and XEP-0145
I don't really know what's wrong with 48 - it's deployed, it
works, and
once it's updated to the new
Hi,
A lot of these specs have seen quite radical change recently in
comparison to the 'lifetime' of the spec. Particularly the PEP CAPS
based specs.
There are others which are fairly new (xmpp ping, pep, caps, etc), or
lot of new changes have been added to them (pubsub, link local
Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote:
I agree. We have gotten some heat in goverment circles about the
draft status of xep45 and its dependencies.
I assume if we make a xep final that all of its dependencies must be
final?
That seems like the right approach.
Some of the
Peter Saint-Andre wrote:
Hi Mridul!
Mridul Muralidharan wrote:
Hi,
A lot of these specs have seen quite radical change recently in
comparison to the 'lifetime' of the spec.
If we don't try to push some of these forward, we never will. :)
+ 1 !
Naturally we won't try to do that until
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Hi Mridul!
Mridul Muralidharan wrote:
Particularly the PEP CAPS
based specs.
In fact PEP hasn't changed since last September, although the
documentation has changed. We should probably wait until is has been
more widely implemented
Version 0.6 of XEP-0189 (Public Key Publishing) has been released.
Abstract: This document specifies how an entity may publish its public keys
over XMPP.
Changelog: More clearly explained node creation and key publication workflows.
(psa)
Diff:
This may be of interest re: MUC.
- Forwarded message from Adam Roach [EMAIL PROTECTED] -
From: Adam Roach [EMAIL PROTECTED]
To: XCON-IETF [EMAIL PROTECTED], '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: [Simple] Chatroom Gap Analysis
As we discussed in Chicago, I have produced a gap
19 matches
Mail list logo
