[Standards] LAST CALL: XEP-0308 (Last Message Correction)
This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL: http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
[Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
At its meeting on July 25, 2012, the XMPP Council agreed to issue a Call for Experience regarding XEP-0071 (XHTML-IM), in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. What software has implemented XEP-0071? Please note that the protocol must be implemented in at least two separate codebases (and preferably more) in order to advance from Draft to Final. 2. Have developers experienced any problems with the protocol as defined in XEP-0071? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments about advancing XEP-0071 from Draft to Final, please provide them by the close of business on Friday, August 31, 2012. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: http://www.xmpp.org/extensions/xep-0071.html Please send all feedback to the standards@xmpp.org discussion list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 7/31/12 2:58 PM, Peter Saint-Andre wrote: If you have any comments about advancing XEP-0071 from Draft to Final, please provide them by the close of business on Friday, August 31, 2012. Section 12.4 of XEP-0071 (version 1.4) reads in full: ### 12.4 W3C Review The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C. Before the XHTML-IM specification proceeds to a status of Final within the standards process of the XMPP Standards Foundation, the XMPP Council is encouraged to pursue a formal review through communication with the Hypertext Coordination Group within the W3C. ### Although I would in fact like to obtain such a formal W3C review, I don't think it's realistic to make formal W3C review a gating factor for advancement to Final because the folks who work on HTML at the W3C are very busy with HTML5 (and will be for the foreseeable future as far as I can see). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. 7.6 states that the style attribute MUST be supported, but 7.6.1 on the other hand shows a list of RECOMMENDED CSS1 properties. If a client does not implement any of those properties, isn’t it the same as dropping the style attribute (and therefore not supporting it)? I am also not sure about the strong/ and blockquote/ 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 span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? There is the matter of the img/ tag that accepts a data:base64 as a src, leading to very big stanzas. I think that maybe the XEP could state that whenever possible, the use of base64 data should be avoided, at least in MUCs, where the message is replicated as many times as there are users, leading to high bandwith usage (although if I remember correctly, most servers set the max stanza size to 10 KiB). Finally, although we have a somehow working partial implementation of XEP-0071 in Poezio, I wouldn’t count it as a proper codebase for XEP validation, because the limitations of console clients do not allow a full implementation (e.g. font changes, text-decorations other than underline, relative margins, etc). -- Mathieu Pasquet (mathieui) signature.asc Description: OpenPGP digital signature
