Hi all,
My Firefox extension, Open URIs, at
https://addons.mozilla.org/en-US/firefox/addon/162154/ , has just been
approved by the Mozilla review team. You can read the description there,
but essentially, the aim of the add-on is to gain enough adoption and
experience for the HTML5 working
how the user could obtain support for the XMPP protocol.
Links that put you on the road to nowhere in browsers that do not
support the protocol do not exactly make for a user-friendly site (not
to mention experimentation in the first place).
Brett
On 7/2/2010 1:37 PM, Brett Zamir wrote:
Hi all
On 1/14/2010 10:57 PM, Dave Cridland wrote:
On Thu Jan 14 14:49:12 2010, Peter Saint-Andre wrote:
We AIM to please!
Surely we XMPP to please?
Dave.
Oh, would you two please stop jabber-ing...
Brett
On 8/25/2009 2:46 AM, Peter Saint-Andre wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/09 9:56 AM, Simon McVittie wrote:
It would also be very useful to include a family-name-first (e.g. Chinese)
name in at least one example to illustrate how that works, although
Etienne Philip Pretorius wrote:
Peter Saint-Andre wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/13/09 1:33 PM, Etienne Philip Pretorius wrote:
Hello List,
What stream error would one use to best indicate that there was an
invalid xml character in the stream?
invalid-xml or
Hi,
Just curious about whether Service Discovery, specifically Service Discovery
Extensions, were looked at to handle such versioning information? I think Disco
Extensions would be especially suitable (and not create the need for more
specs), especially if, as we all discussed here earlier,
The see-other-host stream error is defined at
http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.7.3
Brett
On 2/7/2009 4:25 PM, imoracle wrote:
My XMPP client library JAXL is currently having this issue. Once in a
week or so, I can see a stream like:
Code:
On 1/4/2009 5:29 AM, Eric Butler wrote:
Should pep nodes be returned in the result of a disco#items query on a
bare JID? Section 5.2 of XEP-0060 makes it sound like this should be the
case, but it's not completely clear, and ejabberd does not return them.
If not, what's the correct way to get a
Pubsub XEP-0060 states:
6.4.6 Returning Notifications Only
A service MAY return event notifications without payloads (e.g.,
to conserve bandwidth). If so, the client MAY request a specific item
(using the ItemID) in order to retrieve the payload. When an entity
requests items by
For XEP-0060, has any thought been given to allowing the same node IDs
to be reused (for collection or leaf nodes) as long as they are held
within different collection nodes? It might make for a more flexible and
attractive expansion of a hierarchy, if one did not need to rely on ugly
Since a lot of users might not be familiar with language codes, I think
it would make sense for pubsub#language (as with pubsub#type) to also be
allowable as a list-single (xdv:open/ especially vaildation) so that
some predefined choices could be listed for them...
e.g., field
Hi,
Along the lines of how Data Forms types and Data Forms Validation can
influence display of forms, I'd like to see some standard way in which
Pubsub payloads could be similarly extensible, not only by allowing
different namespaces (as is now allowable within Atom extension elements
or for
Hi,
I love the Data Forms spec and the Data Forms Validation spec, but I
have a number of questions and thoughts relating to Data Forms
Validation, XEP-0122.
1) If Data Forms validation is approved, list-multi and list-single
would need to changed as it says in section 3.3 of XEP-0004, that
Also, as for Table 1, as note 10 states, If a particular field type is
not listed, the display MAY include validation support, but is not
expected to do so, although it is pretty obvious, I think the boolean
type should be added to the chart to forbid it for each type of
validation (as with
Also on Data Forms Validation, why are jid-multi and jid-single
discouraged for use with Basic validation, or even 'hidden' for that
matter, if results ca be verified?
Brett
Just a suggestion...
Maybe data forms could, along the lines of reported/ / item/ be
enabled to also return hierarchical listings, such as via nesting of
item/'s? I could see such a thing as useful for some search results
(and it shouldn't be unimaginable that clients could display data
After example 120 in section 8.1.1 of Pubsub XEP-0060, it states,
Similarly, if the node creation request specified a NodeID but the
service modified the NodeID before creating the node (refer to
XEP-0248), the service MUST also specify the modified node in the IQ
result.
I do not see
In the Data Forms spec XEP-0004, what is an implementation to do for each type
if there are empty fields?
Send an emptyvalue/ or an emptyfield/?
An empty field would seem to make sense for lists at least, but I wasn't clear
on what it should be for say, text-single.
Brett
On 12/22/2008 10:37 PM, Dave Cridland wrote:
On Mon Dec 22 13:24:25 2008, Brett Zamir wrote:
In the Data Forms spec XEP-0004, what is an implementation to do for
each type if there are empty fields?
Send an emptyvalue/ or an emptyfield/?
An empty field would seem to make sense for lists
For XEP-0004, in addition to the correction in the schema we discussed
earlier on loosening element ordering requirements within field/, the
schema dealing with field/ also ought to be updated to allow for Data
Forms validation children:
xs:any
I don't see that I submitted this one yet...
In Pubsub XEP 0060, 7.2.3.6 Item Deletion Not Supported, reference is
made to the feature delete-nodes, but it presumably should be
something like delete-items, though the latter would first need to be
listed elsewhere in the document. And under
Might the meta-data query result (section 5.4 in XEP-0060) recommend the
@type attribute on the x's field/ children so that a client could,
for example, know to display a boolean type as the more readable true
and false as opposed to the potential values of 1 and 0?
Brett
Hi,
According to section 6.3.4.1 of Pubsub, When requesting subscription
options...SHOULD specify a node (if no node is specified, the service
MUST assume that the requesting entity wishes to request subscription
options for its subscription to the root collection node; refer to
XEP-0248 for
Given the Subscribe-and-Configure option in Pubsub (at
http://xmpp.org/extensions/xep-0060.html#subscriber-configure-subandconfig
), would it not make sense to be able to get a set of default values for
subscription configuration, just as there is with default node
configuration:
So, can this schema snippet from
http://xmpp.org/extensions/xep-0004.html#schema
xs:element name='field'
xs:complexType
* xs:sequence*
xs:element name='desc' minOccurs='0' type='xs:string'/
xs:element name='required' minOccurs='0' type='empty'/
Hi Jehan,
All of your points (in these Pubsub emails) sounded quite reasonable to me, but
I'm just a fringe subscriber...
I've been waiting on a number of Pubsub items too, but
Peter said that he was collecting the Pubsub errata
from me and would reply later, so maybe that's going on with your
Under example 18 at http://xmpp.org/extensions/xep-0248.html, it states,
To associate a node with the root collection node, the node owner MUST
submit an empty value/ element within the 'pubsub#collection' field.
whereas in example 21, it states, To disassociate the node from the
root
In http://xmpp.org/extensions/xep-0060.html#owner-subreq-pernode , a
per-node request (of pending subscriptions) is to be made using Ad-hoc
Commands. The Openfire implementation returns a command/ child and
looking at the Ad-hoc Commands spec,
Hi,
For http://xmpp.org/extensions/xep-0248.html#revs , does
pubsub#children_association_policy relate to disassociating nodes as
well, and if not, should it also be recommended to support a policy and
whitelist for disassociation?
Brett
Brett Zamir wrote:
Ralph Meijer wrote:
On Thu, Nov 20, 2008 at 07:26:53PM -0700, Peter Saint-Andre wrote:
[..]
The Data Forms schema for 'field' would indicate that value/ instances
must come before any option/ instances...
Ah, I see. I'll look into fixing that tomorrow.
Did
Ralph Meijer wrote:
On Thu, Nov 20, 2008 at 07:26:53PM -0700, Peter Saint-Andre wrote:
[..]
The Data Forms schema for 'field' would indicate that value/ instances
must come before any option/ instances...
Ah, I see. I'll look into fixing that tomorrow.
Did we really want to
I never got an answer on this one... Anybody?
thanks,
Brett
---BeginMessage---
In Examples 11-13, and 15, 16 (and 14 if you meant to have the original
XML there too) of http://xmpp.org/extensions/xep-0248.html , there is no
field var='FORM_TYPE' type='hidden', whereas the other examples with a
According to the schema in Data Forms,
http://xmpp.org/extensions/xep-0004.html , value/ should precede
option/:
xs:sequence
xs:element name='desc' minOccurs='0' type='xs:string'/
xs:element name='required' minOccurs='0' type='empty'/
xs:element ref='value'
In Examples 11-13, and 15, 16 (and 14 if you meant to have the original
XML there too) of http://xmpp.org/extensions/xep-0248.html , there is no
field var='FORM_TYPE' type='hidden', whereas the other examples with a
child x xmlns='jabber:x:data'/ in configure/ have it. If it is not
to be there,
Jonathan Schleifer wrote:
Oh, and if we're already at it, you should stop using TOFU[1], which
is considered very impolite on mailing lists.
--
Jonathan
[1] http://en.wikipedia.org/wiki/TOFU#Top-posting
I personally strongly dislike bottom-posting, and the Wikipedia article
you cite also
In the Openfire implementation of Pubsub, the following field/ is
returned in a form (for default configuration of nodes):
field var=pubsub#itemreply type=list-single label=Select
entity that should receive replies to itemsvalueowner/value/field
All of the other field/'s encapsulate the
In Pubsub XEP-0060, in example 113, for a request to create a node,
there is this:
iq type='set'
from='[EMAIL PROTECTED]/elsinore'
to='pubsub.shakespeare.lit'
id='create1'
pubsub xmlns='http://jabber.org/protocol/pubsub'
create node='princely_musings'/
/pubsub
/iq
However, just
If you're still taking errata on the non-draft spec... (the draft spec
has fixed it already)
In the last example in section 7.4, both iq/'s have a @to, though they
are not supposed to per Core spec 9.1.1 (a stanza sent from a client to
a server for handling by that server (e.g., presence sent
Sorry, was relying on the subject line--IM spec...
Brett
Peter Saint-Andre wrote:
Brett Zamir wrote:
If you're still taking errata on the non-draft spec... (the draft spec
has fixed it already)
Which spec? We have an awful lot of them...
Peter
I meant to say the copy at http://xmpp.org/rfcs/rfc3921.html but
mistakenly pasted the text version from ietf.org. Oddly, RFC3921 is
blocked for me here in China, but only that page (I can get to it via a
proxy)!
Brett
Sorry again... Clearing the browser cache fixed it...
Brett
1) There is a link in 7.1.2 to
http://xmpp.org/extensions/xep-0060.html#impl-errors which should be to
http://xmpp.org/extensions/xep-0060.html#impl-bounce
2) The link in 8.7.4 to
http://xmpp.org/extensions/xep-0060.html#impl-unsub doesn't lead
anywhere (and the section (by that name at
Hi,
1) I think Example 191 in http://xmpp.org/extensions/xep-0060.html
should have member-affiliation, outcast-affiliation, or
publisher-affiliation as a feature instead of modify-affiliations
(which is covered in the previous example).
2) And immediately preceding example 122, there is
Hi,
Also, in examples 191-194, I believe the sender's XML (sent back with
the error) should have been related to an attempt to modify the
affiliations since that is the subject of that section.
Brett
The following unsupported type errors are in the schema, but I'm not
sure they can actually be triggered (and if so under what circumstances):
1) At the end of 8.1.3, it seems to me to indicate an error would not be
returned: If the create-and-configure option is not supported but the
Hi,
In http://xmpp.org/extensions/xep-0055.html , example 8, we believe @var
should be 'x-gender' and not 'gender' per Field Standardization...
Brett
Hi,
In http://xmpp.org/extensions/xep-0055.html , examples 7-9, it looks
like @var should be 'x-gender' and not 'gender' per Field Standardization...
Brett
Kevin Smith wrote:
Per the RFC3921 (including the newer draft), when message type is
normal, presumably appropriate for something like an email, it is
stated that A receiving client SHOULD present the message in an
interface enabling the recipient to reply, but without a conversation
history.
Peter Saint-Andre wrote:
Brett Zamir wrote:
In Jabber Search, iq type=set is used to submit a search form whereas
in the examples in 0059, the type used--also using the jabber:iq:search
namespace--is 'get'.
The Core spec defines an iq type 'get' stanza as a request for
information
Peter Saint-Andre wrote:
Brett Zamir wrote:
As comments, processing instructions, DTD subset, and entity reference
are prohibited in XMPP, I was wondering whether there were or could be a
standard way to escape at least processing instructions, comments, and
the internal DTD subset
Greetings!
Was item #18 on the agenda, re: conflicting examples in the way the IQ
type attribute is used in Jabber Search (0055) and Result Set Management
(0059) tabled to another meeting?
In Jabber Search, iq type=set is used to submit a search form whereas
in the examples in 0059, the
As comments, processing instructions, DTD subset, and entity reference
are prohibited in XMPP, I was wondering whether there were or could be a
standard way to escape at least processing instructions, comments, and
the internal DTD subset (canonical features) so they could be reliably
52 matches
Mail list logo
