Ralph Meijer wrote:
Hi,
Not sure where to inject this, so this is as good as any other place.
On Thu, 2007-05-31 at 10:05 -0600, Joe Hildebrand wrote:
On May 31, 2007, at 9:21 AM, Ian Paterson wrote:
Actually, once PEP starts to be more deployed (hopefully later
this year), I'd like to
404 ?
http://www.xmpp.org/registrar/alt-connections.html
Hmm there must be an error in my scripts or practices somehow...
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
In today's meeting of the XMPP Council we discussed whether the
specifications we will use for the 2008 certification program (i.e.,
XEPs 211 and 212) should refer to rfc3920bis and rfc3921bis (the
in-progress revisions to RFCs 3920 and 3921, a.k.a. the bis drafts).
Here is my take:
PRO
The
Adam Nemeth wrote:
On 6/11/07, Olivier Goffart [EMAIL PROTECTED] wrote:
And i would even put the body element in the root of the message
element. So
even client that doesn't support pubsub can receive such message
Hmm... I disagree here a bit, but of course, you're the developer, so
the
'
id='retrieve1'
Copy-and-paste error. :)
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
in favor of making life easier for coders.
What do others think?
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
people are happy with it and continue to use it.
Agreed. I have not seen a great deal of demand for this since people
seem happy enough with vcard-temp. But vcard-temp has a lot of problems
in theory and has been temp since 1999. Maybe it's time for something
better. :)
Peter
--
Peter Saint
Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Btw, are we not moving to using the stream feature instead of the db
namespace in the stream to advertise dialback ?
In which case, we could just deprecate both use of the namespace, and
support for dialback
Plus it helps us remove 15+ pages from rfc3920bis, which is getting
quite long with all the examples I've added.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
Michal 'vorner' Vaner wrote:
Hello
On Fri, Jun 22, 2007 at 03:07:05PM -0600, Peter Saint-Andre wrote:
Currently, the XML schema for the jabber:iq:roster namespace does not
limit the length of an item name or a group name. I think that might
cause problems. In particular I think it might
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Forgot to add, change name from ver ext to verh and exth ?
Why?
Conflict with existing clients - too many of them in the wild dont use
these semantics.
But introducing new attributes is backward
Chris Mullins wrote:
That verbage makes the answer clear. Thanks!
I'm not in the habit yet of checking the bis revisions of the specs.
I'll have to change that, and make it my starting point.
Good idea. In general, the bis specs incorporate errata, corrections,
clarifications, and a lot
Mridul wrote:
Joe Hildebrand wrote:
On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Forgot to add, change name from ver ext to verh and exth ?
Why?
Conflict with existing clients - too many of them in the wild dont use
Rachel Blackman wrote:
That said, I think we can come up with some simpler logic. If a given
token is prefixed with 'h$', for instance, we know it's a hash and
should be both validated against the result, and -- if it matches --
cached globally instead of per-client. But for backwards
Michal 'vorner' Vaner wrote:
Hello
On Tue, Jul 03, 2007 at 09:18:59AM -0600, Joe Hildebrand wrote:
hash='MD5'
and make it mutually-exclusive with ext.
Why exclusive? ext for the old clients, hash to check if it makes sense?
caps:c node='client' ext='f1 f2 f3' hash='the-hash'/
Or
Joe Hildebrand wrote:
I just talked to stpeter IRL (he's all of 10 feet from me; should have
done that first thing this morning!),
I just measured. It's 15 feet. :P
and made sure he understood what I
was after. I'm replying to Rachel's mail, since it hits on the two (in
my mind) remaining
Daniel Noll wrote:
Someone poked me about adding the following activity to XEP-0108:
talking/on_video_phone
Which seems reasonable and I'm happy to add it to the spec. But it
strikes me that we might just want to have a registry for this kind of
thing, eh? :)
A registry would be nice,
Ian Paterson wrote:
Mridul wrote:
So queries for both bare jid and ns#ver will be supported (and return
the same value) ? And all clients using newer spec would use bare jid I
suppose ? (so that we can deprecate ns#ver and remove this in the future)
Yes.
But we do lose ability to
Joe Hildebrand wrote:
On Jul 4, 2007, at 5:35 AM, Ian Paterson wrote:
'ext' and pre-defined sets only improve security if the choice of a
weak hash makes pre-image attacks possible. So why don't we make
things easier for everyone and simply recommend a stronger hash instead?
So, to pull
I not just set DND while on a video call?
XEP-0108 is for things that are much more granular than showdnd/show.
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
We still need to figure out private storage via pubsub. Joe Hildebrand
proposed that we tack +private on the end of the namespace (NodeID):
http://mail.jabber.org/pipermail/standards/2007-March/014758.html
Rephrasing and generalizing his email based on subsequent list
discussion, I would present
Tomasz Sterna wrote:
Dnia 27-06-2007, śro o godzinie 16:50 -0600, Peter Saint-Andre
napisał(a):
So I propose the following text:
A server MUST ignore any 'to' address on a roster set, and MUST
treat any roster set as applying to the sender. A server MUST
NOT include a 'from
Tomasz Sterna wrote:
Dnia 05-07-2007, czw o godzinie 16:31 -0600, Peter Saint-Andre
napisał(a):
Now, a 'from' address of the full JID seems odd to me. What if I send
an IQ-set from one of my resources to another? Does that mean I can do
roster pushes directly from one resource to another
Daniel Noll wrote:
On Friday 06 July 2007 09:00, Peter Saint-Andre wrote:
Robin Redeker wrote:
And I think announcing capabilities seems to be a great application
of PEP/PubSub. I can already imagine the client setting:
PEP depends on XEP-0115. Circular dependencies seem like a bad idea
Andreas Monitzer wrote:
On Jul 06, 2007, at 17:55, Peter Saint-Andre wrote:
Isn't not-authorized an iq result, and thus not applicable for a message
stanza?
If the message contains only the attention element (as it certainly
should), then the recipient can simply ignore it. It's
Rachel Blackman wrote:
How do other services implement this kind of poke feature? I assume in
the UI you can right-click or whatever to choose poke stpeter and your
client sends this special message off to me. I think it's less likely
that you'd send a message (hey pay attention!) with the
Ian Paterson wrote:
Peter Saint-Andre wrote:
Whenever a client publishes the first item to a node that ends in
+[accessmodel], the pubsub service MUST create the node with a default
access model equal to the specified model (that is open or presence
or roster or authorize or whitelist). [1
-rfc3920bis-03.html
http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-03.html
Thanks!
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
respects except those specified in the
preconditions (in this case, the node would be created with an access
model of whitelist) and the publish succeeds.
Correct?
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME
Mridul Muralidharan wrote:
Whether to autocreate or to return error saying node does not exist
(item-not-found) - can this be an implementation detail ? That is, are
clients expected to handle the error path too and explictly create ?
We do not have auto create in pubsub iirc (not sure if
it may be the best
we can do.
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
Ian Paterson wrote:
Peter Saint-Andre wrote:
We already have one such solution/hack in PEP: the +notify
namespaces used in entity capabilities to signal that a subscriber wants
to receive notifications related to a given namespace. Your suggestion
of +whitelist (etc.) is in the same spirit
Ian Paterson wrote:
Peter Saint-Andre wrote:
So we'd have something like this:
iq from='juliet at capulet.com/balcony' type='set' id='foo'
pubsub xmlns='http://jabber.org/protocol/pubsub'
publish node='http://jabber.org/protocol/activity'
item
activity xmlns='http
in the RFCs, however.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Peter Saint-Andre wrote:
http://www.xmpp.org/extensions/tmp/xep-0004-2.9.html
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0004.xml?r1=851r2=1031
We had a discussion [1] about ordering of items in the jdev room today
so I've made an adjustment [2] to clarify that as well.
/psa
Based on a message I received off-list, I've provisionally made one
clarification and one correction to XEP-0077 (In-Band Registration):
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0077.xml?r1=535r2=1032
http://www.xmpp.org/extensions/tmp/xep-0077-2.3.html#usecases-cancel
/psa
I've made a first pass at updating XEP-0115 (Entity Capabilities) in
line with recent list discussion:
http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=742r2=1035
Feedback is welcome as always.
Peter
--
Peter Saint
Ian Paterson wrote:
Peter Saint-Andre wrote:
I've made a first pass at updating XEP-0115 (Entity Capabilities) in
line with recent list discussion:
This looks like a good first pass.
- In section 1.2 How it Works:
1. If Benvolio is publishing caps with a different 'node
http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html
Diff from 1.4pre1:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1035r2=1037
Diff from 1.3:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1037r2=742
Version 1.3 is archived here:
Ian Paterson wrote:
Peter Saint-Andre wrote:
Ian Paterson wrote:
- In section 1.2 How it Works:
1. If Benvolio is publishing caps with a different 'node' but the same
'ver' then I don't need to perform another disco#info. So can you make
that clear from the very outset by giving Benvolio
FYI
Original Message
Date: Wed, 11 Jul 2007 12:16:30 -0600
From: Peter Saint-Andre [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Jabber-ID: [EMAIL PROTECTED]
Subject: [Council] meeting minutes, 2007-07-11
Results of the XMPP Council meeting held 2007-07-11...
Agenda:
http
Tobias Markmann wrote:
I just noticed that it doesn't define whether duplicates are allowed in
jid-multi or not either.
What's the point of duplicates? IMHO the jid-multi field SHOULD NOT
include duplicates and duplicates MUST be ignored.
/psa
smime.p7s
Description: S/MIME Cryptographic
Peter Saint-Andre wrote:
Tobias Markmann wrote:
I just noticed that it doesn't define whether duplicates are allowed in
jid-multi or not either.
What's the point of duplicates? IMHO the jid-multi field SHOULD NOT
include duplicates and duplicates MUST be ignored.
http://svn.xmpp.org:18080
Dave Cridland wrote:
On Wed Jul 11 15:59:39 2007, Peter Saint-Andre wrote:
http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html
This looks good.
For maximum pedantry, you might note that the base64 encoding used MUST
NOT contain whitespace (which RFC 4648 says is the default anyway
The following XEPs have been inactive for 6+ months and therefore are
subject to automatic deferral. If you have an interest in these specs,
please speak up.
XEP-0150: Use of Entity Tags in XMPP Extensions
http://www.xmpp.org/extensions/xep-0150.html
XEP-0151: Virtual Presence
Andreas Monitzer wrote:
On Jul 13, 2007, at 20:54, Peter Saint-Andre wrote:
The following XEPs have been inactive for 6+ months and therefore are
subject to automatic deferral. If you have an interest in these specs,
please speak up.
XEP-0154: User Profile
http://www.xmpp.org
://www.xmpp.org/extensions/xep-0195.html
XEP-0196: User Gaming
http://www.xmpp.org/extensions/xep-0196.html
XEP-0197: User Viewing
http://www.xmpp.org/extensions/xep-0197.html
Maybe we can interest the Atom community in extensions for this kind of
thing.
Peter
--
Peter Saint
Ian Paterson wrote:
Peter Saint-Andre wrote:
The following XEPs have been inactive for 6+ months and therefore are
subject to automatic deferral. If you have an interest in these specs,
please speak up.
XEP-0154: User Profile
http://www.xmpp.org/extensions/xep-0154.html
Now
Regarding XEP-0176 and those who say ICE isn't implemented anywhere so
how can we use it in XMPP?
Original Message
From: Kai Vehmanen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 17 Jul 2007 15:27:53 +0300
Organization: Nokia
Subject: [MMUSIC] open-source ICE
Tony Finch wrote:
Following a discussion on the ejabberd list, I've noticed that XEP 178
makes no mention of certificates being presented by the target of a
connection and verified by the source of the connection, as is usual. I
guess that this is a mistake, since it is omitted for both c2s
At http://mail.jabber.org/pipermail/standards/2007-July/015878.html and
other messages in that thread, we talked about a kind of publishing an
item only certain preconditionsn are met. Ralph Meijer mentioned that we
could broaden this to include publish-options other than preconditions:
FYI, the latest provisional versions are here...
1. XEP-0060: Publish-Subscribe
Version: 1.10pre2
URL: http://www.xmpp.org/extensions/tmp/xep-0060-1.10.html
Changelog: In accordance with XMPP Council consensus, moved the
auto-create, auto-subscribe, filtered-notifications, and last-published
XMPP Extensions Editor wrote:
Title: Private Data via PEP
Abstract: This document specifies XMPP semantics for using the
personal eventing subset of XMPP publish-subscribe to persistently
store private data such as bookmarks and client configuration
options.
URL:
William Voorsluys wrote:
Hello,
But, according to the XEP, it is not allowed to include any inner XML
stanza on the iq of type RESULT used as ACK:
iq from='[EMAIL PROTECTED]/balcony' to='[EMAIL PROTECTED]/orchard'
type='result' id='ibb1'/
That's just an example.
The RFC allows zero
Currently it is not possible to send room invitations directly from one
person to another. That is, the invitation must go through the room. See:
http://www.xmpp.org/extensions/xep-0045.html#invite
This can cause problems with deployments that use privacy lists to block
communications from
Currently in XEP-0045, roomnicks are case-sensitive. To be precise
roomnicks are handled according to the Resourceprep profile of stringprep:
http://www.xmpp.org/extensions/xep-0045.html#bizrules-jids
This means that the following roomnicks are all different:
StPeter
stpeter
STPETER
Some
Peter Saint-Andre wrote:
We could solve it by applying the Nodeprep profile of stringprep, but
that would forbid things like whitespace and the ' and : characters.
(Naturally, those characters could be escaped using XEP-0106 if desired.)
Er, that's wrong. XEP-0106 is for node identifiers only
Rachel Blackman wrote:
Currently in XEP-0045, roomnicks are case-sensitive. To be precise
roomnicks are handled according to the Resourceprep profile of
stringprep:
http://www.xmpp.org/extensions/xep-0045.html#bizrules-jids
This means that the following roomnicks are all different:
Michal 'vorner' Vaner wrote:
Hello
On Thu, Jul 19, 2007 at 02:27:51PM -0600, Peter Saint-Andre wrote:
Currently it is not possible to send room invitations directly from one
person to another. That is, the invitation must go through the room. See:
http://www.xmpp.org/extensions/xep-0045
Michal 'vorner' Vaner wrote:
Hello,
On Thu, Jul 19, 2007 at 03:34:25PM -0600, Peter Saint-Andre wrote:
Michal 'vorner' Vaner wrote:
Hello
On Thu, Jul 19, 2007 at 02:27:51PM -0600, Peter Saint-Andre wrote:
Currently it is not possible to send room invitations directly from one
person
[EMAIL PROTECTED] wrote:
On Thu, Jul 19, 2007 at 02:36:25PM -0600, Peter Saint-Andre wrote:
Currently in XEP-0045, roomnicks are case-sensitive. To be precise
roomnicks are handled according to the Resourceprep profile of stringprep:
http://www.xmpp.org/extensions/xep-0045.html#bizrules-jids
Ian Paterson wrote:
*Maybe* we need to consider addressing the valid reasons that Google
Talk feels it needs this policy, rather than handling the symptoms of
the policy? Can we solve the real problem? i.e. can we create enough
anti-spim protocols and/or infrastructure to make Google (and
Robin Redeker wrote:
On Sat, Jul 21, 2007 at 09:20:27AM +0200, Mats Bengtsson wrote:
I think the whole XEP should be renamed to something like:
XEP-0106 - JID Mapping for Gateways
This would be better. But it breaks the generic usage of JIDs for both users
and gateways. It will create a
Tomasz Sterna wrote:
What error condition should I report when there is a SASL level error?
For example a malformed challenge had been sent.
Nothing of
http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-03.html#sasl-errors
seems really appropriate.
The actual problem is
Peter Saint-Andre wrote:
Tomasz Sterna wrote:
Dnia 25-07-2007, śro o godzinie 09:32 -0700, Peter Saint-Andre
napisał(a):
The actual problem is described on
http://jabberd2.xiaoka.com/ticket/116
What do you mean by malformed challenge?
The contents of the BASE64 encoded data is somehow
Tomasz Sterna wrote:
Dnia 25-07-2007, śro o godzinie 09:32 -0700, Peter Saint-Andre
napisał(a):
The actual problem is described on
http://jabberd2.xiaoka.com/ticket/116
What do you mean by malformed challenge?
The contents of the BASE64 encoded data is somehow unparsable
Tomasz Sterna wrote:
Dnia 25-07-2007, śro o godzinie 09:32 -0700, Peter Saint-Andre
napisał(a):
We have a malformed-request error here:
http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-03.html#sasl-errors-malformed-request
My concern is that we do not have it here:
http
addresses would be
possible. (i.e. any valid e-mail address could then be used as a JID as
well)
Right. It's worth investigating.
Also, changing nodeprep seems like it might cause problems with backward
compatibility, no?
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
IMO, (un)escaping should only be done by the entities which need to do
so - we should not mix a routing construct with display.
Sure. We never mess with the routing. From the client perspective,
XEP-0106 is only
. Which
would provide an argument for removing it from the compliance suites
(even at the recommended level) and clarifying the scope of
applicability in XEP-0106.
And maybe that would enable us to end this damn thread.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME
to contact some folks at the IETF about the
issues with DIGEST-MD5).
Thoughts?
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
that it would disallow
only the at-sign (@). (Naturally we can discuss this further...) As to
how it is discovered that a server supports nodeprep2, I will post a
separate message about that.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Michal 'vorner' Vaner wrote:
Hello
On Thu, Aug 02, 2007 at 11:40:25AM -0600, Peter Saint-Andre wrote:
Clearly we can't allow @ because we use that character
as a separator between the node identifier and the domain identifier.
Email address can contain @ in the username part
Thomas Charron wrote:
On 8/2/07, Peter Saint-Andre [EMAIL PROTECTED] wrote:
What specifically breaks? Does it depend on which characters would be
allowed in nodeprep2? I agree that / and @ are problematic, but the
characters ' seem less so. But I may be missing something.
I believe
Tomasz Sterna wrote:
Dnia 02-08-2007, czw o godzinie 13:22 -0600, Peter Saint-Andre
napisał(a):
The sooner we implement XMPP version dependant features mechanics in
our
software, the faster we're be able to move forward. :-)
Did you forget the sarcasm/sarcasm wrapper?
No I did not.
OK
Mridul Muralidharan wrote:
XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Component Connections
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to connect to XMPP servers.
Fabio Forno wrote:
XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Component Connections
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to connect to XMPP servers.
URL:
Justin Karneges wrote:
On Wednesday 01 August 2007 10:10 am, Peter Saint-Andre wrote:
Michal 'vorner' Vaner wrote:
Hello
Wouldn't it be better to discourage _sending_ such messages instead of
recommending how to handle them?
At last a notice that sending such message is a bad thing (dumb
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Btw, changing nodeprep now will cause quite a lot of problem with
existing deployments - since the contact jid's are part of the user data
- and would pretty much mean we cant adopt bis spec.
What specifically
Matthias Wimmer wrote:
Peter Saint-Andre schrieb:
Well we're having a long discussion about this in the jdev room
right now:
http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-02.html
I just read the log. Sounds good and is how I intended/proposed that it
would work:
- Escaping
Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Tomasz Sterna wrote:
I was talking with Grégoire Menuel (mu-conference developer) about
implementing Peter's idea of MUC rooms as items on the roster.
Basically the idea is to teach MUC component to answer to subscription
requests.
So
FYI.
- Forwarded message from [EMAIL PROTECTED] -
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RFC 4979 on IANA Registration for Enumservice 'XMPP'
A new Request for Comments is now available in online RFC libraries.
Top-posting discouraged, comments at the bottom.
On Wed, Aug 08, 2007 at 12:04:25AM +0100, Alex Jones wrote:
On Tue, 2007-08-07 at 14:56 -0600, Peter Saint-Andre wrote:
Alex Jones wrote:
I don't see how XHTML-IM can support icon delimitation like IMML. I
really don't think we
Ian Paterson wrote:
Alex Jones wrote:
On Wed, 2007-08-08 at 13:21 +0100, Ian Paterson wrote:
Mridul Muralidharan wrote:
If we just add another tag to explicitly mark emoticons - and remove
the implicit rendering completely - then Alex's baseline
requirements should be done with
FYI.
Original Message
Date: Wed, 08 Aug 2007 12:48:57 -0600
From: Peter Saint-Andre [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Council] meeting minutes, 2007-08-08
Results of the XMPP Council meeting held 2007-08-08...
Agenda:
http://www.jabber.org/council/meetings
XMPP Extensions Editor wrote:
Version 0.1 of XEP-0225 (Component Connections) has been released.
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to connect to XMPP servers.
One of the items up for discussion is the default namespace
Rachel Blackman wrote:
On Aug 8, 2007, at 1:44 PM, Peter Saint-Andre wrote:
XMPP Extensions Editor wrote:
Version 0.1 of XEP-0225 (Component Connections) has been released.
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components
Tomasz Sterna wrote:
Dnia 08-08-2007, śro o godzinie 15:11 -0700, Justin Karneges napisał(a):
I vote not repeating this mistake. This means
no 'jabber:component' or such. The choice should be between
'jabber:client'
and 'jabber:server' for the namespace. Use a real attribute or
element
Magnus Henoch wrote:
Peter Saint-Andre [EMAIL PROTECTED] writes:
Why does this document specify an XML namespace? It doesn't seem
necessary to namespace the content.
Indeed, not for its own sake; I was thinking about external tools that
might want to identify the file, or embed
Evgeniy Khramtsov wrote:
Peter Saint-Andre wrote:
At the recent XMPP devcon, I talked a bit with Thiago Camargo about NAT
traversal and media relays. There are really two separate issues here:
1. Finding and using STUN servers for NAT traversal. This is discussed
in XEP-0215.
New
clarify this in the spec.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Peter Saint-Andre wrote:
Ian Paterson wrote:
XEP-0100 Gateway Interaction doesn't, AFAICT, explain whether the
username supplied at registration should be the Legacy Service
username or the Jabber username. [The difference between these
usernames (typically escaping) is explained in section
Someone poked me offlist about an oversight in our specs: XEP-0118 (User
Tune) includes a way to stop sending tune updates, but there is no such
mechanism in XEP-0107 (User Mood), XEP-0108 (User Activity), etc. This
seems like a helpful feature and something that we forgot to add to the
Sergei Golovan wrote:
On 8/9/07, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Sergei Golovan wrote:
On 8/9/07, XMPP Extensions Editor [EMAIL PROTECTED] wrote:
Version 0.1 of XEP-0224 (Attention) has been released.
I'd like to comment this version little bit:
1) Headline messages
Olivier Goffart wrote:
Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
Version 0.1 of XEP-0224 (Attention) has been released.
Abstract: This document defines an XMPP protocol extension for getting the
attention of another user.
Changelog: Initial published version. (psa)
Diff:
Olivier Goffart wrote:
Le jeudi 9 août 2007, Peter Saint-Andre a écrit :
Olivier Goffart wrote:
Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
Version 0.1 of XEP-0224 (Attention) has been released.
Abstract: This document defines an XMPP protocol extension for getting
defining a payload format. A client could
send it either by message or by IQ. If you want to buzz one resource,
use IQ. If you want to buzz all resources, use message headline.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Ralph Meijer wrote:
jabber:server and jabber:client both don't make much sense
for component streams. I think we have a couple of choices here:
1. Use a separate namespace for the component streams.
2. Choose from jabber:server and jabber:client
3. Iff we do a new version of XMPP (i.e.
Joe Hildebrand wrote:
On Aug 10, 2007, at 11:52 AM, Peter Saint-Andre wrote:
Joe Hildebrand wrote:
1) A new MUC role which effectively the opposite of visitor. Of course,
on the bar napkin, this got written as rotisiv. :) A rotisiv can
potentially speak (broadcasting to all
1 - 100 of 2690 matches
Mail list logo
