Re: [Standards] UPDATED: XEP-0245 (The /me Command)
On Fri Jan 9 01:29:54 2009, Matthew Wild wrote: On Thu, Jan 8, 2009 at 11:05 PM, XMPP Extensions Editor edi...@xmpp.org wrote: Version 0.2 of XEP-0245 (The /me Command) has been released. Abstract: This specification defines recommended handling of the /me command in XMPP instant messaging clients. Changelog: Clarified handling of XHTML-IM formatting; added security consideration for multi-user chat rooms. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0245.xml?%40diffMode=u%40diffWrap=sr1=2614r2=2624u=3ignore=k= That looks good to me, thanks! /me thinks it looks okay too. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] XEP readability
Some members of the XMPP Council commented recently that the front matter (author info, legal notices, etc.) in existing XEPs is quite lengthy. Therefore I have modified the XSLT to move almost all of that information to appendices. All of the XEPs have been regenerated to use this new format: http://xmpp.org/extensions/ Let me know what you think. Peter
Re: [Standards] XEP readability
Peter Saint-Andre wrote: Some members of the XMPP Council commented recently that the front matter (author info, legal notices, etc.) in existing XEPs is quite lengthy. Therefore I have modified the XSLT to move almost all of that information to appendices. All of the XEPs have been regenerated to use this new format: http://xmpp.org/extensions/ Let me know what you think. Better, but I would not move all metadata to the end. Comparing it to an RFC, I would move Appendix A (dependencies and version), B (who wrote that stuff), D (not important, but it should be at the top IMHO), and F (it is necessary to read the XEP) back to the top. Dirk -- Early to rise, early to bed, makes a man healthy, wealthy and dead. -- Terry Pratchett, The Light Fantastic
Re: [Standards] XEP readability
Dirk Meyer wrote: Peter Saint-Andre wrote: Some members of the XMPP Council commented recently that the front matter (author info, legal notices, etc.) in existing XEPs is quite lengthy. Therefore I have modified the XSLT to move almost all of that information to appendices. All of the XEPs have been regenerated to use this new format: http://xmpp.org/extensions/ Let me know what you think. Better, but I would not move all metadata to the end. Comparing it to an RFC, I would move Appendix A (dependencies and version), B (who wrote that stuff), D (not important, but it should be at the top IMHO), and F (it is necessary to read the XEP) back to the top. And something else: the top says Copyright (c) 1999 - 2009 XMPP Standards Foundation. See Legal Notices. That is not correct. E.g. my XEPs have no copyright before 2008, they did not exist at that time. Maybe parse the first version info as copyright start date. Dirk -- Original Pentium of Borg: Division is futile - your decimals will be approximated.
[Standards] Question about XEP-191: Simple Communications Blocking
Peter, et al- I have a quick query about XEP-191. In Section 3, Relationship to Privacy Lists, the XEP states that the new protocol is intended to be a user-friendly front-end to the privacy lists protocol. While I have some personal issues with this stated goal (in particular I don't think that XEP-16's requirement for in-order processing is particularly useful), I do have a specific question about implementation. First, should there be some standard name for a list that is generated by this protocol if it is retrieved via the XEP-16 protocol? Using the URI of the blocking protocol would probably be sufficient (and could provide a hint to sophisticated clients that this list was generated using the simple protocol), but I am curious if there is guidance from the standards body. Additionally, the implications listed in Section 3 state: If all of a user's clients always use simple communications blocking, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of virtual list (in the sense that it is never modified directly by any of the clients). This rule implies to me that there should be some interaction with entity capabilities such that the server knows if the clients support this protocol or not. This would, of course, require that the client publish proper caps in its initial presence and the server will have to defer this decision (i.e. should I be using the Simple Blocking list vs. the list defined as default in XEP-16) until the capabilities information has been cached by the server. Finally, the 5th implication in this section states: If one of a user's clients makes active something other than the default privacy list, the user may receive communications from contacts who are blocked in the default list. Is there an expectation here that a connect client that's using the simple blocking protocol would get the push notifications of the updated blocklist? That question applies to the wider context of the usage of this protocol - should privacy list modification cause simple blocking protocol pushes and vice versa? Thanks for your time. Ben
Re: [Standards] XEP readability
How about simply adding a link to the table of contents near the top of the page? That would satisfy me. I have indeed grown tired of scrolling through the front matter. Thanks, Matt
Re: [Standards] XEP readability
Dirk Meyer wrote: Dirk Meyer wrote: Peter Saint-Andre wrote: Some members of the XMPP Council commented recently that the front matter (author info, legal notices, etc.) in existing XEPs is quite lengthy. Therefore I have modified the XSLT to move almost all of that information to appendices. All of the XEPs have been regenerated to use this new format: http://xmpp.org/extensions/ Let me know what you think. Better, but I would not move all metadata to the end. Comparing it to an RFC, I would move Appendix A (dependencies and version), B (who wrote that stuff), D (not important, but it should be at the top IMHO), and F (it is necessary to read the XEP) back to the top. Then we haven't really improved anything. :) And something else: the top says Copyright (c) 1999 - 2009 XMPP Standards Foundation. See Legal Notices. That is not correct. E.g. my XEPs have no copyright before 2008, they did not exist at that time. Maybe parse the first version info as copyright start date. Currently the XEP metadata does not have the specific date (or date range) of the particular spec, so everything claims copyright since the original Jabber projects began (1999). I'm sure that could be improved. /psa
Re: [Standards] XEP readability
Peter Saint-Andre wrote: Some members of the XMPP Council commented recently that the front matter (author info, legal notices, etc.) in existing XEPs is quite lengthy. Therefore I have modified the XSLT to move almost all of that information to appendices. All of the XEPs have been regenerated to use this new format: http://xmpp.org/extensions/ Let me know what you think. +1, much better now :-) Bernd
