3. Web team
CommTeam manages website repo, iTeam and board also have permissions
4. AOB
Mediawiki upgrade for iTeam
5. Date of Next
+1W
ralphm bangs gavel at 16:05
Logs: https://logs.xmpp.org/xsf/2019-11-14#2019-11-14-36b0069be768e993
--
Nicolas Vérité (Nÿco)
ᐧ
to poll the wider standards community and/or jdev. Maybe.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ________
nfo: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
--
Nicolas Vérité (Nÿco)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
5, really, we should be referring
> to the (deliberately) "Marketing" terms of "Core Server 2017" and so
> on - that's why we created those terms. These need links on the
> website directly into the document, and perhaps some user
> documentation around them.
>
Yes, it
re out a
> different way, I'm happy to let them work on it instead.
>
> —Sam
>
Once again, trying to clarify the discussion:
* still keep and apply the XEP process (it’s awesome)
* make it easier to discover and adopt
--
Nicolas Vérité (Nÿco)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
they have apparently the same approach: offering border gateway,
to their internal chat system, still running on proprietary protocol.
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
On Wed, Sep 14, 2011 at 20:52, Peter Saint-Andre wrote:
> On 9/14/11 12:49 PM, Dave Cridland wrote:
>> Running some
>> interop tests
>
> Perhaps it's time for another online interop test?
Perhaps it's time to go further than these interop tests?
--
Nicolas V
s, it lets the communities booh the cheaters.
I think it's the most important task we have now.
What is your opinion?
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
ender/xep-correct.html
> Discussion welcome.
Additionally, we can also forbid, or deeply advice to forbid, message deletion.
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
to
edit everything every time
** users do not trust the client, nor the contact
** lots of unwanted side-effects in histories and logs
** uncompatible clients suffer
** etc.
If it does not appear as mandatory in the XEP, it needs at least to be
strongly adviced.
> On 3/25/11, Nicolas Vérité wr
On Fri, Mar 25, 2011 at 17:01, Florian Zeitz wrote:
> Am 25.03.2011 16:48, schrieb Kevin Smith:
>> On Fri, Mar 25, 2011 at 3:41 PM, Nicolas Vérité
>> wrote:
>>> On Fri, Mar 25, 2011 at 16:30, Kevin Smith wrote:
>>>> On Fri, Mar 25, 2011 at 2:53 PM, Nicolas Vé
wouldn't mind
>> recommendations, though.
>>
>> As long as the client indicates that a message has been edited X times
>> (and provides the original message), i don't really see any issues.
>>
>> cheers,
>> Remko
>>
>
> --
> Sent from my mobile device
>
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
On Fri, Mar 25, 2011 at 16:30, Kevin Smith wrote:
> On Fri, Mar 25, 2011 at 2:53 PM, Nicolas Vérité
> For only one edit, I'm not sure this is necessary for interop (and
> therefore to include in the spec) - but clients are free to not render
> an edit as an edit if they feel t
ture? What user have said about it?
Don't forget that we are in the proces of allowing to modify (a) past
message(s)... it is a huge trickery concern.
Also, what do you want to do with encrypted messages?
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
On Fri, Mar 25, 2011 at 15:59, Peter Saint-Andre wrote:
> On 3/25/11 8:53 AM, Nicolas Vérité wrote:
>
>> Just one common feedback from our most technical users:
>> we should:
>> 1/ forbid the edition/correction of other messages than the last
>> 2/ authorize the c
On Fri, Mar 25, 2011 at 15:46, Kevin Smith wrote:
> On Fri, Mar 25, 2011 at 2:43 PM, Nicolas Vérité
> wrote:
>> On Tue, Jul 20, 2010 at 11:19, Kevin Smith wrote:
>>> Following a discussion in jdev, I've thrown together the skeleton of a
>>> XEP for correctin
itution string à la vi (s/wrong/right/). It can be
considered a fallback to this XEP. So we are ready to implement it.
Can we advance this XEP?
Regards
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
network such as 3G.
>
> Changelog: Initial published version. (psa)
>
> Diff: N/A
>
> URL: http://xmpp.org/extensions/xep-0286.html
>
>
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.
cial-look-face-time-part-1.html
http://www.packetstan.com/2010/07/special-look-face-time-part-2-sip-and.html
http://www.packetstan.com/2010/07/special-look-face-time-part-3-call.html
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.or
roposal:
>>
>> http://xmpp.org/extensions/inbox/sxe.html
>>
>> At its next meeting, I will ask the XMPP Council to consider accepting
>> this as an official XEP.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>>
>
>
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
;
> Unfortunately we still need to think about SIP deployment compatibility.
STUN? (joking... ;-) )
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
nyway, though)
> The IQ request is nice and current I make use of it, for several other
> reasons like throttle, network profile etc...
Can you please detail that?
> I'm happy with the current one, if major servers have that. would
> already be a great first step.
>
> Regards,
On Fri, Mar 12, 2010 at 14:02, Matthew Wild wrote:
> On 12 March 2010 10:37, Nicolas Vérité wrote:
>> On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor wrote:
>>> Version 0.1 of XEP-0279 (Server IP Check) has been released.
>>>
>>> Abstract: This specifica
ult in feature-not-implemented, but are still
delivered. I believe any first message chat/headline is delivered to
all resources disregarding the priorities.
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
x-type
>
> * headline -- [...] The receiving server SHOULD deliver the message to all
> of the recipient's available resources.HTH,
It will not be an offline message though, right?
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
shed version. (psa)
>
> Diff: N/A
>
> URL: http://xmpp.org/extensions/xep-0279.html
I am not quite also what would happen with BOSH: if there's separate
BOSH CMs and/or reverse proxies in the middle...
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
ly
address your need:
http://xmpp.org/extensions/xep-0033.html
Also I'm not sure, but if you control all your client connections, you
might want all resources to connect with the same priority (dirty
hack?).
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
e inside an iq, but at the stream level.
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
discover its external IP address.
>>
>> Changelog: Initial published version. (psa)
>>
>> Diff: N/A
>>
>> URL: http://xmpp.org/extensions/xep-0279.html
>
> Why not use STUN?
Am I mistaking, or this question has not been answered on this thread?
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
XEP, then
what CAN/SHOULD/MUST clients and/or servers implement then? STUN
and/or SIC?
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
On Mon, Mar 8, 2010 at 13:36, Kevin Smith wrote:
> On Mon, Mar 8, 2010 at 11:28 AM, Nicolas Vérité
> wrote:
>> Clients:
>> I believe most clients, if no all, support XEP-0049. I believe only a
>> few clients support bookmarks over XEP-0223 (I don't know of any).
>
, support XEP-0049. I believe only a
few clients support bookmarks over XEP-0223 (I don't know of any).
Servers:
I believe too few servers support PubSub. I believe none supports HTTP/WebDAV.
Any best practice or hint? Or w're stuck on a historical XEP?
--
Nicolas Vérité - ProcessOne
http
that completely mimics the IRC-styme anonymosity and channels (no
one-to-one chat, no presence, no roster, etc.):
http://codingteam.net/project/poezio
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
things are linked, so it's hard to reduce complexity to handle
>> all cases.
>
> I've come to that conclusion, too, but I was hoping you could provide a
> new perspective. :)
Why not adding more complexity... to archive also Jingle calls, and
file transfers?
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
n for RFC3020bis.
Thx
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/
http://xmpp.org - http://april.org/ - http://qsos.org/
ion of the XEPs?
>> Sure it's possible, the question is whether we want it.
>
> I think we do.
Yes, the indentation is fine, and well documented.
However, my eyes are not trained enough when code is monocolor. But
they thank me when I read the PDF's code ;-)
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
; We're still working out a few glitches here and there, so your feedback
> is appreciated.
Since I don't have a clue, I'm asking here:
color coding rocks, would that be possible to have the same color code
in the XHTML version of the XEPs?
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
the other hand, maybe it's not useful to list the lesser-known
ones, like Jaiku, Pownce, Yahoo! Meme, Yammer, Plurk, Present.ly,
Tumblr... Non-exhaustive list, of course.
What do you think of it?
Regards
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
ou get your geographical coordinates from?
IMHO no, and that's the point.
In the XEP, we only use GPS.
Do we want to be it:
- exhaustive (and add, GSM, wifi, etc.)
- technology-agnostic (and remove GPS)
?
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
se
>>>> Jira for that. Want to help set it up? :)
>>>
>>> I've just set Jira up at work, I'm happy to give it a go if you want.
>>
>> Sure, sounds good. Thanks!
>>
>> Peter
>>
>
> I'd also be glad to help, in case there
geolocation technologies, like GSM (cell-id) and wifi (less
accurate).
Should we still stick to GPS only? Or be GPS-independant?
Should we add some fields to reflet the different other technologies?
Will new ones appear in the future? (highly probable?)
Regards,
Nÿco
--
Nicolas Vérité - ProcessOne
be strict, we could write a specific mechanism that says
how to send and handle received keepalives, but it will be
resource-consuming...
Regards.
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
Dear all,
In the "Security considerations" section of the PubSub spec, shouldn't
we warn of the possible presence leaks, since subscribers (possibly
not in the user's roster) are instantly notified of a user's
publication?
Regards,
Nÿco
--
Nicolas Vérité - ProcessO
e role of the XSF to put up such a service?
Regards.
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
Hi,
In http://xmpp.org/extensions/ there is a link to
http://xmpp.org/extensions/inbox/ which points to non-yet XSF XEP.
Some of them are waiting for approval, but some of them are
abondonned: could we move them to a
http://xmpp.org/extensions/abadonned/ directory?
Thx
Nÿco
--
Nicolas Vérité
What about that small proposed change?
On Mon, May 25, 2009 at 11:31 AM, Nicolas
Vérité wrote:
> Hi,
From:
> "The sending of such a space character is called a WHITESPACE PING."
To:
> "The sending of such a whitespace is called a WHITESPACE KEEPALIVE."
--
Nic
t to loss of connection).
>
My point was the spec RFCbis: how should we update it?
Apparently, the whitespace keepalive is used in Psi and Gajim as a sending
entity, at least, and maybe in other clients, especially mobile ones, I
don't know for the server-side behaviour(s).
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
, i.e., any instance of SP, HT, CR, and LF."
Thus I propose this change:
"The sending of such a whitespac is called a WHITESPACE KEEPALIVE."
What do you think ot it?
Regards
--
Nicolas Vérité - ProcessOne
http://process-one.net
Mobile: +33 6 20 88 63 04
OULD
be such that they come first in the privacy list."
Is it a question of message, presence (in/out) or iq? Or all stanza types?
Nÿco
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabbe
Multiple elements MAY be included, each with a different
'xml:lang' value.
Proposal:
Multiple elements MAY be included, each MUST have a different
'xml:lang' value.
Nÿco
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - h
Hi,
There are small typos in XEP-0050: Ad-Hoc Commands:
http://xmpp.org/extensions/xep-0050.html
:%s/X-Windows/X-Window/g
http://en.wikipedia.org/wiki/X_Window_System
;-)
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - http
On Tue, Apr 14, 2009 at 15:56, Peter Saint-Andre wrote:
> On 4/14/09 3:36 AM, Jiří Zárevúcký wrote:
>> 2009/4/14 Nicolas Vérité :
>>
>>> In 5th bullet point, I propose a change to
>>> "The attention extension MUST NOT use stanzas, since use this
&
2009/4/14 Jiří Zárevúcký :
> 2009/4/14 Nicolas Vérité :
>> In 3rd bullet point of section 4,
>> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
>> receive a delayed 'attention', though I propose the change from MUST
>> to SHOULD.
>
&g
5th bullet point, I propose a change to
"The attention extension MUST NOT use stanzas, since use this
feature is part of the conversation."
Regards,
Nÿco
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - http://fr.w
On Thu, Mar 19, 2009 at 5:51 PM, Peter Saint-Andre wrote:
> FYI, last night I adjusted the XEP boilerplate so that it shows a bit
> more information at the top. Load any XEP to see.
>
> Peter
Clean and synthetic, I like it! Thx!
I don't see anything to add/remove...
Nÿco
-
about cutting
and restrcturing all the info in User Profile in different PEP stuff?
Like the user's relationships, projects, resume...
I evoked the subject in:
http://mail.jabber.org/pipermail/standards/2009-March/021218.html
Nÿco
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber I
just an
> avatar :).
>
> This might actually work in some clients out of the box.
Or "MUC Profile"? Like "User Profile"?
Nÿco
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adhérez à l'April : http://april.org/
Hi,
I was just wondering...
Is it possible/easy/XEPable to have an image/avatar/logo that symbolizes a MUC?
Just a funny wannabe gadget... though no doubt a killer-feature for some.
Nÿco
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http
d parts of User Profile.
Nÿco
--
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr
http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/
Hi,
FYI, here is the "Liberty Alliance ID-SIS 1.0 Specifications":
http://www.projectliberty.org/resource_center/specifications/liberty_alliance_id_sis_1_0_specifications
This deals with XMPP for presence, I don't know anything else.
Nÿco
--
Nicolas Vérité (Nÿco) mailto:[
thing I overlooked?
>
> --
> Jonathan
It's still in inbox (no XEP number):
http://xmpp.org/extensions/inbox/xtls.html
Nÿco
--
Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED]
Jabber ID : xmpp:[EMAIL PROTECTED]
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adhérez à l'April : http://april.org/
serid=16911
> View this thread: http://www.jabberforum.org/showthread.php?t=1073
>
>
--
Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED]
Jabber ID : xmpp:[EMAIL PROTECTED]
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Adhérez à l'April : http://april.org/
: it is not accessible for the blinds or
visually impaired. We need more printed text (meta)data.
Nÿco
--
Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED]
Jabber ID : xmpp:[EMAIL PROTECTED]
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
xt releases, as maybe some other people. So the wiki is a place
where to contribute.
Nÿco
--
Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED]
Jabber ID : xmpp:[EMAIL PROTECTED]
http://linuxfr.org/ - http://fr.wikipedia.org/ -
http://www.jabberfr.org/ - http://qsos.org/
Hi all,
I think you have all heard about the OpenSocial buzz...
Do some of you consider making XMPP compatible/interoperable
with this API? Is it useful/necessary/worth?
Nÿco
--
Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED]
Jabber ID : xmpp:[EMAIL PROTECTED]
http://linuxfr.org/ - http
On 10/22/07, Remko Tronçon <[EMAIL PROTECTED]> wrote:
> Why would they want to modify RFCs?
To "embrace and extend"? (and extinguish)
--
Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED]
Jabber ID : xmpp:[EMAIL PROTECTED]
http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/
66 matches
Mail list logo
