[Standards] XEP-0256 (Last Activity in Presence) questions/issues
Hi All, I apologize that I didn't bring this up several years ago when this XEP first popped up, but I was on a (long) hiatus from my open source work, and really wasn't following anything in XMPP-land. I've been reviewing the XMPP code in libpurple (basis of Pidgin, Finch, and Adium), and was looking into some issues with the XEP-0256 handling. There are 2 separate issues that I feel need addressing. Apologies if this has been discussed on here before, I couldn't find anything in the archives. First, the spec (much like XEP-0012 which it derives from) tries to serve multiple purposes, serving as a mechanism for both "idle time" and time since last login. From XEP-0012: > > > 7. Implementation Notes > > The information contained in an IQ reply for this namespace is > inherently ambiguous. Specifically, for a bare JID > the information is the time since the JID was > last connected to its server; for a full JID > the information is the time since the > resource was last active in the context of an existing session; and > for a bare domain the information is the uptime for the server or > component. An application MUST take these differences into account > when presenting the information to a human user (if any). > > In XEP-0256, the 2 different pieces of information are how long since last login (similar to the bare JID case in 0012), and "idle time" (the full JID case in 0012). In XEP-0256, the distinguishing difference seems to be "initial presence" vs "away or extended away". I feel like this distinction is a little ambiguous. In my client(s) (and I believe in several others) the concepts of "away" and "idle" are independent, so there's nothing preventing you from being "idle" without being "away". Also, from my understanding of XMPP (and someone please correct me if I'm wrong here), there's nothing wrong with an initial presence having a 'show' tag contianing 'away' or 'xa'. So given a presence packet , I can't tell if I'm being told how idle a user is, or how long it has been since they logged in. The second issue is that some servers (notably google/gmail) don't seem to implement XEP-0203 (Delayed Delivery) for presence packets, so even if I knew which piece of information is being conveyed to me, I can't reliably tell how stale that information might be if I recently reconnected, or if the servers recently went through some sort of split/join event. When I first log in, it looks like all my idle gmail buddies have been idle for 5 minutes or 10 minutes (depending on how they have their client set up). Apple seems to have invented their own (undocumented as far as I can tell, but pretty self-explanatory) protocol for idle time. It looks like: 2012-10-15T16:37:07Z Even without documentation, I like that this is much clearer about the information being conveyed, and frankly I'd rather deal with the (increasingly rare) problem of clock drift, than something not being implemented by a particular server. I think we could take this "style" of protocol, and perhaps add "previous-login" and "online-since" to cover all of the XEP-0012 bases. I'm assuming it would be a bad idea to just document their protocol, especially if we add to it (or they change it). Any thoughts? -Nathan
[Standards] NEW: XEP-0315 (Data Forms XML Element)
Version 0.1 of XEP-0315 (Data Forms XML Element) has been released. Abstract: This specification defines an XMPP protocol extension for including XML-data in XEP-0004 data forms. Changelog: Initial published version approved for publication by the XMPP Council. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0315.html
Re: [Standards] Stamping on one's head Re: Fwd: Minutes 20121011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/12 1:44 AM, Kevin Smith wrote: > > On Sat, Oct 13, 2012 at 5:37 PM, Andreas Kuckartz > wrote: >> According to http://xmpp.org/about-xmpp/xsf/xmpp-council/ ralphm >> is currently a member of the XMPP Council. >> >> Can someone please let me know if he has a veto right there? > > Yes - the process is described in > http://xmpp.org/extensions/xep-0001.html#approval; any Council > member can prevent advancement of a XEP indefinitely (whether this > is a good idea is up for debate, but that's the way it is). > >> If that is the case there would be no reason for me to spend a >> minute more on finding a reasonable way to add RDFa to XEP-0071. >> I generally do not participate in discussions with a >> predetermined outcome. > > Council members have been known to change their minds, but in this > case I think a significant change in scope/purpsoe of a Draft XEP > immediately before advancement to Final might be a bit extreme. > This doesn't, however, prevent proposal of a new XEP implementing > RDFa, which would seem a sensible route to take here. Andreas, I agree with Kev -- Ralph is concerned about making major changes to the scope of XEP-0071 when it is close to a Final spec. However, developing a new spec for RDFa over XMPP makes sense. In fact, I think it would be simpler than XEP-0071 because in XEP-0071 we had to define a new Integration Set using XHTML modularization (which I found kind of confusing at the time), whereas the W3C has already defined RDFa for us using XHTML modularization, so all we need to do is define a wrapper element for sending RDFa over XMPP. In fact, I chatted with someone else about this very topic last week, so I will introduce you to him offlist in case you want to work together. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB8IdYACgkQNL8k5A2w/vxQIQCeKaEbgSDy6f7kobN/sqiAiTXb vwcAn2KYHcZSay2d5/aj8zG91vVuE2RU =pbCN -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/12 7:53 AM, Peter Saint-Andre wrote: > On 10/12/12 4:07 AM, Sergey Dobrov wrote: >> On 10/11/2012 10:23 PM, Peter Saint-Andre wrote: >>> On 9/27/12 5:32 PM, Peter Saint-Andre wrote: >>> >>> (I also wonder why we don't support for inline >>> quotation...) >> >> Yes, it seems that the set of allowed tags should be reviewed >> too. > > Maybe. :) I'm sure we had good reasons for the limited subset we > defined in 2003-2004, and I am not sure we want to reconsider every > element and attribute when the XEP is so mature. I really don't want to re-open a discussion about each and every XHTML element, so I'm sorry about the comment on for inline quotation. In any case, what's in XEP-0071 is a recommended profile, so developers are free to support more structural elements if desired. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB8H5YACgkQNL8k5A2w/vzkXQCeNVe3gocxbZGwqJfLk1QQD3xs tFEAnAsA8kvnE01ot4Rh/tRoqXig1ZIm =BJLf -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/12 12:21 AM, Andreas Kuckartz wrote: > I agree with that sentiment. Green-colored text and strange fonts > were popular when MySpace was popular. This is something from the > past, not the present or future. > > The present and future require semantic elements (such as > ) and attributes (such as those used by RDFa). I think that's right. So how about the following change... OLD The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., this is bold and this is indented) rather than XHTML structural elements (e.g., and ) wherever possible. NEW Where strictly presentational style are desired (e.g., colored text), it might be necessary to use use 'style' attributes (e.g., this is green). However, where possible it is instead RECOMMENDED to use appropriate structural elements (e.g., and instead of, say, style='font-weight: bold' or style='margin-left: 5%'). Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB8Hs4ACgkQNL8k5A2w/vxiMwCfSUAJJEpXaNLLgH1jH460VBKS SsoAoO6pG90B7HzgCWJAtXBmsXi18kXx =Utuf -END PGP SIGNATURE-
Re: [Standards] Stamping on one's head Re: Fwd: Minutes 20121011
Hi, On Sat, Oct 13, 2012 at 5:37 PM, Andreas Kuckartz wrote: > According to http://xmpp.org/about-xmpp/xsf/xmpp-council/ ralphm is > currently a member of the XMPP Council. > > Can someone please let me know if he has a veto right there? Yes - the process is described in http://xmpp.org/extensions/xep-0001.html#approval; any Council member can prevent advancement of a XEP indefinitely (whether this is a good idea is up for debate, but that's the way it is). > If that is the case there would be no reason for me to spend a minute > more on finding a reasonable way to add RDFa to XEP-0071. I generally do > not participate in discussions with a predetermined outcome. Council members have been known to change their minds, but in this case I think a significant change in scope/purpsoe of a Draft XEP immediately before advancement to Final might be a bit extreme. This doesn't, however, prevent proposal of a new XEP implementing RDFa, which would seem a sensible route to take here. /K
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
I agree with that sentiment. Green-colored text and strange fonts were popular when MySpace was popular. This is something from the past, not the present or future. The present and future require semantic elements (such as ) and attributes (such as those used by RDFa). Cheers, Andreas Peter Saint-Andre: > On 9/27/12 5:32 PM, Peter Saint-Andre wrote: > >> On 7/31/12 6:43 PM, Mathieu Pasquet wrote: > >>> I am also not sure about the and >>> elements: they are shown as a recommended element to support >>> (7.8), but the business rules (8.7) states that they should >>> not be used, but rather or with appropriate style >>> attributes. Is it only for backward compatibility, then? > >> I think we need a broader discussion of this topic, since it >> caused so much controversy when we first defined XHTML-IM. I will >> review the old list discussion and more modern opinions on this >> topic, then post to the list again. > > Here is the relevant business rule: > > ### > > The use of structural elements is NOT RECOMMENDED where > presentational styles are desired, which is why very few structural > elements are specified herein. Implementations SHOULD use > appropriate 'style' attributes (e.g., this is bold and this is > indented) rather than XHTML structural elements (e.g., > and ) wherever possible. > > ### > > That now seems wrongheaded to me. Sure, *if* you just want a > pretty presentation (say, a bit of green-colored text), then > 'style' attributes are appropriate. However, it seems to me that if > you want to quote something or emphasize something then using > or is the right thing to do. > > (I also wonder why we don't support for inline quotation...) > > Peter
