Re: [Standards] UPDATED: XEP-0184 (Message Receipts)
XMPP Extensions Editor píše v St 31. 03. 2010 v 17:57 -0500: > > ... > > URL: http://xmpp.org/extensions/xep-0184.html > Hi. The HTML seems to not have been updated. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)
Peter Saint-Andre píše v Čt 11. 02. 2010 v 19:42 -0700: > On 2/11/10 5:29 PM, Jiří Zárevúcky wrote: > > XMPP Extensions Editor píše v Čt 11. 02. 2010 v 18:06 -0600: > >> Version 0.10 of XEP-0234 (Jingle File Transfer) has been released. > >> > >> Abstract: This specification defines a Jingle application type for > >> transferring files between two entities. The protocol provides a > >> modular framework that enables the exchange of information about > >> the file to be transferred as well as the negotiation of parameters > >> such as the transport to be used. > >> > >> Changelog: Described the file retrieval case; updated referenced > >> namespaces. (psa) > >> > >> Diff: see http://xmpp.org/extensions/diff/ > >> > >> URL: http://xmpp.org/extensions/xep-0234.html > >> > > > > The XEP has the same flaw as the original File Transfer. It sends > > the file's hash before the transfer, > > Says who? The 'hash' is not mandatory in the schema from XEP-0096: > > > Yes. What I mean is the case when I do want to send the hash. > > which means the sender needs to > > hash the file first (potentially very time-consuming). If the > > transfer is terminated, the receiver won't use it anyway. > > > > Allowing the hash to be sent after the transfer is finished would > > allow the sender to hash it while sending, making it much more > > convenient and usable feature. > > We could certainly define a jingle-info payload to communicate the hash > after the fact, and add some text about leaving the hash out of the offer. > That would be great. > Peter > signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)
XMPP Extensions Editor píše v Čt 11. 02. 2010 v 18:06 -0600: > Version 0.10 of XEP-0234 (Jingle File Transfer) has been released. > > Abstract: This specification defines a Jingle application type for > transferring files between two entities. The protocol provides a modular > framework that enables the exchange of information about the file to be > transferred as well as the negotiation of parameters such as the transport to > be used. > > Changelog: Described the file retrieval case; updated referenced namespaces. > (psa) > > Diff: see http://xmpp.org/extensions/diff/ > > URL: http://xmpp.org/extensions/xep-0234.html > The XEP has the same flaw as the original File Transfer. It sends the file's hash before the transfer, which means the sender needs to hash the file first (potentially very time-consuming). If the transfer is terminated, the receiver won't use it anyway. Allowing the hash to be sent after the transfer is finished would allow the sender to hash it while sending, making it much more convenient and usable feature. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: [Standards] XEP-0136 modifications
Yann Leboulanger píše v Ne 17. 01. 2010 v 18:28 +0100: > Yann Leboulanger wrote: > > Hi all, > > > > Alexander Tsvyashchenko and I discussed changes in XEP-136, and we wrote > > them in the XEP. Attached is a diff of the xep-0136.xml, and you can > > see the result here: > > www.lagaule.org/xep/xep-0136.html > > > > What do you think about that? > > Comments are appreciated! > > > > > > Is this list the correct place to propose changes to XEPs? Is there > another mailing list for that? or a bug tracker? > > Thanks It is the right place, but sometimes it may take quite a long time for someone to respond. Especially when it's not about some important problem. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: [Standards] NEW: XEP-0273 (Stanza Interception and Filtering Technology)
On 09/17/2009 04:15 AM, Justin Karneges wrote:
On Wednesday 16 September 2009 18:23:32 Robert Quattlebaum wrote:
mobile clients a way to silence incoming presence ("presence hush"),
and give them a way to rebuild the presence state of their roster
quickly and efficiently when presence it is actually needed. The first
part is easy if your server supports privacy lists, but there is no
easy way to rebuild the presence state when you are actually
interested in it. (about the only way is to send out a presence probe
to everyone on your roster. Horrible.)
I always figured that as soon as you change the privacy lists to unblock
presence, then the server should immediately deliver the latest presence of
the unblocked jids. But maybe privacy lists aren't meant to be that smart.
I personally don't think brainless on/off stanza filtering is all that useful.
For the filtering use-cases people actually want, such as
invisible/visible/away-to/etc lists, and various optimized deliveries over
mobile, we need the server to be smarter.
-Justin
This isn't stated explicitly in the privacy lists XEP, but it makes
perfect sense. The feature wouldn't be quite that useful without it,
would it?
But privacy lists (in my opinion) can't cope with some real-world
problems and needs nowadays. That's why I think it should be redone from
scratch and with everyone's concerns in consideration. I don't think
there are usable client-side implementations anyway.
I will have some time, so I may try writing something if more people
agree with me.
Re: [Standards] NEW: XEP-0273 (Stanza Interception and Filtering Technology)
On 09/15/2009 05:36 PM, XMPP Extensions Editor wrote: Version 0.1 of XEP-0273 (Stanza Interception and Filtering Technology) has been released. Abstract: This specification defines an XMPP protocol extension that enables a client to exercise control over the XML stanzas it will receive from the server by instructing the server to intercept and filter inbound stanzas. Changelog: Initial published version as accepted for publication by the XMPP Council. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0273.html I'm not convinced we really need this (at least in it's current form). 1) Some functionality overlaps with privacy lists. 2) Payload matching could be much more simple if done in tandem with disco#info. No need for entire new extension for that. Some could argue about the extended matching, but I personally don't see the need (client either supports the namespace or it doesn't, where's the benefit of server-side extended filtering except making them crash under load more often?). 3) Overloading empty SIFT query to mean "Make me available for messaging" is evil. 4) Overall, the extension seems to me like an amalgam of would-like solutions then a compact extension solving a single issue. Personally, I'd see bigger benefit in re-doing privacy lists with current real-world requirements in mind.
Re: [Standards] XEP-0237 Roster Versioning question
2009/7/18 Tomasz Sterna : > On wto, 2009-07-14 at 13:21 -0600, Peter Saint-Andre wrote: >> Agreed -- there is no harm if the server always includes 'ver'. I'll >> update the spec to say that. > > We once banned non-standard subelements from roster items > and now wish to allow non-standard ver attribute? > > Isn't it a bit hypocritical? > > > If it was in a separate namespace, there would be no doubt it is > allowed. But it isn't. > > Roster versioning is intended for inclusion to XMPP-IM.
Re: [Standards] Initial presence. Was Roster changes
2009/7/17 Pedro Melo :
> Hi,
>
> On 2009/07/16, at 14:14, Jiří Zárevúcky wrote:
>
>> I think there is one way to really solve the issue in question.
>>
>> As I understand it, the problem is that when user logs it, he doesn't
>> know whether the contact is online or not. Sending all presences
>> together is not an option, as it would require waiting for all the
>> probes to respond.
>>
>> Now, I'm not exactly sure how this works with server implementations,
>> but my guess is that the once the s2s connection is established (which
>> can vary widely for every server) all the probes (should) get
>> processed and returned in a relatively short timespan.
>>
>> What we need to do, is to make client aware that he has received all
>> the delayed presences from a particular domain.
>> It would then be possible to display contacts with some sort of
>> "waiting" state, so the user knows whether the contact in question is
>> offline, or the s2s connection just didn't get through yet.
>>
>> All in all, this could be very simply defined in a short XEP.
>
> Several people pointed out that this problem is already solved with
> jabber::delay. So far you didn't seem to acknowledge it either positively
> ("yes it might solve the problem") or negatively ("no it doesn't solve the
> problem because of X, Y and Z").
>
> Before start Yet Another XEP, can you tell me why do you think that
> jabber:x:delay is not an option?
>
> Thanks in advance,
Several people lack the understanding of the problem Jonathan was
trying to solve.
The original problem is that when you connect, you see everyone
offline. Even if they are online, you may have to wait several minutes
to see it under some circumstances.
If you connect just to quicky check someone's availability, you have a
problem, because you can't be entirely sure of him *not* being
available unless you actually open an XML console of your client and
send a probe yourself (and that only for some implementations anyway).
Delay only solves the problem of distinguishing delayed and live
presences.
The way it works now can be lived with, but I've stumbled several
times over this particular problem (as a user) and even though it
doesn't affect me often, it's very annoying when it does.
As a side note, jabber:x:delay is not an option because it's obsolete. ;-)
Re: [Standards] Initial presence. Was Roster changes
I think there is one way to really solve the issue in question. As I understand it, the problem is that when user logs it, he doesn't know whether the contact is online or not. Sending all presences together is not an option, as it would require waiting for all the probes to respond. Now, I'm not exactly sure how this works with server implementations, but my guess is that the once the s2s connection is established (which can vary widely for every server) all the probes (should) get processed and returned in a relatively short timespan. What we need to do, is to make client aware that he has received all the delayed presences from a particular domain. It would then be possible to display contacts with some sort of "waiting" state, so the user knows whether the contact in question is offline, or the s2s connection just didn't get through yet. All in all, this could be very simply defined in a short XEP.
Re: [Standards] UPDATED: XEP-0260 (Jingle SOCKS5 Bytestreams Transport Method)
Section 2.3 "3. If both parties send a candidate-used notification but the candidates have a different priority, then the candidate with the lower priority shall be considered the nominated candidate." Shouldn't the candidate with *higher* priority be nominated?
Re: [Standards] Roster changes
2009/7/15 Peter Saint-Andre : > > On 7/15/09 9:12 AM, Jiří Zárevúcky wrote: > >> We probably first need to sum up the additional functionality we'd >> want in roster management. >> Arbitrary attached XML is the first and obvious one, which wouldn't >> even require a new protocol. > > Correct! The "X" in XMPP stands for "extensible". :) So maybe we need a > service discovery feature for roster extensions and away we go. No need > for a redesign of jabber:iq:roster at that point! > You've got a point. But let's look at this from another perspective. XMPP-IM doesn't dictate jabber:iq:roster has to be used, right? Then there is nothing wrong if a few people with a lot of free time write a purely experimental XEP defining a new way to access and manage roster. Developers who like the idea could just play with it... no obligations for anyone else. :) Well, that's the theory, anyway. The question is whether more people would be interested in such experiment. :) >> Are there any other functionalities we may want? Perhaps some more >> sophisticated handling including JID and group filtering, etc. I think >> I saw something about some "roster activation" here. What was that >> about? > > The requirements for such features are quite nebulous, IMHO. If someone > cares about them, they can work to define them more clearly. I agree with that. > At the > moment I don't feel there are any truly compelling use cases here, but I > freely admit that I might be wrong because I haven't thought about it in > detail yet. > > The "roster activation" idea is an optimization for mobile environments > that we talked about at XMPP Summit 6 earlier this year. Refer to the > list archives for a bit more insight into what that might mean. > > Peter > Yes, I will. Thanks. :)
Re: [Standards] Roster changes
2009/7/15 Peter Saint-Andre : > On 7/15/09 8:53 AM, Jiří Zárevúcky wrote: >> 2009/7/15 Peter Saint-Andre : >>> On 7/15/09 8:44 AM, Jiří Zárevúcky wrote: >>>> The only objectively >>>> "broken" thing is probably just the fact you can't be sure about the >>>> existence of incoming subscription request (if declined by a different >>>> resource, you have no idea it happened). >>>> >>>> Subjectively, roster (and subscription handling as a whole) was the >>>> single most annoying thing I've implemented so far, including MUC, >>>> data forms, file-transfer, etc. It's my subjective personal opinion, >>>> though, so you can freely ignore it. >>> I never said that the roster+presence functionality is beautiful, >>> simple, or easy to implement -- only that it has worked for 10 years, so >>> I think we need to be very careful about designing something new and >>> backward-incompatible at this stage. >>> >>> Peter >>> >> >> Well, it may be completely different, but I think backwards >> compatibility wouldn't be a problem. By creating a new protocol with >> different namespace, we would essentially be adding a new interface, >> not replacing the new one. Then it's simply a matter of client >> choosing the interface to use for it's session. > > Right. But then clients and servers need to implement two similar but > different protocols for almost exactly the same functionality. Is this > really worth all the time and effort and confusion involved? > > Peter > That's what we need to find out, isn't it? We probably first need to sum up the additional functionality we'd want in roster management. Arbitrary attached XML is the first and obvious one, which wouldn't even require a new protocol. Are there any other functionalities we may want? Perhaps some more sophisticated handling including JID and group filtering, etc. I think I saw something about some "roster activation" here. What was that about?
Re: [Standards] Roster changes
2009/7/15 Peter Saint-Andre : > > On 7/15/09 8:44 AM, Jiří Zárevúcky wrote: >> The only objectively >> "broken" thing is probably just the fact you can't be sure about the >> existence of incoming subscription request (if declined by a different >> resource, you have no idea it happened). >> >> Subjectively, roster (and subscription handling as a whole) was the >> single most annoying thing I've implemented so far, including MUC, >> data forms, file-transfer, etc. It's my subjective personal opinion, >> though, so you can freely ignore it. > > I never said that the roster+presence functionality is beautiful, > simple, or easy to implement -- only that it has worked for 10 years, so > I think we need to be very careful about designing something new and > backward-incompatible at this stage. > > Peter > Well, it may be completely different, but I think backwards compatibility wouldn't be a problem. By creating a new protocol with different namespace, we would essentially be adding a new interface, not replacing the new one. Then it's simply a matter of client choosing the interface to use for it's session.
Re: [Standards] Roster changes
2009/7/15 Jonathan Schleifer : > Remko Tronçon wrote: > >> IMO, that would needlessly complicate things (duplicated >> functionality/information/...) at virtually no gain. >> >> cheers, >> Remko > > There _IS_ a gain: You won't get presences every few seconds for the 5 > minutes after you logged in which spam your desktop with notifications > etc. Very, very annoying IMO. Initial presences should come all at > once, IMO, so the client doesn't need to show a notification for > initial presences. Just waiting for 30 secs like Gajim does doesn't > work for me, as it takes 5 minutes until I see all presences (which > SUCKS!). > > -- > Jonathan > I agree with Jonathan. Presence flood is VERY annoying. It may not be by including in the roster (that would indeed not be possible for versioned one), but it needs to be solved sooner or later.
Re: [Standards] Roster changes
2009/7/15 Peter Saint-Andre : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 7/15/09 8:18 AM, Jiří Zárevúcky wrote: >> 2009/7/15 Pedro Melo : >>> Hi, >>> >>> On 2009/07/15, at 08:36, Kevin Smith wrote: >>> >>>> While we're discussing upgrading roster handling, can I put my request >>>> in for hanging arbitrary xml off the roster entries, please? >>> Thats the only reason I could come up with to justify changing namespaces. >>> And I think that when Joe mentioned "it would give us a chance to define an >>> extensibility model" this is one of the things that would fallback naturally >>> from such model. >>> >>> The question as always is of scope: do we just make jabber:iq:roster a >>> little bit more liberal and use it for rosters from gateways, or do we go >>> the whole nine yards and create a new roster protocol. >>> >>> I think that creating a new protocol for rosters is something that takes >>> time, and the problem of gateway roster would still be messy until then. >>> >>> I say we fix what the known problem is right now, gateway interaction, by >>> allowing the use of jabber:iq:roster and roster versioning with multiple >>> entities. >>> >> >> I'd say we could do both. Fix the pressing problem now, but start >> designing an entirely new protocol. > > What is "the pressing problem"? > >>> I would love to have XML annotations on roster items, it would solve a lot >>> of with meta-contacts, and other uses cases (personal notes on contacts like >>> "remind me to ask kev for an update on his new client ;)", or alarms "when >>> remko logs on, ask him if the client is coming along"). >>> >>> But how to do it would be a big discussion: would it be possible to just >>> define a new PubSub profile and be done with it? >> >> It's possible I guess, but creating a new roster protocol could have >> another advantages. >> >> For example, the current one doesn't communicate the full state. For >> pending-in, you have to listen for presences and client even has to >> guess the state sometimes. >> >> The presence subscription handling using presence stanzas is another >> thing I always considered quite weird. > > Look, folks, this is a major redesign of core XMPP functionality. I > think we need to tread very very carefully here. What *exactly* is truly > broken (as opposed to not aesthetically pleasing)? What problems are you > trying to solve that are not solved with jabber:iq:roster? Etc. > > Peter > I'm just pointing out my personal opinion. The only objectively "broken" thing is probably just the fact you can't be sure about the existence of incoming subscription request (if declined by a different resource, you have no idea it happened). Subjectively, roster (and subscription handling as a whole) was the single most annoying thing I've implemented so far, including MUC, data forms, file-transfer, etc. It's my subjective personal opinion, though, so you can freely ignore it.
Re: [Standards] Roster changes
2009/7/15 Pedro Melo : > Hi, > > On 2009/07/15, at 08:36, Kevin Smith wrote: > >> While we're discussing upgrading roster handling, can I put my request >> in for hanging arbitrary xml off the roster entries, please? > > Thats the only reason I could come up with to justify changing namespaces. > And I think that when Joe mentioned "it would give us a chance to define an > extensibility model" this is one of the things that would fallback naturally > from such model. > > The question as always is of scope: do we just make jabber:iq:roster a > little bit more liberal and use it for rosters from gateways, or do we go > the whole nine yards and create a new roster protocol. > > I think that creating a new protocol for rosters is something that takes > time, and the problem of gateway roster would still be messy until then. > > I say we fix what the known problem is right now, gateway interaction, by > allowing the use of jabber:iq:roster and roster versioning with multiple > entities. > I'd say we could do both. Fix the pressing problem now, but start designing an entirely new protocol. > I would love to have XML annotations on roster items, it would solve a lot > of with meta-contacts, and other uses cases (personal notes on contacts like > "remind me to ask kev for an update on his new client ;)", or alarms "when > remko logs on, ask him if the client is coming along"). > > But how to do it would be a big discussion: would it be possible to just > define a new PubSub profile and be done with it? > It's possible I guess, but creating a new roster protocol could have another advantages. For example, the current one doesn't communicate the full state. For pending-in, you have to listen for presences and client even has to guess the state sometimes. The presence subscription handling using presence stanzas is another thing I always considered quite weird. > Best regards, >
Re: [Standards] XEP-0237 Roster Versioning question
2009/7/14 Tomasz Sterna : > On pon, 2009-07-13 at 15:42 -0600, Peter Saint-Andre wrote: >> Whether or not the roster has been modified since the version >> ID enumerated by the client, the server MUST either return the >> complete roster as described in RFC 3921 (including a 'ver' >> attribute that signals the latest version) or ... > > Peter, > I don't want to be picky, but this raises a question: > - Where should I put the 'ver' attribute? > > This is a technical document after all, so it should be strict and leave > no place for doubt. Even at the cost of over explaining. > > I agree specs should be strict, but someone not capable of deducing this actually implementing the spec? That is a ridiculous idea (considering all the examples).
Re: [Standards] XEP-0237 Roster Versioning question
2009/7/11 Tomasz Sterna : > I am implementing XEP-0237 in jabberd2 and I have a question. > > """ > 2.3 Server Response > Whether or not the roster has been modified since the version ID > enumerated by the client, the server MUST either return the complete > roster as described in RFC 3921 or return an empty IQ-result [...] > """ > > How do I send to the client current roster version when sending complete > roster? > I guess I should add ver attribute to the iq-result query item, but that > is only a guess. > A correct one. Seems the example on full result has been left out. Maybe it needs a sentence or two about that.
Re: [Standards] none + pending in
2009/7/10 Me Self : > > It looks like the explanation of "None+ Pending in" has been moved to > appendix A.1 in bis and it now reads: > > ""None + Pending In" = contact and user are not subscribed to each other, > and contact has sent user a subscription request but user has not replied > yet (note: contact's server SHOULD NOT push or deliver roster items in this > state, but instead SHOULD wait until user has approved subscription request > from contact); this is reflected in the user's roster by subscription='none' > " > > The wording has been changed but its not really clearer. The whole concept > of storing pending requests in the roster still seems very vague to me (but > admittedly I have only skimmed the new bis). In the old RFC 3921 the concept > was introduced in parenthesis (quoted in my first post) which was a bit > vague but now that the line has been removed it seems Im left with a lot > more guessing here. From the new bis I can deduct from appendix A.1 that > pending request are stored in the roster but its not obvious and I think the > bis could use a separate chapter to introduce the concept. Its not obvious > to store pending requests in the roster because roster items and pending > request are not sent at the same time. Roster items are sent as reply to > "roster get" and pending items are sent when the users becomes "available" > after sending initial presence to the server. On top of that I cant > interpret A.1 in the new bis any other way than it prevents roster items > from being sent in reply to "roster get" when the state is "None + Pending > in" which still means that an existing item that was previously visible when > it was just "None" now has become hidden because a request from a contact > has put it in a pending state. > Roster always stores the subscription state, which is now "none". How you store the actual request is up to you. That kind of implementation details do not reflect in the network, so that is not the kind of stuff the spec can dictate. The only think you need to know is that the item is "hidden" to the user until the subscription is approved or the item is explicitly added by the user. That's all you need to know to implement it. How exactly you do it doesn't matter here.
Re: [Standards] none + pending in
Hello Søren. Seems you are referring to the old version of the spec. Look at recent http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-00.html , many things are explained much more clearly there.
Re: [Standards] UPDATED: XEP-0051 (Connection Transfer)
2009/7/8 XMPP Extensions Editor : > Version 0.2 of XEP-0051 (Connection Transfer) has been released. > > Abstract: This specification defines an XMPP protocol extension that enables > a server to redirect connections from one connection manager or server node > to another. > > Changelog: Rewritten to focus on the connection transfer use case only. (fj) > > Diff: > http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0051.xml?%40diffMode=u&%40diffWrap=s&r1=320&r2=3312&u=3&ignore=&k= > > URL: http://xmpp.org/extensions/xep-0051.html > > Wow, this is really old spec... and I think not really useful. see-other-host stream error does the exactly same job.
Re: [Standards] Issue tracker for XEPs?
2009/7/7 Peter Saint-Andre : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 7/7/09 1:06 PM, Kevin Smith wrote: >> 2009/7/7 Peter Saint-Andre : > Sure. Indeed I prefer it. I just figured I'd test the issue tracker > since that's what the IETF Tools Team has given us. :) Have you thought about setting up an issue tracker for XEPs? I think it would be very nice. Various small problems can get easily forgotten and lost in the amount of emails posted in threads dedicated to bigger ones. >>> We have a license from Atlassian for FishEye, so I'm sure we could use >>> Jira for that. Want to help set it up? :) >> >> I've just set Jira up at work, I'm happy to give it a go if you want. > > Sure, sounds good. Thanks! > > Peter > I'd also be glad to help, in case there is something I can help with. :) But as it seems quite easy for one person and I have no experience with it, I'll probably help more just by filling it. :D
[Standards] Issue tracker for XEPs?
Dne 7. červenec 2009 20:42 Peter Saint-Andre napsal(a): > >> btw, is it OK to respond to the tickets on this list instead of >> commenting them directly? > > Sure. Indeed I prefer it. I just figured I'd test the issue tracker > since that's what the IETF Tools Team has given us. :) > > Peter > Have you thought about setting up an issue tracker for XEPs? I think it would be very nice. Various small problems can get easily forgotten and lost in the amount of emails posted in threads dedicated to bigger ones.
Re: [Standards] Last Activity in initial presence
2009/7/2 Marcus Lundblad : > ons 2009-07-01 klockan 15:56 -0600 skrev Peter Saint-Andre: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 7/1/09 3:51 PM, Peter Saint-Andre wrote: >> > XEP-0256 talks about including last activity in auto-away notifications, >> > which means "I'm away at this resource and I was last active at time T." >> > >> > Another possible use case is including last activity in initial >> > presence, which would mean "I'm newly online and I was last online from >> > this resource at time T." >> > >> > The attraction here is that pubsub and PEP nodes to which you subscribe >> > might be able to optimize item delivery (e.g., by sending you only the >> > items that were published after you went offline the last time, give or >> > take a few minutes). The same might be true of MUC room history (I am >> > growing tired of receiving messages from yesterday when I join a quiet >> > room). >> >> http://xmpp.org/extensions/tmp/xep-0256-1.1.html > > This would kinda break the way I interpreted 0256. > That way, if say the client goes idle, it'll send an updated presense > with a "last" with seconds='300'. > Then later the client looses its connection with the server, after say > an hour, then a minute later goes online again (still idle). Now the > initial presence will have a "last" with seconds='3960' (give or take a > few seconds. > This does not mean it was last online over an hour ago, it was online a > minute ago (though being idle). > I'd suggest that the last activity in initial presence again means just last activity. Contact doesn't really need to know whether it was last online time or last mouse movement.
Re: [Standards] Last Activity in initial presence
2009/7/2 Peter Saint-Andre : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 7/1/09 4:18 PM, Jiří Zárevúcky wrote: >> 2009/7/2 Peter Saint-Andre : >>> On 7/1/09 4:07 PM, Jiří Zárevúcky wrote: >>>> 2009/7/1 Peter Saint-Andre : >>>>> The same might be true of MUC room history (I am >>>>> growing tired of receiving messages from yesterday when I join a quiet >>>>> room). >>>>> >>>> There is a mechanism to do this in MUC (see section 7.1.16 of >>>> XEP-045). The problem here is more likely to be the fact that the >>>> possibility to use it this way didn't occur to client implementors. >>>> Funny, actually. To me neither. >>> There is such a mechanism in MUC, but AFAIK it's not implemented anywhere. >>> >>> Peter >>> >> >> Well, in that case there is no reason to assume the new approach will >> be implemented promptly. I think all it takes is a few devs demanding >> the feature. > > I think the PubSub and PEP possibilities are more pressing than MUC, but > they are basically the same idea anyway... > Yes, of course. Maybe, for the sake of using the same system everywhere, we should remove the "since" attribute from MUC spec. Maybe "seconds", too, since I don't see any practical usefulness. Never mind that, I'll bring the topic back once there is something going on around MUC again.
Re: [Standards] Last Activity in initial presence
2009/7/2 Peter Saint-Andre : > > On 7/1/09 4:07 PM, Jiří Zárevúcky wrote: >> 2009/7/1 Peter Saint-Andre : >>> The same might be true of MUC room history (I am >>> growing tired of receiving messages from yesterday when I join a quiet >>> room). >>> >> >> There is a mechanism to do this in MUC (see section 7.1.16 of >> XEP-045). The problem here is more likely to be the fact that the >> possibility to use it this way didn't occur to client implementors. >> Funny, actually. To me neither. > > There is such a mechanism in MUC, but AFAIK it's not implemented anywhere. > > Peter > Well, in that case there is no reason to assume the new approach will be implemented promptly. I think all it takes is a few devs demanding the feature.
Re: [Standards] Last Activity in initial presence
2009/7/1 Peter Saint-Andre : > The same might be true of MUC room history (I am > growing tired of receiving messages from yesterday when I join a quiet > room). > There is a mechanism to do this in MUC (see section 7.1.16 of XEP-045). The problem here is more likely to be the fact that the possibility to use it this way didn't occur to client implementors. Funny, actually. To me neither.
Re: [Standards] Anonymous SASL and Presence
2009/6/30 Eloi Bail : > To authenticate to a XMPP server, I must implement encryption. I wanted to > test without it, to have a XMPP client as light as possible... > I have to go strait to SASL with encryption so... > Thanks for your reply ! > Eloi > Nope, you don't need to. You can connect without TLS and with PLAIN SASL authentication. Some servers don't enable such combination, so you have to find one that doesn't enforce secure password transfer.
Re: [Standards] Anonymous SASL and Presence
2009/6/30 Eloi Bail : > Thanks for your reply... > As I understood, if I want to push my presence, I have to send a stanza for > each JID because XMPP servers can not route my presence (because roster > empty)... which is not very great :( > So I guess, I have to use encryption SASL, to have a not random JID and so > push only one time my presence. > Right ? > > Eloi > I don't quite understand what are you asking. If you need an XMPP account for normal communication, you will register it and authenticate with your registered JID and password. Anonymous authentication is kinda special-purpose one-time thing. You'll generally not need to send any presences with it, except perhaps a few directed ones...
Re: [Standards] Anonymous SASL and Presence
2009/6/30 Dave Cridland : > On Tue Jun 30 16:20:25 2009, Jiří Zárevúcky wrote: >> >> 2009/6/30 Dave Cridland : >> > On Tue Jun 30 15:33:35 2009, Matthew Wild wrote: >> >> >> >> It does. Anonymous users get given a unique (~random) JID, with an >> >> empty roster. So you /can/ send presence, you just either have to send >> >> it to a known address, or add people to your temporary roster first. >> > >> > FWIW, although I agree that's what *should* happen, nothing in the >> > specifications available says that's what does. >> > >> >> Actually, XMPP-IM does. At least for broadcasts as long as roster is >> enabled. Of course the roster may be disabled. Routing of directed >> presences is not strictly required, too. > > No, I meant the "unique (~random) JID", and the "empty" or "temporary > roster". None of those things are specified. > There is nothing that would classify "random JID" as something special. The same applies to "empty" and "temporary" roster. And you can't say rules of XMPP-IM don't apply to them. > What happens if you have a roster is, of course, specified. >
Re: [Standards] Anonymous SASL and Presence
2009/6/30 Dave Cridland : > On Tue Jun 30 15:33:35 2009, Matthew Wild wrote: >> >> It does. Anonymous users get given a unique (~random) JID, with an >> empty roster. So you /can/ send presence, you just either have to send >> it to a known address, or add people to your temporary roster first. > > FWIW, although I agree that's what *should* happen, nothing in the > specifications available says that's what does. > Actually, XMPP-IM does. At least for broadcasts as long as roster is enabled. Of course the roster may be disabled. Routing of directed presences is not strictly required, too.
Re: [Standards] [xmpp] Modifying the schema for auth(RFC 3920)
2009/6/23 Joe Hildebrand : > Moving the discussion to the XMPP working group mailing list since this is > RFC-related. > > It looks like Google's docs for this are here: > > http://code.google.com/apis/talk/jep_extensions/jid_domain_change.html > > Should the client just use this bare JID the next time it logs in? If so, we > may need to make a change to 3920bis to make this clear. If we're > contemplating making a change in -bis, we should make the correct one, not > just loosen up the schema. In my opinion, this is a pretty Google-specific problem. In normal XMPP world, user account is strictly defined by the combination of node identifier and domain name. This google "extension" allows user to log in with different domain, then the one user registered with. If we are to modify the spec about this, we must also allow one account to have multiple JIDs, which in turn would require a way to retrieve all the account's aliases (for the proper handling on another servers), along with proper security considerations and so on... > > Of course, in your implementation, there's nothing that says you can't use > any schema you like to do validation, since validation is not required and > the schemas are non-normative. > IMHO, validation is completely useless on an XMPP server. It just slows it down and possibly breaks it on any unexpected input. The server should handle the communication as long as there is everything needed. Not kick client in the butt for something that shouldn't be here. > -- > Joe Hildebrand > > > > > From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On > Behalf Of Mittal Thakkar > Sent: Tuesday, June 23, 2009 12:43 AM > To: standards@xmpp.org > Subject: [Standards] Modifying the schema for auth(RFC 3920) > > Hi, > > The clients using the libpurple 2.6.x like Adium and Pidgin sends the > following stanza for auth : > xmlns:ga='http://www.google.com/talk/protocol/auth' > ga:client-uses-full-bind-result='true'/>. > At our server xml parsing fails as in the schema for auth it supports only > one attribute ie. mechanism. wrt. Appendix C.4 of RFC 3920. > > Is it valid if we allow any attribute( of other namespace ) for the > as RFC is silent about it. The schema we want to use is as follows: > > > > > > type='xs:string' > use='optional'/> > > > > > > > > -- > Thanks, > Regards, > Mittal Thakkar > ___ > xmpp mailing list > x...@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp >
Re: [Standards] Wording JID, FullJid, baseJID,...
2009/6/22 Bernhard zwischenbrugger : > > PS: I'm teaching that things and must be very correct. > As all the other questions have been answered, I'd just like to ask one. Why are you teaching something you don't fully understand?
Re: [Standards] reliable messaging
2009/6/17 Remko Tronçon : >> It's possible, I suppose, that the remote client went offline before the >> , and came back online after, just in time to get the , but >> it seems terribly unlikely, especially as you'd also see a >> update as it came back online. > > Well, there's not much worse than a reliable messaging protocol that isn't > 100% reliable. If there's the slightest possibility that this fails (e.g. > client going offline and coming online with the same resource, and for some > reason the presence doesn't get through), then it shouldn't be used as a way > to acknowledge receipt. > But it can be used quite well to report error when it is sure. Client can wait a few seconds for any activity from the other side, then report that the other party doesn't respond and is probably unreachable. That would be usable in case the other party doesn't support receipts, but I agree it should not be use to explicitly acknowledge the delivery happened, as ping has no relation to the previous stanza. (For example the receiver can filter incoming messages and drop the message before any processing, or something similar)
Re: [Standards] XEP-0199 -- implementation notes?
2009/5/29 Justin Karneges : > > But yes, the advantage of XEP-199 is that it works with clients that may not > actually support XEP-199. :) For clients that aren't XMPP-compliant enough > to return errors from unsupported iq types, the server could use a heuristic > approach to detect such clients and then not ping them. > I don't think such clients deserve any special treatment. It will just make things complicated for everyone else. There is the RFC, nobody will ever force me to specially handle non-standard behavior because someone is lazy.
Re: [Standards] XEP-0199 -- implementation notes?
2009/5/29 Dirk Meyer : > Peter Saint-Andre wrote: >> In the XMPP Council meeting yesterday, we discussed the desirability of >> adding some implementation notes to XEP-0199 (XMPP Ping) before >> advancing it from Draft to Final. > > Stupid question: why use XEP-0199 and not from XEP-0189 > for this task? > Very simple answer: Clients not supporting the XEP will still respond with IQ error (if they are XMPP compliant, which is not the extension's problem). They wouldn't respond to some unknown "r" element. Also think of all the client that won't support XEP-189 for vry long time.
Re: [Standards] Idle sreams in RFCbis
2009/5/25 Artur Hefczyc : > Hi, > >> I would like to provide feedback on these two sections: >> >> 5.7.3. Handling of Idle Streams >> >> http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#streams-close-idle >> >> 12.7. Whitespace >> >> http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#xml-whitespace >> >> >> In 5.7.3, it says: >> "The typical method for detecting an idle TCP connection is to send a >> space >> character (U+0020) over the TCP connection between XML stanzas, which is >> allowed for XML streams as described under Section 12.7 (Whitespace)." >> >> Strictly speaking: >> - the sending entity does not detect the loss of connection when it sends >> whitespaces > > I think you are not right here. From my experience the sending entity only > can > detect connection loss not the receiving. > This is because sometimes TCP/IP doesn't get notified of simple connection > loss if there is no data transmission over the link. > Only when you attempt to send some data, even a single character, the TCP/IP > stack tries to deliver it to the destination address. Of course if the > connection > is broken, the attempt fails and an error is returned to sending > application. > > Artur > That's right, but from my experience the timeouts are waay too long to be useful.
Re: [Standards] Idle sreams in RFCbis
2009/5/25 Nicolas Vérité : > > Strictly speaking: > - the sending entity does not detect the loss of connection when it sends > whitespaces That's correct. > - the receiving entity detects the loss of connection only if it has a > mechanism that detects the absence of whitespaces Not really. It is not required to send them, so you could be terminating a live connection. Otherwise I fully agree with you. Whitespace sending is a mechanism for keepalive, not a failure detection, and certainly not a ping. I'm not sure but I think that can be done with TCP somehow? Even as a request-response mechanism. Does anyone have some experience with that?
Re: [Standards] SIFT
2009/5/18 Peter Saint-Andre : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 5/16/09 6:45 AM, Jiří Zárevúcky wrote: >> Hello. The filtering/intercepting functionality seems nice for IQ >> stanzas, but I have doubts about some of the use cases. >> >> "Invisibility" as defined by this spec would certainly ease it's >> handling by both client and server, > > Simplification is a good thing, no? (Aside from the fact that > invisibility is stupid, if we're going to support it then we might as > well support it in the simplest way possible.) > Sure. >> but is changes the meaning of >> available and unavailable presence stanzas. > > How so? > > still means "tell my contacts that I'm online". > > still means "tell my contacts that I'm > offline". > >> That means servers that >> support SIFT will understand them differently than servers that do >> not. > > Yes, SIFT separates presence probing and inbound presence delivery from > the sending of outbound presence notifications. I don't yet see any > major problems with that, because the client will discover whether the > server supports SIFT before it starts sending presence. > Well, until now I believed that "unavailable" presence doesn't mean "show me offline", but "make me unavailable for presence exchange and messaging". But you're right, it doesn't really matter. Anyway, if SIFT capable client went invisible mid-session, it could do so by sending unavailable presence. But possibly without any prior SIFT command. So I think it should be noted that either supporting client must use sift to initiate it's "SIFT based session" prior to using such invisibility, or the server must not terminate the communication availability even when there was no explicit SIFT. If it is not specified, the first possibility should be implicit for the client developer to avoid problems, but I'm afraid not everyone would realize that. >> Also, if I understand it correctly, the empty sift query means >> "don't filter anything" and not "send me all now". If you use it as an >> "on" switch, you are overloading it's functionality. > > How so? > > 1. I log in. > > 2. I discover that my server supports SIFT. > > 3. I send empty . > > 4. Server sends me offline messages and probes my contacts. > > Why does empty need to mean either "don't filter anything" or > "sync me up" but not both? > It's actually not said that the request also means "start sending everything that's not to be intercepted". It's only implied by the business rules. I think it should be added to the definition. >> The second (possible) problem is that when you use it to filter >> messages (which you can do by negative priority), your contacts >> wouldn't know it. If you have negative priority, everyone sees you >> can't receive messages. That is not the case here. I think the spec >> should at least define an error response to notify sender the entity >> can't receive messages. > > The intent is that SIFT removes the need for negative priorities. Why is > it necessary to advertise the fact that the client doesn't want to > receive messages addressed to the bare JID? And what would a contact do > wtih that information? In general we recommend that you send a message > to the bare JID when you want to initiate a chat, not send to the full > JID of a particular resource. I don't see a big (or even any) problem here. > Oh, sorry. I thought the rule applies to any message, even specifically addressed. I have to read more carefully next time. >> And to be complete, I'd appreciate an example of "excepting" multiple >> payload types for IQ's. Thanks :) > > Done in 0.0.4. > > Peter > You've forgotten to update human language "translation". :)
Re: [Standards] SIFT
2009/5/16 Dirk Meyer : > Peter Saint-Andre wrote: >> http://xmpp.org/extensions/inbox/sift.html > > I only took a quick look at the spec and maybe I missed it, but what > happens to an IQ that got filtered? If a client sends an IQ it expects > an answer and that answer maybe 'client not available'. What is the > answer if the recipient filters the IQ? > > > Dirk > I believe server should reply with "service-unavailable" on behalf of the client. That way it is consistent with XMPP-CORE and doesn't introduce any security problems.
Re: [Standards] SIFT
Hello. The filtering/intercepting functionality seems nice for IQ stanzas, but I have doubts about some of the use cases. "Invisibility" as defined by this spec would certainly ease it's handling by both client and server, but is changes the meaning of available and unavailable presence stanzas. That means servers that support SIFT will understand them differently than servers that do not. Also, if I understand it correctly, the empty sift query means "don't filter anything" and not "send me all now". If you use it as an "on" switch, you are overloading it's functionality. The second (possible) problem is that when you use it to filter messages (which you can do by negative priority), your contacts wouldn't know it. If you have negative priority, everyone sees you can't receive messages. That is not the case here. I think the spec should at least define an error response to notify sender the entity can't receive messages. And to be complete, I'd appreciate an example of "excepting" multiple payload types for IQ's. Thanks :)
