Re: [Standards] User Activity (XEP-0108)
Florian Zeitz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brendan Taylor wrote: XEP-0108 says: In addition, the *specific* activity element can be in order to handle activities not defined herein. I read that to mean that you can do: but not: Is that incorrect? I'm not fluent in XML Schema. Indeed it is. According to the XML Schema can be inside any general activity, but not directly under the element. I already suggested adding a (just a placeholder name) tag at the top level some time ago (not only for activity but also for mood) and I think psa agreed it was a good idea, but somehow we both forgot about that. I haven't forgotten about it, just haven't gotten to it yet. :) But I suppose we could allow as a child of too. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] User Activity (XEP-0108)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brendan Taylor wrote: > > XEP-0108 says: > > In addition, the *specific* activity element can be in order to > handle activities not defined herein. > > I read that to mean that you can do: > > > > but not: > > > > Is that incorrect? I'm not fluent in XML Schema. Indeed it is. According to the XML Schema can be inside any general activity, but not directly under the element. I already suggested adding a (just a placeholder name) tag at the top level some time ago (not only for activity but also for mood) and I think psa agreed it was a good idea, but somehow we both forgot about that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIrLmm0JXcdjR+9YQRAmlkAKDYB4CkINBUVKpzZzWUvtsTfiqITwCfWQ1D JvN5vUYfP9KkKD/G+Rm7YBw= =3Yld -END PGP SIGNATURE-
Re: [Standards] User Activity (XEP-0108)
On Thu, Aug 21, 2008 at 02:19:32AM +0200, Pavel Simerda wrote: > is the only way foreign > elements should be ever included. I know, I omitted the namespaces for clarity. I probably should have indicated that. pgpdutuxGe3WZ.pgp Description: PGP signature
Re: [Standards] User Activity (XEP-0108)
On Wed, 20 Aug 2008 16:02:01 -0700 "Collin Grady" <[EMAIL PROTECTED]> wrote: > On Wed, Aug 20, 2008 at 3:58 PM, Brendan Taylor <[EMAIL PROTECTED]> > wrote: > > XEP-0108 says: > > > >In addition, the *specific* activity element can be in > > order to handle activities not defined herein. Yep, *activities not defined herein* > > I read that to mean that you can do: > > > > This syntax without 'xmlns' means is an element that *is* defined for this particular XML namespace. If it's not, you can't do that. > > but not: > > > > > > > > Is that incorrect? I'm not fluent in XML Schema. The shares the same problem. > > Hmm, that's how I read that section too, looking at it - that part > might need clarified if the latter is supposed to be allowed. > is the only way foreign elements should be ever included. Note: I'm talking about the XML part and didn't read the XEP at all. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
This looks ugly and unnecessary to me. On Wed, 20 Aug 2008 16:01:54 +0200 Jonathan Schleifer <[EMAIL PROTECTED]> wrote: > Am 20.08.2008 um 01:01 schrieb Peter Saint-Andre: > > > >from='[EMAIL PROTECTED]/desktop' > >to='[EMAIL PROTECTED]'> > > > > >id='some-long-id-here'/> > >^^ > > > > > > How about this instead? > >to='[EMAIL PROTECTED]'> > > >some_id (doesn't even need to be long) > > > > > Are you sure current implementations will not route that? > For the clients, it doesn't matter if they ignore it, because that > means they only support mediated invitations and not direct > invitations. Only new clients will implement directed invitiations, > and if we make the ID a part of that, they will implement it. > > -- > Jonathan -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Mon, 18 Aug 2008 02:52:50 +0100 "Matthew Wild" <[EMAIL PROTECTED]> wrote: > On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre > <[EMAIL PROTECTED]> wrote: > > Pavel Simerda wrote: > >> > >> Ok, just... couldn't this be at least partially automated (not to > >> have the sure check himself)? If it's not possible, never mind. > > > > Sure it could. I'm not sure if we really need that, given that > > members-only rooms are relatively uncommon, but we could presumably > > define a data form or ad-hoc command for the automated flow if we > > really need to. > > > > I'm leaning toward crossing that bridge when we come to it. My reason > for bringing invite-only rooms was not to suggest they should be done, > just that this protocol takes away the possibility to implement them > (and it happens to be something I was thinking about a couple of weeks > ago). We don't have invite-only rooms, but IRC doesn't have > members-only rooms. > > I can't think of many cases an invite-only room would be called for, > unless it is an admin doing the inviting, in which case it is easy to > add invitees to the member list. That, or just use a password, as > exampled in this XEP. But this must apparently by written by the inviting user. > Matthew. -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] User Activity (XEP-0108)
On Wed, Aug 20, 2008 at 3:58 PM, Brendan Taylor <[EMAIL PROTECTED]> wrote: > XEP-0108 says: > >In addition, the *specific* activity element can be in order to >handle activities not defined herein. > > I read that to mean that you can do: > > > > but not: > > > > Is that incorrect? I'm not fluent in XML Schema. Hmm, that's how I read that section too, looking at it - that part might need clarified if the latter is supposed to be allowed. -- Collin Grady
Re: [Standards] User Activity (XEP-0108)
On Wed, Aug 20, 2008 at 08:40:16AM -0600, Peter Saint-Andre wrote: > Jonathan Schleifer wrote: >> Am 20.08.2008 um 05:16 schrieb Peter Saint-Andre: >>> Matthew Wild wrote: >>> How about: >>> >>> That's already allowed, no? >> Not exactly. But this would: >> >> >> >> >> > > XEP-0108 already includes the element. So the first example is > correct, not the second. XEP-0108 says: In addition, the *specific* activity element can be in order to handle activities not defined herein. I read that to mean that you can do: but not: Is that incorrect? I'm not fluent in XML Schema. pgpS7XqrFa0tf.pgp Description: PGP signature
[Standards] LAST CALL: XEP-0243 (XMPP Server Compliance 2009)
This message constitutes notice of a Last Call for comments on XEP-0243 (XMPP Server Compliance 2009). Abstract: This document defines XMPP server compliance levels for 2009. URL: http://www.xmpp.org/extensions/xep-0243.html This Last Call begins today and shall end at the close of business on 2008-09-02. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
[Standards] LAST CALL: XEP-0242 (XMPP Client Compliance 2009)
This message constitutes notice of a Last Call for comments on XEP-0242 (XMPP Client Compliance 2009). Abstract: This document defines XMPP client compliance levels for 2009. URL: http://www.xmpp.org/extensions/xep-0242.html This Last Call begins today and shall end at the close of business on 2008-09-02. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
[Standards] [Fwd: [Council] meeting minutes, 2008-08-20]
FYI Original Message Date: Wed, 20 Aug 2008 14:11:47 -0600 From: Peter Saint-Andre <[EMAIL PROTECTED]> To: XMPP Council <[EMAIL PROTECTED]> Subject: [Council] meeting minutes, 2008-08-20 Results of the XMPP Council meeting held 2008-08-20... Agenda: http://www.jabber.org/council/meetings/agendas/2008-08-20.html Log: http://logs.jabber.org/[EMAIL PROTECTED]/2008-08-20.html 0. Roll call Present: Dave Cridland, Peter Saint-Andre, Kevin Smith. Ralph Meijer sent his regrets, he is provisionally +1 on all items but will post to the list after the meeting. AWOL: Ian Paterson. 3 of 5 members present, quorum achieved. 1. Agenda bashing BOSH items (XEP-0124 and XEP-0206) removed pending further discussion on the [EMAIL PROTECTED] list. 2. Next meeting September 3. 3. XEP-0060: Publish-Subscribe Dave, Peter, and Kevin +1 with removal of section on owner notifications of subscription events. Peter removed this during the meeting. 4. XEP-0071: XHTML-IM Kev +1 with wordsmithing changes made during the meeting. Dave and Peter +1. 5. XEP-0174: Serverless Messaging Dave, Peter, and Kevin +1. Note: we need to harmonize stream handling at some point between rfc3920bis, XEP-0174, and XEP-0246. 6. XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH) Skipped. 7. XEP-0206: XMPP Over BOSH Skipped. 8. XEP-0231: Bits of Binary Dave, Peter, and Kevin +1. 9. XEP-0221: Data Forms Media Element Dave, Peter, and Kevin +1. 10. XEP-0158: Robot Challenges Dave, Peter, and Kevin +1. 11. XEP-0242: XMPP Client Compliance 2009 Consensus to issue a Last Call. 12. XEP-0243: XMPP Server Compliance 2009 Consensus to issue a Last Call. 13. Proto-XEP: Direct MUC Invitations Kevin pointed out that we might as well resurrect jabber:x:conference instead of defining something new. Peter agreed that is a reasonable approach and will post to the standards list about that. 14. Council elections. Candidate position statements are accumulating. 15. Any other business? None. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Direct MUC Invitations Abstract: This specification defines a method for inviting a contact to a multi-user chat room directly, instead of sending the invitation through the chat room. URL: http://www.xmpp.org/extensions/inbox/direct-invitations.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. In the Council meeting just ended, Kevin Smith suggested that we might want to bring back the old jabber:x:conference namespace: You have been invited to the [EMAIL PROTECTED] room. Older clients already support that, so the suggestion seems reasonable to me. Thoughts? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] User Activity (XEP-0108)
Matthew Wild wrote: Ha, I somehow didn't notice that. What would we do without the documentation guy? :) Whatever you did, it would be *undocumented*! ;-) smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] User Activity (XEP-0108)
On Wed, Aug 20, 2008 at 3:40 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Jonathan Schleifer wrote: >> >> Am 20.08.2008 um 05:16 schrieb Peter Saint-Andre: >> >>> Matthew Wild wrote: >>> How about: >>> >>> That's already allowed, no? >> >> >> Not exactly. But this would: >> >> >> >> >> >> > > XEP-0108 already includes the element. So the first example is > correct, not the second. > Ha, I somehow didn't notice that. What would we do without the documentation guy? :) Matthew.
Re: [Standards] User Activity (XEP-0108)
Am 20.08.2008 um 16:40 schrieb Peter Saint-Andre: XEP-0108 already includes the element. So the first example is correct, not the second. Oh, sorry then. Had in mind it's not there :) -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] User Activity (XEP-0108)
Jonathan Schleifer wrote: Am 20.08.2008 um 05:16 schrieb Peter Saint-Andre: Matthew Wild wrote: How about: That's already allowed, no? Not exactly. But this would: XEP-0108 already includes the element. So the first example is correct, not the second. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Jonathan Schleifer wrote: Am 20.08.2008 um 01:01 schrieb Peter Saint-Andre: ^^ How about this instead? some_id (doesn't even need to be long) Element, attribute, whatever. Are you sure current implementations will not route that? No, I have not yet tested that. But it's easy enough to do. For the clients, it doesn't matter if they ignore it, because that means they only support mediated invitations and not direct invitations. Only new clients will implement directed invitiations, and if we make the ID a part of that, they will implement it. Right. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] User Activity (XEP-0108)
Am 20.08.2008 um 05:16 schrieb Peter Saint-Andre: Matthew Wild wrote: How about: That's already allowed, no? Not exactly. But this would: -- Jonathan -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Am 20.08.2008 um 01:01 schrieb Peter Saint-Andre: ^^ How about this instead? some_id (doesn't even need to be long) Are you sure current implementations will not route that? For the clients, it doesn't matter if they ignore it, because that means they only support mediated invitations and not direct invitations. Only new clients will implement directed invitiations, and if we make the ID a part of that, they will implement it. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] User Activity (XEP-0108)
Peter Saint-Andre wrote:
> Matthew Wild wrote:
>
>> How about:
>>
>>
>>
>>
>>
>>
>
> That's already allowed, no?
Yes.
But example: People implemented set of 'additional' states for one
client and included icons for these states. All users of this client can
view them. It's fine, but what should do developers of other clients?
Reimplement new stateset every time? It not enough universal solution.
Need base for client-independent states & icons exchange.
Every user (not only programmers) should have possibility add new state,
draw new icon for it and share with own contacts.
I imagine this as (it's long piece of text :)):
1. Alice - designer. She created new icon, uploaded it on public server,
entered title and text for it with some additional info in her client.
She pressed 'Send custom activity' button, and it's all her actions
2.1.Alice' client saves new activity
2.2. Alice' client sends XML like:
Alice
http://www.alicehomepage.org
GIMPization
Working
3. Bob' client received activity info from Alice and began parse it.
3.1. Client see element in . As it knows this means
custom activity.
3.2. Client supports custom activity. It check cache and can't found
nothing for http://www.alicehomepage.org/custom_activity namespace. It
creates new cache list for this namespace
3.3. Client gets name of activity('GIMPization') and name of
category('Working'). It have no icons for them
3.4. Client supports only icons 16x16 and it downloads
gimpization_16x16.png file and working_16x16.png file and put them into
cache for namespace http://www.alicehomepage.org/custom_activity
3.5. Client adds new activity with icon in dialog for choosing activity
(may be Bob in future want use it)
3.6. Client draws icon for activity 'GIMPization' in roster and adds in
tooltip message 'Working: GIMPization'
4. Bob - programmer. He see in roster new icon, reads message and reply
to Alice: 'Hi, Alice! You really jumped from Photoshop to GIMP?'
Popular states & icons will spread in jabber network automatically, from
one user to another. Peoples will invent new values ourselves. PEP is
personal events, custom activity will become a personal states
