: Re: [Simple] SIMPLE chat: Internationalization and
normalization of nicknames
Date: Thu, 01 Mar 2012 15:26:00 -0700
From: Peter Saint-Andre stpe...@stpeter.im
To: Ben Campbell b...@nostrum.com
CC: Simple WG sim...@ietf.org
On 3/1/12 3:12 PM, Ben Campbell wrote:
On Mar 1, 2012, at 3:55 PM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/28/12 11:28 PM, Gunnar Hellström wrote:
Returning to the initial question of this thread: Is there a common
way to indicate session start and session end.
Peter Saint-Andre skrev 2012-02-29 04:20:
Yes, but that doesn't necessarily mean you
because it describes another behavior of the
attribute and not switching it on or off.
Right. We need to define the configuration option for this.
Peter
--
Peter Saint-Andre
https://stpeter.im/
to change the status of XEP-0130 to Obsolete. If you have
any concerns about this action, please post to this list by March 16, 2012.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 2/28/12 1:56 AM, Sergey Dobrov wrote:
On 02/28/2012 06:36 AM, Peter Saint-Andre wrote:
On 2/27/12 12:36 AM, Sergey Dobrov wrote:
The other thing here is linking: atom:link needs attributes ref and
href, but href usually points to the atom feed at all and ref points
to the specific entry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/27/12 4:02 PM, Peter Saint-Andre wrote:
On 2/15/12 1:07 PM, Peter Saint-Andre wrote:
On 2/15/12 12:48 PM, Kurt Zeilenga wrote:
On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote:
I'd be willing to work on this, but I want to make sure
-0085. However, if we really really need
formal management then I would suggest using Jingle.
Peter
--
Peter Saint-Andre
https://stpeter.im/
provides a mechanism
for a client to detect whether the remote client has RTT support, before
transmitting outgoing unsolicited rtt.
Mark, the model you're searching for is what we use in XEP-0085. Please
take a look at the text there and see if you can re-use it for RTT.
Peter
--
Peter Saint
On 2/28/12 6:13 PM, Mark Rejhon wrote:
On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre stpe...@stpeter.im
mailto:stpe...@stpeter.im wrote:
On 2/28/12 4:47 PM, Mark Rejhon wrote:
[snip]
*Use Case Example #1:*
Alice messages Bob. Alice enables real-time text
On 2/28/12 7:33 PM, Mark Rejhon wrote:
On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre stpe...@stpeter.im
mailto:stpe...@stpeter.im wrote:
I'm suggesting that you use a model similar to XEP-0085 -- if the other
side advertises it (disco/caps), send the first message with some kind
Hi Florian!
On 2/28/12 7:42 PM, Florian Zeitz wrote:
Am 29.02.2012 03:02, schrieb Peter Saint-Andre:
On 2/28/12 6:13 PM, Mark Rejhon wrote:
*[To Discuss] Matter of negotiation of activation of RTT feature*
/However/, XEP-0085 doesn't answer the question of an appropriate
negotiation model
be mentioned in XEP-0301, and therefore
relevant discussion
Yes, but that doesn't necessarily mean you need an explicit negotiation
protocol.
Peter
--
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/15/12 1:07 PM, Peter Saint-Andre wrote:
On 2/15/12 12:48 PM, Kurt Zeilenga wrote:
On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote:
I'd be willing to work on this, but I want to make sure that
people think there's value in doing so
atom:id in
payload at all since it's confusing to have two identities that means
the same thing. How to address the entry then?
Thanks for your attentions, I hope that I was clear enough.
Have a good weekend, btw. :)
--
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As far as I have been able to determine, the technology defined in
XEP-0130 (Waiting Lists) is obsolete. I plan to raise the issue of
obsoleting the spec itself in the next XMPP Council meeting.
Peter
- --
Peter Saint-Andre
https://stpeter.im
development list j...@jabber.org
On Tue, Feb 14, 2012 at 3:54 AM, Peter Saint-Andre stpe...@stpeter.im
wrote:
Hallo Thijs,
On 1/4/12 10:26 AM, Thijs Alkemade wrote:
Hello,
As a client developer, I'm a bit confused about how XEP 0172 (User
Nickname) is intended to be used with MUCs. From the XEP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/17/12 4:50 AM, Sergey Dobrov wrote:
On 02/15/2012 11:52 PM, Peter Saint-Andre wrote:
Hi Sergey,
Hello again.
On 2/15/12 9:15 AM, Sergey Dobrov wrote:
So I suggest to add to 7.1.2 that client MUST always check if
service has changed
separately about XEP-0060.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk873LEACgkQNL8k5A2w/vyESgCg8yF0UCmUj4ByeRX5f4jrkmc7
Ar4AoIbq3BRwQN1Xaf2oUQP5rtLK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/15/12 9:35 AM, Dave Cridland wrote:
On Wed Feb 15 16:26:25 2012, Peter Saint-Andre wrote:
We have two really long specs: XEP-0045 and XEP-0060.
In the XMPP Council meeting just now, we talked about some ways
to shorten these documents
or setting a
resourcepart when logging in: the server has the right to change the
identifier that was provided by the user. So I think this is something
we should fix when we revise XEP-0060 later this year.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG
:38:27 2012, Peter Saint-Andre wrote:
a) I'd like to be able to have stable and working
copies of the same spec, particularly for major revisions
like XEP-0045 is currently going through.
I think this is a matter of best practices for how the spec
authors work, i.e., placing interim
On 2/15/12 5:01 AM, Dave Cridland wrote:
On Tue Feb 14 04:09:45 2012, Peter Saint-Andre wrote:
On 1/24/12 2:58 PM, Dave Cridland wrote:
I recall - ages ago - that we were going to, at one point, mention that
if you change your nickname, you should send unavailable persence after
the change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/15/12 12:48 PM, Kurt Zeilenga wrote:
On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote:
I'd be willing to work on this, but I want to make sure that
people think there's value in doing so.
Personally, I not sure what I hate more
slightly unrealistic, if
they haven't been doing it up till now.
Peter
--
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/7/12 10:56 PM, Curtis King wrote:
On 2012-02-07, at 6:10 PM, Peter Saint-Andre wrote:
At the XMPP Summit, I finally had a chance to chat with Kevin
Smith about XEP-0289, and on the plane back from Brussels I've
reviewed that spec in more
for free in
various libraries, so it might be worth a closer look.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 1/26/12 10:29 AM, Peter Saint-Andre wrote:
On 1/26/12 9:18 AM, Peter Saint-Andre wrote:
On 1/26/12 4:53 AM, Ben Langfeld wrote:
Gentlemen,
I believe I have found a minor bug in XEP-0166, as follows:
1) An example states that a security-required/ error element be
included in a response
behavioral implications (e.g., return an error if the
streams are not qualified consistently)?
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk850mcACgkQNL8k5A2w
cause such issues, nor am I the first person to have
such complaints :)
Sure, rant away! ;-)
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
nickname too - and will eventually have to send an unavailable
anyway.
Well, the server could do that immediately (when it accepts the nick
change), no?
Peter
--
Peter Saint-Andre
https://stpeter.im/
the XMPP Council
considers it for acceptance as a XEP?
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 2/10/12 2:59 PM, Matthew Wild wrote:
On 10 February 2012 21:09, Peter Saint-Andre stpe...@stpeter.im wrote:
On 2/10/12 12:01 PM, Kim Alvefur wrote:
On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote:
On 01/12/2012 01:41 AM, Kim Alvefur wrote:
On Tue, 2012-01-10 at 17:33 +0700, Sergey
from Waqas Hussain. Kev and Matthew,
please check this as co-authors to make sure that you think we're on the
right track.
Peter
--
Peter Saint-Andre
https://stpeter.im/
also need to provide clearer
documentation of ranged transfers (e.g., reusing the Jingle session ID).
Peter
--
Peter Saint-Andre
https://stpeter.im/
Closing the loop...
http://xmpp.org/about-xmpp/faq/
Peter
--
Peter Saint-Andre
https://stpeter.im/
it return any status at all?
- I don't mind the JID\20Escaping stuff for room names, but I suppose
others might consider it ugly
Kev, I'd be happy to work with you on improving XEP-0289.
Peter
--
Peter Saint-Andre
https://stpeter.im/
At the XMPP Summit just now, Florian Zeitz and Jonathan Schleifer
pointed out that XEP-0237 has actually been obsoleted by RFC 6121, so I
think we should make that official. Something to add to the Council
agenda.
/psa
Waqas, I've incorporated all of your feedback into the spec, and will
check it with my co-authors here at the XMPP Summit before pushing out a
revision.
On Fri, Dec 09, 2011 at 01:38:12AM +0500, Waqas Hussain wrote:
On Tue, Dec 6, 2011 at 3:32 AM, Peter Saint-Andre stpe...@stpeter.im wrote
in memory)
This module does not serve vcard4 queries (that would be part of
mod_vcard in Prosody trunk).
Thanks, Waqas. I'll read that on the flight to Brussels tomorrow. I hope
to install it at xmpp.net soon. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
#roomconfig_allowpm'
type='list-single'
label='Whether to Allow Occupants to Invite Others'/
»
seem to have the labels switched around. Additionally I think
muc#roomconfig_allowpm should be a list-multi.
Fixed in my working copy.
Thanks for the feedback!
Peter
--
Peter Saint-Andre
https
On 1/31/12 6:29 PM, Florian Zeitz wrote:
Am 01.02.2012 02:20, schrieb Peter Saint-Andre:
On 1/31/12 5:57 PM, Florian Zeitz wrote:
Hi everyone,
someone just pointed out to me that the current revision of XEP-45
prescribes JIDs to modify the moderator list. This seemed quite strange
to me
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8nH7UACgkQNL8k5A2w/vzSQwCffoBBmDnr+jJ3aOqrS6LF89AN
WpwAnA+1oPOYJ79N1NkK+1cd9dNu1HhL
=ld4P
-END PGP SIGNATURE-
.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 1/25/12 4:04 PM, Peter Saint-Andre wrote:
It may make sense to extend 210 to (2)
and (3).
That's the path I took based on your feedback (however, I notice that I
didn't add anything about status code 210 to the section on
user-requested nick changes, which is another time when
Snipping areas of agreement...
On 1/24/12 2:14 AM, Kevin Smith wrote:
On Mon, Jan 23, 2012 at 11:46 PM, Peter Saint-Andre stpe...@stpeter.im
wrote:
On 1/19/12 7:49 AM, Kevin Smith wrote:
Some comments, a couple of which predate the patch but most of which
are a consequence
the registration/ element.
There might be more elegant ways to do it, but this one seems acceptable
to me. Feedback is welcome. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 1/24/12 11:14 AM, Peter Saint-Andre wrote:
After jabbering with Kev for a bit, here's a follow-up on the status
code 210 issue (originally raised by Waqas Hussain).
If the user's nickname is modified by the service as a result of
registration and the user is in the room, the service SHOULD
On 1/24/12 2:22 PM, Kevin Smith wrote:
On Tue, Jan 24, 2012 at 6:14 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Snipping areas of agreement...
On 1/24/12 2:14 AM, Kevin Smith wrote:
not the nick (and thus implicitly the full JID) as with roles. -
isn't right, it's the nick
On 1/24/12 2:53 PM, Kevin Smith wrote:
On Tue, Jan 24, 2012 at 9:26 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 1/24/12 11:14 AM, Peter Saint-Andre wrote:
After jabbering with Kev for a bit, here's a follow-up on the status
code 210 issue (originally raised by Waqas Hussain).
I
double-checked all instances and it does seem that I did not
make this change consistently throughout the document. Fixed in my
working copy.
Peter
--
Peter Saint-Andre
https://stpeter.im/
spam angle because
it needs to be triggered by the room owner or admin.
With my Council hat on, *** are the things that I'd like to see
changed before publishing or at least for me to be shouted down on
(i.e. at least discussed and consensus reached).
See discussion above.
Peter
--
Peter Saint
snip/
For ease of tracking, I've checked in my working copy as 1.25rc11...
http://xmpp.org/extensions/tmp/xep-0045-1.25.html
http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc10/vs/1.25rc11
/psa
FYI.
Original Message
Subject: [Summit] deadline for FOSDEM talks
Date: Wed, 11 Jan 2012 10:31:27 -0700
From: Peter Saint-Andre stpe...@stpeter.im
Reply-To: XMPP Summit sum...@xmpp.org
To: XMPP Summit sum...@xmpp.org
If you'd like to give a talk in the XMPP devroom at FOSDEM
FYI regarding the upcoming meetings in Brussels. Please join the
sum...@xmpp.org list to discuss:
http://mail.jabber.org/mailman/listinfo/summit
Original Message
Subject: [Summit] Brussels discussion topics
Date: Mon, 09 Jan 2012 13:16:57 -0700
From: Peter Saint-Andre stpe
I've updated the Network Information Sharing (and renamed it) to
include a scenario about publishing such data, too:
http://xmpp.org/extensions/inbox/network.html
Continued feedback is welcome.
Peter
--
Peter Saint-Andre
http://stpeter.im/
On 1/9/12 2:23 PM, Peter Saint-Andre wrote:
I've updated the Network Information Sharing (and renamed it) to
include a scenario about publishing such data, too:
http://xmpp.org/extensions/inbox/network.html
I just pushed out version 0.0.3, adding an ad-hoc command for triggering
the presence
Noted. Thanks for the bug reports!
On 1/4/12 6:18 AM, Nobuo Ogashiwa wrote:
Dear all,
I found some typos in RFC6120 and XEP-220.
In RFC6120, I think that the word 'FDQN' should be 'FQDN'.
3. If a response is received, it will contain one or more
combinations of a port and FDQN,
On 12/29/11 8:22 PM, Ludovic BOCQUET wrote:
Le 09/12/2011 20:39, Peter Saint-Andre a écrit :
On 12/6/11 11:16 AM, Filipus Klutiero wrote:
Le 2011-12-06 12:22, Peter Saint-Andre a écrit :
On 12/6/11 10:18 AM, Filipus Klutiero wrote:
Le 2011-12-06 10:13, Peter Saint-Andre a écrit :
On 12/6/11
will run your owner server, you can call it whatever you'd like.
Peter
--
Peter Saint-Andre
https://stpeter.im/
For review...
On 12/13/11 4:54 PM, Peter Saint-Andre wrote:
On 12/13/11 10:21 AM, Matthew Wild wrote:
On 13 December 2011 17:01, Peter Saint-Andre stpe...@stpeter.im wrote:
On 12/13/11 8:48 AM, Peter Saint-Andre wrote:
On 12/12/11 1:52 PM, Kim Alvefur wrote:
On Mon, 2011-12-12 at 12:43 -0700
this up early in the new year so that I can
move on to cleaning up XEP-0060. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
judge
a message type by the namespaces of its immediate children.
Shades of XEP-0226, eh?
http://xmpp.org/extensions/xep-0226.html
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 12/8/11 3:36 PM, Peter Saint-Andre wrote:
Have any server or client developers here considered adding support for
the emerging SASL mechanism for OAuth?
http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth
That would seem to open up some interesting authentication possibilities
(e.g
that
this too could use with some clarification in 6121bis.
Thanks for the feedback!
Peter
--
Peter Saint-Andre
https://stpeter.im/
Done. Updated XEP to be published shortly...
On 9/26/11 11:38 AM, Peter Saint-Andre wrote:
After last week's XMPP Council meeting, a few folks had a discussion
about MUC status codes (XEP-0306)...
http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110921/#16:22:29
Ralph Meijer's point
haven't had time to work on
XEP-0248 in quite a while.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 12/12/11 1:52 PM, Kim Alvefur wrote:
On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote:
XEP-0077 (In-Band Registration) does not define a disco feature for
advertising support for jabber:iq:register. I have a use case in which
this would be very handy.
I'm pretty sure
On 12/13/11 8:48 AM, Peter Saint-Andre wrote:
On 12/12/11 1:52 PM, Kim Alvefur wrote:
On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote:
XEP-0077 (In-Band Registration) does not define a disco feature for
advertising support for jabber:iq:register. I have a use case in which
On 12/13/11 10:21 AM, Matthew Wild wrote:
On 13 December 2011 17:01, Peter Saint-Andre stpe...@stpeter.im wrote:
On 12/13/11 8:48 AM, Peter Saint-Andre wrote:
On 12/12/11 1:52 PM, Kim Alvefur wrote:
On Mon, 2011-12-12 at 12:43 -0700, Peter Saint-Andre wrote:
XEP-0077 (In-Band Registration
for it to send presence to B until A logs in again.
I think we might have a failure of communication here. Could you explain
your question in a bit more detail?
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 12/10/11 2:18 AM, Kim Alvefur wrote:
I had some thougts about using PEP in combination with this for
sharing things like peer server certs seen, and incident reports.
My current plan is to use this as the basis for automating data
gathering for http://xmpp.org/resources/public-services/
XEP-0077 (In-Band Registration) does not define a disco feature for
advertising support for jabber:iq:register. I have a use case in which
this would be very handy. Any concerns about adding this to XEP-0077?
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 12/12/11 2:10 PM, Kim Alvefur wrote:
On Mon, 2011-12-12 at 20:36 +, XMPP Extensions Editor wrote:
Changelog: Updated ad-hoc command with field for the sending server;
added XMPP Registrar Considerations. (psa)
What about the 'to' attribute of the iq/ ?
I suppose that might do it...
what you mean by schema checking?
Ciao
Hannes
On Dec 9, 2011, at 8:10 PM, Peter Saint-Andre wrote:
In addition, I know of at least one large deployment community that
performs active schema-checking for XMPP traffic. Those folks would like
it if our schemas were normative, I'd bet. :)
On 12/9/11 9:24 AM, Dave Cridland wrote:
On Thu Dec 8 23:13:38 2011, Matthew A. Miller wrote:
I'd like to point out that all of our XML Schemas are non-normative.
They're provided for informational use, and ought not be considered
the absolute record of authority.
What follows is my
On 12/9/11 9:46 AM, Dave Cridland wrote:
On Fri Dec 9 16:44:23 2011, Peter Saint-Andre wrote:
On 12/9/11 9:24 AM, Dave Cridland wrote:
On Thu Dec 8 23:13:38 2011, Matthew A. Miller wrote:
I'd like to point out that all of our XML Schemas are non-normative.
They're provided
FYI (this has an impact on XEP-0068).
Original Message
Subject: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt
Date: Fri, 09 Dec 2011 17:19:10 +
From: Alexey Melnikov alexey.melni...@isode.com
To: apps-disc...@ietf.org apps-disc...@ietf.org
Dear WG participant,
I
were normative, I'd bet. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
again when thinking about XEP-0300 recently.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 12/6/11 11:16 AM, Filipus Klutiero wrote:
Le 2011-12-06 12:22, Peter Saint-Andre a écrit :
On 12/6/11 10:18 AM, Filipus Klutiero wrote:
Le 2011-12-06 10:13, Peter Saint-Andre a écrit :
On 12/6/11 6:34 AM, Kim Alvefur wrote:
On Tue, 2011-12-06 at 01:50 -0500, Filipus Klutiero wrote:
Hi
Jefry has sent me a patch. I'll work to process it soon.
On 11/28/11 3:07 PM, Jefry Lagrange wrote:
Thanks for your response. ;-)
I'm not sure it's a good idea to overload the disco request this way.
Perhaps having the filter in a separate namespace would be ok, but I
think perhaps it would
Needless to say, this person has been modded.
On 12/8/11 5:51 AM, wang chun wrote:
*From wang chun*
engineer at Trident MultiMedia
China
I'd like to add you to my professional network on LinkedIn.
- wang
--
Peter Saint-Andre
https://stpeter.im/
is still
online), but now I'm not so sure. Something to revisit when working on
6121bis. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
but no protocol based on it is not distinguishable from a client that
does not support PEP at all.
Agreed.
XEP-0292 has some PEP features in there, but we probably can't require
that until 2013 or 2014 (although I'd like to kill off vcard temp as
soon as possible).
Peter
--
Peter Saint-Andre
modified MIT license. The licensing used by the logo designer is
irrelevant, since the XSF paid for the logo and can put it under
whatever license it prefers.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 12/6/11 10:18 AM, Filipus Klutiero wrote:
Le 2011-12-06 10:13, Peter Saint-Andre a écrit :
On 12/6/11 6:34 AM, Kim Alvefur wrote:
On Tue, 2011-12-06 at 01:50 -0500, Filipus Klutiero wrote:
Hi,
is XMPP's logo licensed? Apparently a free license would help including
it on Wikipedia ( http
your own thinking about how useful
(or not useful) XEP-0300 is.
Peter
--
Peter Saint-Andre
https://stpeter.im/
I'm at the IETF meeting in Taipei this week so I don't have time to look
into this, but I might have time on the plane home Saturday, or for sure
early next week.
On 11/16/11 2:22 AM, Dave Richards wrote:
Am I missing something or is there a bit of a hole in these sections
regarding denying a
FYI for those of you who don't follow the coun...@xmpp.org list (yes,
anyone can subscribe), there's an XMPP Council meeting later today.
Original Message
Subject: Re: [Council] Agenda
Date: Wed, 09 Nov 2011 06:35:54 -0700
From: Peter Saint-Andre stpe...@stpeter.im
Reply
be displayed to the user, which would seem to
suggest internationalization is necessary here.
XMPP is an XML technology, thus xml:lang is allowed on any element.
Naturally, we could add an example of that to XEP-0030.
Peter
--
Peter Saint-Andre
https://stpeter.im/
Council discussed this matter in its meeting today and approved
the change, so I'll publish the revised spec and schema sometime soon.
Peter
--
Peter Saint-Andre
https://stpeter.im/
Updated per list discussion...
Rendered:
http://xmpp.org/extensions/tmp/xep-0045-1.25.html
Last diff:
http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc7/vs/1.25rc8
Diff from 1.24:
http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc8
/psa
.
XEP-0045 doesn't cover service-global features. We've always said we
might write a spec about that, though.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 10/5/11 2:11 PM, Mike Wacker wrote:
On 10/4/2011 10:14 AM, Peter Saint-Andre wrote:
On 10/3/11 5:11 PM, Mike Wacker wrote:
Hello,
One of the tenets of XEP-0045 is backwards-compatibility with groupchat
1.0.
Additional features do not necessarily introduce incompatibility. The
old
On 10/27/11 2:54 PM, Bala Pitchandi wrote:
The DTD in section 9 http://xmpp.org/extensions/xep-0054.html#dtd
mandates that the element vCard must contain VERSION, FN, N but the
examples in section 3.1 do not comply. Particularly the vCard retrieval
request (Section 3.1, example 1) has an empty
On 10/27/11 2:59 PM, Bala Pitchandi wrote:
Which is correct?
RFC 6121 is correct.
On 10/27/11 3:06 PM, Bala Pitchandi wrote:
So does that mean, a XMPP client implementation MUST add a presence
subscriber to its roster, if it wants to keep track of its
watchers?
Yes. XMPP's presence and subscription model is different from SIP's. You
will need to change your way of thinking
On 10/27/11 3:03 PM, Bala Pitchandi wrote:
The implementation note (pasted below) does not say that VERSION
element is optional:
Some Jabber implementations add a 'version' attribute to the vCard/
element, with the value set at 2.0 or 3.0. The DTD is incorrect,
and the examples in
On 10/27/11 3:19 PM, Bala Pitchandi wrote:
I agree with you on xCard/XEP-0292. I would rather implement that
than implementing XEP-0054 but like you said no one (*cough* Google
*cough*) has implemented it yet.
To be fair, vCard4 is new. But we need to figure out how to bootstrap
701 - 800 of 2693 matches
Mail list logo
