Re: [Standards] XEP-0108: registry?
Daniel Noll wrote: Daniel Noll wrote: doesn't really matter to me. They're all phones. If I'm on an audio call, I might be able to IM with you in the background without the other person knowing. But I can't very well get away with that on a video call. So I think the distinction provides useful information wrt my ability to communicate. And that's what extended presence is all about, no? Hmm... that could be a thought. Although... 1. There are already activities in the list which don't necessarily help the other user determine if they can send a message. Did we say that all activities needed to help other users determine if it's appropriate to send a message? e.g. for gaming, if they're playing Solitaire, I'd say they can respond to messages. There are games where they can't. XEP-0108 is extensible. People can always define more precise sub-activities if they want to. We *could* do that with the video phone activity. It's a bit of a borderline case, but IMHO it's going to be common enough that we want to define a separate activity for it. 2. We already have presence for the other user to determine if I'm contactable. i.e. can 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
[Standards] Proposed XMPP Extension: Getting a User's Attention
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Getting a User's Attention Abstract: This document defines an XMPP protocol extension for getting a user's attention. URL: http://www.xmpp.org/extensions/inbox/attention.html The XMPP Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official XEP.
[Standards] XEP-0115 is harmful and should be deferred
Dnia 04-07-2007, śro o godzinie 21:03 -0600, Peter Saint-Andre napisał(a): base64(sha1(dave-formatted id/features)) Seems reasonable to me. I've picked this random post to reply but it does not concern this particular post but the whole thread... ...which I did not follow really, because I find this whole XEP and concept of entity capabilities distributed with presence packed unneeded and harmful. This XEP came out to solve a problem of jabber:iq:version storming on the Psi client launch, which other clients blindly copied just to show-off the remote client version at the fancy tooltip. So instead of pull-based mechanizm there was a push-based mechanizm deployed. But I do see some inconsistency here. We don't allow vCard hashes to be pushed with the presence. We do not allow moods and now-playing to be pushed on us with the presence packet, but we gladly allow unrequested capabilities to be pushed with the presence?? More then, we're going to REQUIRE them? Excuse me. I've subscribed your PRESENCE information. I didn't ask for your mood, tune, avatar nor capabilities. If I would need them, I will ask and you may allow me to have them. There's nothing special about the caps, that these would require special privileges. And what's more - we invented a way for me to subscribe for all this kinds of additional information. Using everyone's favorite PubSub. Why don't we reuse it somehow? We didn't have PEP/PubSub deployed at all when we invented XEP-0115, but we do have now and for sure can do better now. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
[Standards] private storage revisited
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 it as follows: *** 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] For such a node, the access model MUST remain fixed and a pubsub service MUST return an error if the node owner tries to change it. *** Yes this hardcodes NodeIDs. But it has the benefit of being simple, explicit, and secure (the access model can't be changed, which is especially important for private storage). Thoughts? /psa [1] In fact roster doesn't make sense here since you need to specify the roster group. And BTW the list for whitelist must start out empty, i.e., only the node owner can publish or subscribe. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] 'from' address on roster push
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' address on a roster push. If a roster push includes a 'from' address then the client SHOULD ignore the stanza. Is it backwards compatible? -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] XEP-0115 is harmful and should be deferred
Hi! On Thu, Jul 05, 2007 at 11:34:10PM +0200, Tomasz Sterna wrote: Dnia 04-07-2007, śro o godzinie 21:03 -0600, Peter Saint-Andre napisał(a): base64(sha1(dave-formatted id/features)) Seems reasonable to me. I've picked this random post to reply but it does not concern this particular post but the whole thread... ...which I did not follow really, because I find this whole XEP and concept of entity capabilities distributed with presence packed unneeded and harmful. This XEP came out to solve a problem of jabber:iq:version storming on the Psi client launch, which other clients blindly copied just to show-off the remote client version at the fancy tooltip. So instead of pull-based mechanizm there was a push-based mechanizm deployed. But I do see some inconsistency here. We don't allow vCard hashes to be pushed with the presence. We do not allow moods and now-playing to be pushed on us with the presence packet, but we gladly allow unrequested capabilities to be pushed with the presence?? More then, we're going to REQUIRE them? w.r.t. to vcard, this is just a small snipped from a recent debug log: 2007-06-30 13:12:30 +0200 | presence from= to= 2007-06-30 13:12:30 +0200 | statusi'm here/status 2007-06-30 13:12:30 +0200 | priority1/priority 2007-06-30 13:12:30 +0200 | c node=http://gaim.sf.net/caps; ver=2.0.0beta5 xmlns=http://jabber.org/protocol/caps/ 2007-06-30 13:12:30 +0200 | x xmlns=vcard-temp:x:update/ 2007-06-30 13:12:30 +0200 | /presence Quite some noise I get there with the presence, I completly agree with you on the following: Excuse me. I've subscribed your PRESENCE information. I didn't ask for your mood, tune, avatar nor capabilities. If I would need them, I will ask and you may allow me to have them. There's nothing special about the caps, that these would require special privileges. I think this is a good point and well spotted :-) ! And what's more - we invented a way for me to subscribe for all this kinds of additional information. Using everyone's favorite PubSub. Why don't we reuse it somehow? We didn't have PEP/PubSub deployed at all when we invented XEP-0115, but we do have now and for sure can do better now. I, as client developer, would really like if PEP/PubSub became more widely-used. Recently when reading this list I became the feeling that PEP is being avoided. Eg. by the common ironic joke: 'lets use PEP for this'. PEP/PubSub has many good applications IMO. And if you ask me, PEP is IMO essential enough to go into XEP-0073 (Basic IM Protocol Suite). (Well, it will have to go in there anyway if it becomes neccessary to promote client capabilities.) And I think announcing capabilities seems to be a great application of PEP/PubSub. I can already imagine the client setting: [X] Allow others to subscribe to your client's capabilities. or: [X] Don't publish this client's capabilities. Just my 1.999... Cents Greetings, Robin
Re: [Standards] 'from' address on roster push
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' address on a roster push. If a roster push includes a 'from' address then the client SHOULD ignore the stanza. Is it backwards compatible? Good question. RFC 3921 talks only about what the client must do with regard to the 'from' address on a roster push: a client SHOULD check the from address of a roster push (incoming IQ of type set containing a roster item) to ensure that it is from a trusted source; specifically, the stanza MUST either have no 'from' attribute (i.e., implicitly from the server) or have a 'from' attribute whose value matches the user's bare JID (of the form [EMAIL PROTECTED]) or full JID (of the form [EMAIL PROTECTED]/resource); otherwise, the client SHOULD ignore the roster push. If a bis-compliant server never includes a 'from' address on a roster push, a 3921-compliant client will not break. However, a bis-compliant client might ignore roster pushes from a 3921-compliant server, since a 3921-compliant server might include a 'from' address whose value is the bare JID or full JID of the user. 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 without updating the roster on the server? Does the server deliver the IQ-result packets from all interested resources to the initiating resource for the roster set? That seems wrong to me (i.e., I think it's a spec bug in RFC 3921). A bare JID makes more sense because IQs sent to the bare JID are handled by the server. But in that case, the server can't perform the usual swapping of 'from' and 'to' addresses anyway, so it seems easier to not include the 'from' address. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] roster schema
Dnia 25-06-2007, pon o godzinie 09:52 -0600, Peter Saint-Andre napisał(a): If we say that the length SHOULD NOT be more than characters I would rather phrase it, that the client MAY NOT expect server to handle names longer than characters. If the server could handle and client knows it could handle, it could use longer names. It's not like this is completely subjective. Mostly I was thinking about database storage of rosters. It would be helpful for server developers to know that roster item handles and roster group names won't need to be more than characters / octets / bytes long. This is not how modern databases work. Handling of variable length strings and fixed length strings works equally well. Actually it would be a pure waste of space to pre-allocate fixed string of 1023 characters to store 5. This is the server implementation detail. If server could handle it, why discourage it? And if server cannot (or does not want, by config option) to handle it, it should communicate it with well-defined error. If it's a SHOULD then you have flexibility. 640KB SHOULD be enough for anyone. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] 'from' address on roster push
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 without updating the roster on the server? It would come from other [EMAIL PROTECTED]/resource that the connection is bound and should be ignored. SHOULD be ignored by the client that receives the IQ-results from the other resources? And the IQ-results are not received by the server or processed by the server, even though the server is the entity that sent the roster pushes. Bad. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
