Re: [Standards] roster schema
Dnia 05-07-2007, czw o godzinie 16:49 -0600, Peter Saint-Andre napisał(a): If the server could handle and client knows it could handle, it could use longer names. How does the client know? It tried to put a long name in a minute ago and it succeeded. 640KB SHOULD be enough for anyone. We're talking about a handle for an IM contact or the name of a roster group here, not the functioning of a complete operating system. Get some perspective. I'm giving you the perspective. We'll defining standards for future use and we simply cannot envision what will be the future requirements. Many tried and failed miserably. Ergo - let's not introduce arbitrary restrictions where these are not needed. This is an implementation issue, so let the implementer and administrator decide. Your concern is clients failing roster sets. Mridul recommended a MINIMUM though and I'm all for for it. When you specify that server MUST handle at least 163 characters (yes Unicode characters, not bytes - again this is an implementation issue), then client authors could set the max limit on 163 and live perfectly fine. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] private storage revisited
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] 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. [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. I think I agree with everything above except the proposed syntax. *If* we agree on the functionality, then IMHO it *should* be trivial to come up with a more appropriate syntax. I strongly disagree with overloading the node attribute with the access model. IMHO, mixing an identifier and a configuration parameter into the same attribute would be a horrible (and unnecessary) hack. Instead of: publish node='http://jabber.org/protocol/activity+whitelist' I could live with this syntax: publish node='http://jabber.org/protocol/activity' access_model='whitelist' However, IMHO, the following example stanza would fit better with the rest of the protocol. That would make it easier for developers, since they could simply reuse their existing configure/ element processing code: iq from='[EMAIL PROTECTED]/balcony' type='set' id='create-presence' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='http://jabber.org/protocol/activity' item activity xmlns='http://jabber.org/protocol/activity' relaxing partying/ /relaxing text xml:lang='en'My nurseapos;s birthday!/text /activity /item /publish configure x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#access_model' optionvaluewhitelist/value/option /field /x /configure /pubsub /iq I stress that the functionality associated with the above example would be absolutely identical to that which Peter described above. - Ian P.S. I put Ralph on copy because, although he has been very busy recently, we're not going to move forward on this without his input and eventual acceptance (he's both a principle author of the PubSub protocol and a council member).
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
On Friday 06 July 2007 06:49, XMPP Extensions Editor wrote: 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. I know it doesn't have the humour tag, but I still can't tell if this is a joke or not. Either way, it sounds like it has the potential to be the most abused feature ever. :-) It may even be desirable to enable this per-user. Whether this means giving different users different disco results or giving the same result and silently dropping the packet, I'm not sure. I think I would prefer the third option, the sender getting a not-authorized error back. Daniel pgpmIhloIvzBa.pgp Description: PGP signature
Re: [Standards] XEP-0115 is harmful and should be deferred
On 6 Jul 2007, at 13:06, Daniel Noll wrote: But mobile client users and authors are still going to object to receiving data they didn't ask for, especially if it's the same size as what was already being sent in the presence. :-) Remember that if the server supports the caps optimisation you'll only receive caps when it changes, because it'll be stripped out of subsequent presence packets to you. /K -- Kevin Smith KTP Associate - Exeter University / ai Corporation Psi Jabber client developer/project leader (http://psi-im.org/) XMPP Standards Foundation Council Member (http://xmpp.org)
Re: [Standards] XEP-0108: registry?
On Friday 06 July 2007 01:53, Peter Saint-Andre wrote: 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. Video phones may become common enough one day (when Cisco stop thinking the privilege is worth paying four times the price of a normal phone, there will probably be a boom in them) but if you want other types of phone that are already common enough to split into their own sections, I'm sure there are plenty. Talking on a mobile vs. talking on a landline, for instance? Talking on a VOIP softphone vs. using a real phone? 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. That's why I will suggest doing both. Set activity to on the phone and status to dnd. That's more specific than doing either independently, and doesn't even require inventing a new type of phone which may not even add any useful information to the other user. Daniel pgpy1fhx1BcxZ.pgp Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
On 6 Jul 2007, at 13:13, Daniel Noll wrote: Title: Getting a User's Attention I know it doesn't have the humour tag, but I still can't tell if this is a joke or not. Either way, it sounds like it has the potential to be the most abused feature ever. :-) Some users want such a feature; I guess most clients would just have an option to ignore the tag. /K -- Kevin Smith KTP Associate - Exeter University / ai Corporation Psi Jabber client developer/project leader (http://psi-im.org/) XMPP Standards Foundation Council Member (http://xmpp.org)
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
On Jul 06, 2007, at 14:13, Daniel Noll wrote: It may even be desirable to enable this per-user. Whether this means giving different users different disco results or giving the same result and silently dropping the packet, I'm not sure. I think I would prefer the third option, the sender getting a not-authorized error back. Isn't not-authorized an iq result, and thus not applicable for a message stanza? andy
Re: [Standards] roster schema
Hello On Fri, Jul 06, 2007 at 10:54:01AM +0100, Richard Dobson wrote: It would be handy to also specify an extended additional error along with the not-allowed/ so that the client can know what part of the roster item is wrong which would add to the flexibility, e.g. name-limit-exceeded xmlns=urn:xmpp:roster:errors/ and groupname-limit-exceeded xmlns=urn:xmpp:roster:errors/. Maybe even add the longest allowed item in the error so the client can know how much it must restrict the user? Like name-limit-exceeded xmlns=urn:xmpp:roster:errors max-len=511/ -- A nuclear war can ruin your whole day. Michal 'vorner' Vaner pgp1GdqT4liGm.pgp Description: PGP signature
Re: [Standards] XEP-0115 is harmful and should be deferred
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. To point out the obvious, there are two non-circular solutions: 1. Assume that caps is present and make PEP depend on caps (current option) It's the current option because it's reality. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
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 not necessary to return an error, IMHO. On mixed messages, my implementation just ignores the attention part and displays the body-part like any other message when this feature is disabled. That's also how I specified it in the XEP. Note that my example actually is a mixed message. Of course, that's not necessary, and my implementation can't send such a stanza either (it'd be complicated UI-wise to do that). 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 poke, but naturally you could do that. If my client didn't know anything about the poke namespace (or was configured to ignore pokes) then it would simply ignore that part of the stanza. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
On Jul 06, 2007, at 18:31, Peter Saint-Andre 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. Usually, it's a button in the message window I think. I think it's less likely that you'd send a message (hey pay attention!) with the poke, but naturally you could do that. If my client didn't know anything about the poke namespace (or was configured to ignore pokes) then it would simply ignore that part of the stanza. Yes, that's what I was thinking. andy
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
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 poke, but naturally you could do that. If my client didn't know anything about the poke namespace (or was configured to ignore pokes) then it would simply ignore that part of the stanza. We have a poke function in Astra, and basically it's just a little shaky-window icon in the toolbar. Works with the AIM, MSN, Yahoo, etc. pokes; I'll make it work with this. (Obviously, it's something which can be turned off, and which personally I /do/... but it was a very highly-requested feature, so.) Since poke (or buzz) is usually just implemented on any service or client as your message window jittering around on the recipient's desktop like a toddler who's just drunk a venté espresso, people tend to send a message, then hit poke. -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
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 poke, but naturally you could do that. If my client didn't know anything about the poke namespace (or was configured to ignore pokes) then it would simply ignore that part of the stanza. We have a poke function in Astra, and basically it's just a little shaky-window icon in the toolbar. Works with the AIM, MSN, Yahoo, etc. pokes; I'll make it work with this. (Obviously, it's something which can be turned off, and which personally I /do/... but it was a very highly-requested feature, so.) Since poke (or buzz) is usually just implemented on any service or client as your message window jittering around on the recipient's desktop like a toddler who's just drunk a venté espresso, people tend to send a message, then hit poke. I guess we can't call it poke, since that's already taken by XEP-0132. But buzz is fine with me unless it's trademarked by one of the existing IM services -- attention is kind of boring if you ask me. ;-) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] private storage revisited
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] 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. [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. I think I agree with everything above except the proposed syntax. *If* we agree on the functionality, then IMHO it *should* be trivial to come up with a more appropriate syntax. I strongly disagree with overloading the node attribute with the access model. IMHO, mixing an identifier and a configuration parameter into the same attribute would be a horrible (and unnecessary) hack. One nice thing about the NodeID hack is that the client knows immediately what the access model (e.g., if the node already exists and it receives data published to that node by another resource). Instead of: publish node='http://jabber.org/protocol/activity+whitelist' I could live with this syntax: publish node='http://jabber.org/protocol/activity' access_model='whitelist' Haven't we been down this road before? See for instance Example 5 here: http://www.xmpp.org/extensions/attic/jep-0163-0.2.html Yet we moved away from that. See here (Ralph objecting to the 'access' attribute): http://mail.jabber.org/pipermail/standards/2006-May/011315.html And further discussion: http://mail.jabber.org/pipermail/standards/2006-May/011383.html http://mail.jabber.org/pipermail/standards/2006-May/011414.html http://mail.jabber.org/pipermail/standards/2006-May/011417.html http://mail.jabber.org/pipermail/standards/2006-June/011496.html http://mail.jabber.org/pipermail/standards/2006-June/011572.html This is essentially publish+configure all over again, but limited to the access model. However, IMHO, the following example stanza would fit better with the rest of the protocol. That would make it easier for developers, since they could simply reuse their existing configure/ element processing code: iq from='[EMAIL PROTECTED]/balcony' type='set' id='create-presence' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='http://jabber.org/protocol/activity' item activity xmlns='http://jabber.org/protocol/activity' relaxing partying/ /relaxing text xml:lang='en'My nurseapos;s birthday!/text /activity /item /publish configure x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#access_model' optionvaluewhitelist/value/option /field /x /configure /pubsub /iq I stress that the functionality associated with the above example would be absolutely identical to that which Peter described above. Right. It's publish+configure. Again. Do you think we'll make more progress this time? Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
[Standards] RC2 of bis drafts
As previously mentioned, I provisionally removed server dialback from rfc3920bis in preparation for moving that documentation to a XEP: http://www.xmpp.org/extensions/inbox/dialback.html Unfortunately, the Council has not yet approved publication of the server dialback proto-XEP. Therefore I cannot submit version -03 of rfc3920bis to the IETF until after the next Council meeting, which means I will miss the IETF's July 09 deadline, which means the -03 versions won't be published until at least July 23 (at the soonest). However, this isn't necessarily a bad thing, because before submitting these drafts to the IETF I'd like to re-read them at least one more time and compare them to the marked-up paper copies I used for editing. If you too would like to read these drafts before they are submitted, I have posted RC2 files here: http://www.xmpp.org/internet-drafts/draft-saintandre-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
Re: [Standards] private storage revisited
Thanks for the helpful post, Ralph. Comments inline. Ralph Meijer wrote: First of I want to restate the issue: the publisher wants to publish an item to a node that has a certain access model. There are two ways to solve this: 1. No auto create. In this case, there is no magical node creation on publish. A publish to a non-existing node fails, the client will create a node with the desired configuration and then republishes. I agree with you that this is fine behavior. But we let auto-create sneak in last year and people don't want to let go of it now... 2. Auto create. Here, as long as all nodes are to be created equal, with the default configuration, all is well. However, if you are having a service that hosts both extended presence nodes and private access nodes, you will want to have different configurations for the nodes that are created automatically on publish. Obviously you can check before each publish, but that is undesirable for various reasons. snip/ I still oppose the idea of publish+configure because it is not what it seems. What we want is this: on publish, if the node exists, only process the request if the node has this access model, or, if the node does not exist, create a node that has this access model. Correct. So whatever you would add to the request, doesn't actually (re-)configure the node. It is some kind of precondition for the publish request to succeed. The auto node creation is a side effect. Also correct. But having the one-trick pony of an attribute for the access model feels icky to me. What if we do allow the publisher to attach a form with 'publishing options', 'publishing conditions', or whatever we want to call them? Something not called configure/. That seems acceptable to me, because as you say it's not really a configuration. And people seem to be interested only in access models, not in configuring every possible option (at least for now as you say). For now we would only have a check on the access model in there. But it does leave the door open for future enhancements. Though probably *not* every possible configurable option (friendly name of the node, default language, or whatever). Ian seemed to agree on this idea. Great. I do want to note that prefer 1) from above more, but if we have 2), like we do now, I think this is the next best thing. Or the next-least-worst thing. ;-) 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://jabber.org/protocol/activity' relaxing partying/ /relaxing text xml:lang='en'My nurseapos;s birthday!/text /activity /item /publish preconditions x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#access_model' optionvaluewhitelist/value/option /field /x /preconditions /pubsub /iq If the node exists and the precondition is not met (in this case, if the access model is something other than whitelist), then the publish fails with a suitable error condition (probably conflict/ along with some pubsub-specific condition). If the node exists and the precondition is met, then the publish succeeds. If the node does not exist, then the service auto-creates the node with default configuration in all 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 Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
Since poke (or buzz) is usually just implemented on any service or client as your message window jittering around on the recipient's desktop like a toddler who's just drunk a venté espresso, people tend to send a message, then hit poke. I guess we can't call it poke, since that's already taken by XEP-0132. But buzz is fine with me unless it's trademarked by one of the existing IM services -- attention is kind of boring if you ask me. ;-) Most clients just call it 'buzz' that I've seen, since on some it makes a buzzing noise, and even if not the window jittering around rapidly looks a bit like a buzzer going off. -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0115 is harmful and should be deferred
On Saturday 07 July 2007 02:04, Peter Saint-Andre wrote: 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. To point out the obvious, there are two non-circular solutions: 1. Assume that caps is present and make PEP depend on caps (current option) It's the current option because it's reality. But of course. It's reality because it was the option which was chosen. Daniel pgpG9cIvrmEEF.pgp Description: PGP signature
Re: [Standards] XEP-0115 is harmful and should be deferred
On Friday 06 July 2007 22:19, Kevin Smith wrote: On 6 Jul 2007, at 13:06, Daniel Noll wrote: But mobile client users and authors are still going to object to receiving data they didn't ask for, especially if it's the same size as what was already being sent in the presence. :-) Remember that if the server supports the caps optimisation you'll only receive caps when it changes, because it'll be stripped out of subsequent presence packets to you. He'll still get a cap flood on login though, unless we can optimise that too. But I suspect mobile users will eventually use gateway tricks to reduce their bandwidth instead of relying on specs being tailored for their requirements. As time goes forward, more people's mobiles are on unlimited data accounts, and their bandwidth is increasing (256k on a phone is doable by EDGE, which is not even considered to be 3G.) The importance of saving bandwidth for the few guys not on thse plans will be like optimising a web site for a 56k modem user -- nobody will even think about it, and they probably shouldn't. Daniel pgpU0eCXfneVz.pgp Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Getting a User's Attention
On Saturday 07 July 2007 01:55, Peter Saint-Andre wrote: If the message contains only the attention element (as it certainly should), then the recipient can simply ignore it. It's not necessary to return an error, IMHO. To some extent though I'd like to know if I prod someone whose client claimed to support the feature, and for some reason they don't get prodded. On the other hand you can solve the same problem by telling some users you support it and other users you don't. So those other users don't even get the button in the first place. Daniel pgpsZRDr7lo3U.pgp Description: PGP signature
