Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 8:00 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-07-31 22:52, XMPP Extensions Editor wrote: 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? Yes, it is a quite important usability improvement. 2. Does the specification solve the problem stated in the introduction and requirements? Yes 3. Do you plan to implement this specification in your code? If not, why not? Yes 4. Do you have any security concerns related to this specification? No other than other last call comments have expressed. 5. Is the specification accurate and clearly written? Yes. However. It does not explicitly state what element of the message/ that is replaced. It is clear from the examples that body/ is what the author thought of. It mentions some items that shall not be replaced, but apart from that it seems to be open for replacing anything that has been delivered in a message/. That is both an opportunity and a risk. It is an opportunity for other extensions adding elements to the message/ to consider if they want to utilize XEP-0308 for replacing the contents. ( this could possibly be utilized by XEP-0301 instead of specifying its own way of doing replacements of real-time text, but it requires some more specific rules in XEP-0301 about how to apply it in that environment.) It is a risk that if other extensions adding new message elements do not specify if XEP-0308 can replace the contents of the new element. interoperability problems may appear, with a sender replacing an element that the recipient is not made for replacing. This could be moderated by inserting a sentence in the Business rules: Extensions specifying message/ contents should specify if and how it can be replaced by the XEP-0308 'replace'. Thanks for the feedback. The XEP says that a correction is a replacement for the entire stanza. I'll make sure I add text to make this clearer. /K
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
[ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ] Hello Gunnar, Thanks very much for the minor corrections to XEP-0301. I have queued your edits. My present judgement is that your edits are safely queued until LC, however, I'd like comments from other key XSF members: There is ONE bullet meriting further discussion. Talk related to section 6.2 Activation/Deactivation. Especially if Kevin/Peter/MM/etc has major comments about section 6.2 ... though Kevin says it didn't need to be relocated to a Business Rules section, and therefore is okay where it is for LC, I'm told. But does MM disagree, for example? On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 1. 4.2.3 id The text should start with a description of what function this attribute supports. Insert after the title: The id attribute is used to enable real-time correction of the last completed message. [Minor Clarification Change] Good suggestion. I'll queue this edit till LC. (unless a 0.8 is warranted prior, e.g. comments from mm/peter/kevin et cetra) Insert the title of XEP-0308 XEP-0308 Last message correction 2. 4.2.3 id On second line. Reception must always be supported if both 0308 and 0301 are supported. c/MUST use this attribute if/MUST support reception of this attribute, and MUST transmit this attribute if/ [Minor Clarification Change] Clients that support incoming corrections don't necessarily do outgoing corrections. Therefore, a different change is better: c/clients MUST use this attribute if/clients MUST support this attribute in situations where/ I'll queue this edit, too. 3. 6.2.1 Activation guidelines Can we really accept the weak indication that discovery is recommended? I think it shall be mandated. Proposal: c/Before sending real-time text, it is preferable for a sender client to/Before sending real-time text, a sender client SHALL/ [Comment] Peter told me that RFC2119 normatives do not belong in Implementation Notes. Therefore, if RFC2119 is used, the whole section 6.2 would automatically need a relocation upwards closer to Protocol instead of Implementation Notes. I'm open to suggestions by others, such as moving to a Business Rules section (just below Discovering Support and above Implementation Notes) However, Kevin of XSF said that it is fine where it is. However, I agree this is an item meriting some discussion, though I'm not 100% sure if this needs to be addressed before LC. (Comments from others? Does it?) Section 6.2: http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text 4. Section 1, intro, last bullet point, to make the description of REACH112 correct.: c/A component within Total Conversation, used by Reach112 [4] in Europe, an accessible emergency service with real-time text./The real-time text component within Total Conversation, for example used by Reach112 [4] in Europe, a project for accessible communication services including emergency service. [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 5. Section 4.1 Example 1 should have a more natural distribution of letters in the different rtt/ elements, appearing from the transmission in regular intervals as specified in section 4.1. This comment has been made from different sources a number of times. [Comment] I already mentioned that the existing example is more readable to a wider variety of less experienced people. The smart people (like us) will figure it out just fine, and the other examples illustrate this already. I'm going to cater for the majority here. 6. 4.7 Third paragraph. Language correction. This is an enumeration of only two elements. Connect them with or instead of comma: s/ messages, incorrect/ messages or incorrect/ [Minor Grammar] Thanks, I'll queue this edit, too. Note that e.g. represents partial list of examples, and automatically assumes etc. at the end. So there are other situations as well, so it's not just two. Even though only two are listed. 7. Appendix G: 4 s/ Reach112: European emergency service with real-time text./ Reach112: European accessible communication and emergency service project with total conversation including real-time text./ [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 8. 4.1 xml:lang Describe explicit or implicit use of the xml:lang attribute similarly as it is described for body/ in RFC 6221. This attribute can introduce alternative language variants of the text in messages and other elements. The use is described in RFC 6221. For XEP-0301 it would be natural to offer the same opportunity to provide the alternative languages in the same message. This would at least go into section 4.2 RTT attributes and 4.5.3.1 t/ element Each language will have its own editing elements and values, so the xml:lang attribute should be on the rtt/ level. I propose
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. -- Kurt On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor edi...@xmpp.org wrote: 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!
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
It may be that I'm reading a restriction into the spec that wasn't intended by the authors. If so, then maybe a simple clarification is needed (like drop the Last from the title). On Aug 13, 2012, at 9:15 AM, Kurt Zeilenga kurt.zeile...@isode.com wrote: Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. -- Kurt On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor edi...@xmpp.org wrote: 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!
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. The spec originally allowed previous non-last correction, and the community cried foul so I removed it. I can add it back in if the community has now changed its mind! /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Aug 13, 2012, at 9:22 AM, Kevin Smith ke...@kismith.co.uk wrote: On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. The spec originally allowed previous non-last correction, and the community cried foul I found a thread that occurred during the initial consideration of the XEP (when it was proposed), starting at: http://mail.jabber.org/pipermail/standards/2011-November/025394.html I noticed that the original title did say Last. I see Ben Langfeld arguing that it shouldn't be restricted to last. I see Dave Cridland being mildly terrified about allowing change to any previous message. And your response. Not much crying. Was there some other thread? Anyways, here's my argument. From a user perspective, often what I want to correct isn't the last stanza I sent. And when I receive corrections, I rather my client not replace the original message in the presentation stream. I rather the client simply add the replacement message to the message stream (as it would any other new message) and provide me some indication that it's a replacement for another message and what that message is. And, I note, if a client receives a correction for a stanza it doesn't have, it still make use of the replace/ element, by using it to trigger that the newly presented content is a replacement for non-presented content. Now, I can see some clients would replace the content in the presented stream it the replaced message last received message (before the replacement)... but that's an implementation detail. No matter what what, clients need to be able to deal replaces coming in for something other than the last received message, like treating it as if the replace/ element was absent. From a protocol perspective, I see little reason to have the last sent restriction as clients have to deal with replace referencing non-last (possibly not previously seen) messages. so I removed it. I can add it back in if the community has now changed its mind! /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 12:22 PM, Kevin Smith ke...@kismith.co.uk wrote: Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. The spec originally allowed previous non-last correction, and the community cried foul so I removed it. I can add it back in if the community has now changed its mind! It's useful for real-time text situations -- it goes hand-in-hand with transcription/caption corrections, when using instant messaging as a conduit of transmitting transcriptions, and needing to retroactively fix transcription errors, or manually editing voice-recognition errors. It is a niche case, but certainly a legitimate one. However, please bring the original people who cried foul, back into this discussion. I'd like to see if they now agree with the use cases. The only thing is that you need to either: 1. Define the bounds of corrections (e.g. X messages ago) --or-- 2. Define what to do if 'id' points to a non-existent message (i.e. refers to a message that no longer exists on recipient's client -- this can happen in multiple login situations, reconnect situations, MUC situations with new participants joining after a message is already sent) For simplicity you may want to go for scenario (2) for now. Treat unrecognized id's as a new stanza. The only problem is that we don't really know how many messages ago it was -- for example, we don't know if it was 2 or 3 messages ago -- or 6 messages ago. So corrections done in a random-access manner, and out-of-order transmission, will show potential jumbling of order. But that's acceptable, and potentially a client implementation could automatically sort the 'id' parameter alphabetically, since the 'id' is often always incrementing (either numerically or alphabetically), though that's not always reliable. Thanks, Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 3:00 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: That is both an opportunity and a risk. It is an opportunity for other extensions adding elements to the message/ to consider if they want to utilize XEP-0308 for replacing the contents. ( this could possibly be utilized by XEP-0301 instead of specifying its own way of doing replacements of real-time text, but it requires some more specific rules in XEP-0301 about how to apply it in that environment.) In addition, it would likely be non-backwards compatible in a graceful degrade manner, e.g. MUC A mixed MUC with all kinds of participants simultaneously: - Clients that don't support XEP-0301 - Clients that support XEP-0301 but not XEP-0308 - Clients that support XEP-0308 but not XEP-0301 - Clients that support both XEP-0301 and XEP-0308 The way both me and Kevin has currently specified, ensures that both 0301 and 0308 will work and interop fine in mixed-MUC situations. Therefore, I like the way XEP-0308 is specified: full stanza replacement only, and keeping 0301 retroactive editing separate of 0308 retroactive. It's far simpler and far more forgiving than trying to specify ways of replacing specific rtt/ elements. Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Am 13.08.2012 22:05, schrieb Mark Rejhon: In addition, it would likely be non-backwards compatible in a graceful degrade manner, e.g. MUC [...] The way both me and Kevin has currently specified, ensures that both 0301 and 0308 will work and interop fine in mixed-MUC situations. Frankly, I would recommend MUCs to filter out any RTT stuff. Unless they want to take part in amplification attacks of course. But that's not for the 0308 LC, is a problem that 0045 has in general and only shows when dealing with heavy traffic.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 4:23 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.08.2012 22:05, schrieb Mark Rejhon: In addition, it would likely be non-backwards compatible in a graceful degrade manner, e.g. MUC [...] The way both me and Kevin has currently specified, ensures that both 0301 and 0308 will work and interop fine in mixed-MUC situations. Frankly, I would recommend MUCs to filter out any RTT stuff. Unless they want to take part in amplification attacks of course. But that's not for the 0308 LC, is a problem that 0045 has in general and only shows when dealing with heavy traffic. Not an option. Some demos of Next Generation 911 uses MUC combined with XEP-0301 Better option: Server control of enabling/disabling 0301 on a per-chat-room basis Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Am 13.08.2012 19:06, schrieb Kurt Zeilenga: I rather the client simply add the replacement message to the message stream (as it would any other new message) and provide me some indication that it's a replacement for another message and what that message is. I like that notion. It doesn't change the 'oh, I meant to say...' model that is (probably) widely used today, but still gives a hint which message is affected.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 4:38 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.08.2012 19:06, schrieb Kurt Zeilenga: I rather the client simply add the replacement message to the message stream (as it would any other new message) and provide me some indication that it's a replacement for another message and what that message is. I like that notion. It doesn't change the 'oh, I meant to say...' model that is (probably) widely used today, but still gives a hint which message is affected. Agreed -- I suggest Kevin make a mention suggesting such behavior. Note, replace/ has no better/worse potential for amplification attacks than XEP-0301 does (assuming you follow reasonable rules, such as automatically transmit traffic when receiving traffic, etc -- neither of which is required for 0301 or 0308)
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Mark, Regarding the example in 4.1, I agree with Gunnar. The first example gives the wrong initial impression by sending only complete words in the rtt/. (It made me go and double check how the protocol worked.) I suggest that we keep the first rtt/ as is, but slightly change the second and third rtt/ text contents to: *tmy J**/t* and *tuliet!/t* respectively. This retains the readability but also shows that the rtt/ is sent independently of word boundaries. Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Apple + Linux + Open Source software On Tue, Aug 14, 2012 at 1:29 AM, Mark Rejhon marky...@gmail.com wrote: [ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ] Hello Gunnar, Thanks very much for the minor corrections to XEP-0301. I have queued your edits. My present judgement is that your edits are safely queued until LC, however, I'd like comments from other key XSF members: There is ONE bullet meriting further discussion. Talk related to section 6.2 Activation/Deactivation. Especially if Kevin/Peter/MM/etc has major comments about section 6.2 ... though Kevin says it didn't need to be relocated to a Business Rules section, and therefore is okay where it is for LC, I'm told. But does MM disagree, for example? On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 1. 4.2.3 id The text should start with a description of what function this attribute supports. Insert after the title: The id attribute is used to enable real-time correction of the last completed message. [Minor Clarification Change] Good suggestion. I'll queue this edit till LC. (unless a 0.8 is warranted prior, e.g. comments from mm/peter/kevin et cetra) Insert the title of XEP-0308 XEP-0308 Last message correction 2. 4.2.3 id On second line. Reception must always be supported if both 0308 and 0301 are supported. c/MUST use this attribute if/MUST support reception of this attribute, and MUST transmit this attribute if/ [Minor Clarification Change] Clients that support incoming corrections don't necessarily do outgoing corrections. Therefore, a different change is better: c/clients MUST use this attribute if/clients MUST support this attribute in situations where/ I'll queue this edit, too. 3. 6.2.1 Activation guidelines Can we really accept the weak indication that discovery is recommended? I think it shall be mandated. Proposal: c/Before sending real-time text, it is preferable for a sender client to/Before sending real-time text, a sender client SHALL/ [Comment] Peter told me that RFC2119 normatives do not belong in Implementation Notes. Therefore, if RFC2119 is used, the whole section 6.2 would automatically need a relocation upwards closer to Protocol instead of Implementation Notes. I'm open to suggestions by others, such as moving to a Business Rules section (just below Discovering Support and above Implementation Notes) However, Kevin of XSF said that it is fine where it is. However, I agree this is an item meriting some discussion, though I'm not 100% sure if this needs to be addressed before LC. (Comments from others? Does it?) Section 6.2: http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text 4. Section 1, intro, last bullet point, to make the description of REACH112 correct.: c/A component within Total Conversation, used by Reach112 [4] in Europe, an accessible emergency service with real-time text./The real-time text component within Total Conversation, for example used by Reach112 [4] in Europe, a project for accessible communication services including emergency service. [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 5. Section 4.1 Example 1 should have a more natural distribution of letters in the different rtt/ elements, appearing from the transmission in regular intervals as specified in section 4.1. This comment has been made from different sources a number of times. [Comment] I already mentioned that the existing example is more readable to a wider variety of less experienced people. The smart people (like us) will figure it out just fine, and the other examples illustrate this already. I'm going to cater for the majority here. 6. 4.7 Third paragraph. Language correction. This is an enumeration of only two elements. Connect them with or instead of comma: s/ messages, incorrect/ messages or incorrect/ [Minor Grammar] Thanks, I'll queue this edit, too. Note that e.g. represents partial list of examples, and automatically assumes etc. at the end. So there are other situations as well, so it's not just two. Even though only two are listed. 7. Appendix G: 4 s/ Reach112: European emergency service with real-time text./
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Barry may have presented a compromise I can accept. The first (introductory) stanza is still full word, and the second and third is not too difficult for most readers to figure out. On 2012-08-13 8:44 PM, Barry Dingle btdin...@gmail.com wrote: Mark, Regarding the example in 4.1, I agree with Gunnar. The first example gives the wrong initial impression by sending only complete words in the rtt/. (It made me go and double check how the protocol worked.) I suggest that we keep the first rtt/ as is, but slightly change the second and third rtt/ text contents to: *tmy J**/t* and *tuliet!/t* respectively. This retains the readability but also shows that the rtt/ is sent independently of word boundaries. Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Apple + Linux + Open Source software On Tue, Aug 14, 2012 at 1:29 AM, Mark Rejhon marky...@gmail.com wrote: [ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ] Hello Gunnar, Thanks very much for the minor corrections to XEP-0301. I have queued your edits. My present judgement is that your edits are safely queued until LC, however, I'd like comments from other key XSF members: There is ONE bullet meriting further discussion. Talk related to section 6.2 Activation/Deactivation. Especially if Kevin/Peter/MM/etc has major comments about section 6.2 ... though Kevin says it didn't need to be relocated to a Business Rules section, and therefore is okay where it is for LC, I'm told. But does MM disagree, for example? On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 1. 4.2.3 id The text should start with a description of what function this attribute supports. Insert after the title: The id attribute is used to enable real-time correction of the last completed message. [Minor Clarification Change] Good suggestion. I'll queue this edit till LC. (unless a 0.8 is warranted prior, e.g. comments from mm/peter/kevin et cetra) Insert the title of XEP-0308 XEP-0308 Last message correction 2. 4.2.3 id On second line. Reception must always be supported if both 0308 and 0301 are supported. c/MUST use this attribute if/MUST support reception of this attribute, and MUST transmit this attribute if/ [Minor Clarification Change] Clients that support incoming corrections don't necessarily do outgoing corrections. Therefore, a different change is better: c/clients MUST use this attribute if/clients MUST support this attribute in situations where/ I'll queue this edit, too. 3. 6.2.1 Activation guidelines Can we really accept the weak indication that discovery is recommended? I think it shall be mandated. Proposal: c/Before sending real-time text, it is preferable for a sender client to/Before sending real-time text, a sender client SHALL/ [Comment] Peter told me that RFC2119 normatives do not belong in Implementation Notes. Therefore, if RFC2119 is used, the whole section 6.2 would automatically need a relocation upwards closer to Protocol instead of Implementation Notes. I'm open to suggestions by others, such as moving to a Business Rules section (just below Discovering Support and above Implementation Notes) However, Kevin of XSF said that it is fine where it is. However, I agree this is an item meriting some discussion, though I'm not 100% sure if this needs to be addressed before LC. (Comments from others? Does it?) Section 6.2: http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text 4. Section 1, intro, last bullet point, to make the description of REACH112 correct.: c/A component within Total Conversation, used by Reach112 [4] in Europe, an accessible emergency service with real-time text./The real-time text component within Total Conversation, for example used by Reach112 [4] in Europe, a project for accessible communication services including emergency service. [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 5. Section 4.1 Example 1 should have a more natural distribution of letters in the different rtt/ elements, appearing from the transmission in regular intervals as specified in section 4.1. This comment has been made from different sources a number of times. [Comment] I already mentioned that the existing example is more readable to a wider variety of less experienced people. The smart people (like us) will figure it out just fine, and the other examples illustrate this already. I'm going to cater for the majority here. 6. 4.7 Third paragraph. Language correction. This is an enumeration of only two elements. Connect them with or instead of comma: s/ messages, incorrect/ messages or incorrect/ [Minor Grammar] Thanks, I'll queue this edit, too. Note that e.g.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Kurt Zeilenga: From a user perspective, often what I want to correct isn't the last stanza I sent. I support that argument. Several Social Networking Services provide similar features and I expect XMPP to also support that. Cheers, Andreas
