Re: [Standards] Proposed XMPP Extension: In-Band Real Time Text
> > On 6/17/11 8:10 PM, XMPP Extensions Editor wrote: >> > URL: http://www.xmpp.org/extensions/inbox/realtimetext.html >> > >> > The XMPP Council will decide at its next meeting whether to accept this >> proposal as an official XEP. >> > FYI: New side-by-side animation of what XMPP In-Band Real-Time Text looks like: http://www.marky.com/realjabber/real_time_text_demo.gif
Re: [Standards] UPDATED: XEP-0292 (vCard4 Over XMPP)
On 6/20/11 3:20 PM, XMPP Extensions Editor wrote: > Diff: http://xmpp.org/extensions/diff/api/xep/0292/diff/0.2/vs/0.4 Somehow I never officially published version 0.3, thus the jump from 0.2 to 0.4. Sorry about the confusion! /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0292 (vCard4 Over XMPP)
Version 0.4 of XEP-0292 (vCard4 Over XMPP) has been released. Abstract: This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. Changelog: Defined provisional mapping from vcard-temp to vCard4. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0292/diff/0.2/vs/0.4 URL: http://xmpp.org/extensions/xep-0292.html
Re: [Standards] XEP-0198 1.3rc2 amendments
On 6/20/11 10:18 AM, Matthew A. Miller wrote: > On Jun 20, 2011, at 07:43 , Peter Saint-Andre wrote: > >> On 6/18/11 10:00 AM, Matthew Wild wrote: >>> Hi, >>> >>> A few more small issues with XEP-0198 have come to my attention. >>> >>> The largest of them is that the XEP says the 'h' attribute is optional >>> on , I don't think this should be allowed because the server >>> needs to know which stanzas the client received before its old session >>> was disconnected so it can re-send them. After a resume is usually the >>> only time stanzas can and should ever be re-sent. If 'h' is made >>> optional at resume time then the server has to special-case the first >>> from a client after resumption, and also distinguish between >>> stanzas it sent on the old connection(s) and on the new one. Many >>> headaches lie this way, for a tiny convenience in the protocol. >> >> Having pondered it a bit, I think that's right. I suggest: >> >> ### >> >> To request resumption of the former stream, the initiating entity sends >> a element qualified by the 'urn:xmpp:sm:3' namespace. The >> element MUST include a 'previd' attribute whose value is the >> SM-ID of the former stream and MUST include an 'h' attribute that >> identifies the sequence number of the last handled stanza sent over the >> former stream from the server to the client (in the unlikely case that >> the client never received any stanzas, it would set 'h' to zero). >> >> Example 10. Stream resumption request >> >> C: > h='some-sequence-number' >> previd='some-long-sm-id'/> >> >> If the server can resume the former stream, it MUST return a >> element, which MUST include a 'previd' attribute set to the SM-ID of the >> former stream and MUST also include an 'h' attribute set to the sequence >> number of the last handled stanza sent over the former stream from the >> client to the server (in the unlikely case that the server never >> received any stanzas, it would set 'h' to zero). >> >> Example 11. Stream resumed >> >> S: >h='another-sequence-number' >>previd='some-long-sm-id'/> >> >> ### >> >>> Also in several places the XEP mentions Stream Management needing to >>> be explicitly enabled in "both directions". I can't recall if this was >>> the case in a previous version of the spec, but I don't believe it to >>> be the case now - when enabled, both parties send and receive and >>> . >> >> Correct. > > After reading this rc3 draft twice, I think all of the "needs to be enabled > in both directions" droppings are now gone. > >> >>> Also some instances of "initiating entity" should be changed to >>> "client" in the vein of the other recent edits to 1.3rc2. >> >> Done. >> >>> Additionally I think it might be worth adding a note at the very end >>> of section 4, with words to the effect that there is no guarantee that >>> an unacknowledged stanza was not in fact received by the peer - in >>> other words, re-sending or otherwise dealing with unacknowledged >>> stanzas has the potential to produce duplicates. >> >> How about this? >> >> ### >> >> Because unacknowledged stanzas might have been received by the other >> party, resending them might result in duplicates; there is no way to >> prevent such a result in this protocol, although use of the XMPP 'id' >> attribute on all stanzas can at least assist the intended recipients in >> weeding out duplicate stanzas. >> >> ### >> >>> Based on feedback I think we should add as the first item in the list >>> at the end of section 5 something like: "The sequence values are >>> carried over from the previous session and are not reset for the new >>> stream.". >> >> Agreed. >> >>> The current first entry in that list (about retransmitting stanzas) >>> may be deserve a little more explanation, e.g. with this text: >>> >>> [[ >>> Upon receiving a or element the client and server >>> use the 'h' attribute to retransmit any stanzas lost by the >>> disconnection. In effect, it should handle the element's 'h' attribute >>> as it would handle it on an element (i.e. marking stanzas in its >>> outgoing queue as handled), except that after processing it MUST >>> re-send to the peer any stanzas that are still marked as unhandled. >>> ]] (this also changes re-sending from SHOULD to MUST, which I believe >>> is required to stop things going very wrong) >> >> That's better, thanks. >> >>> The final issue is that the schema needs updating - it says can >>> have a 'h' attribute, while the text (correctly) says it has none. >> >> Fixed. >> >> http://xmpp.org/extensions/tmp/xep-0198-1.3.html >> >> http://xmpp.org/extensions/diff/api/xep/0198/diff/1.3rc2/vs/1.3rc3 >> >> http://xmpp.org/extensions/diff/api/xep/0198/diff/1.2/vs/1.3rc3 >> > > The changes look pretty good overall. I have the one nit from a different > thread, which you've acknowledged already (-: Fixed: http://xmpp.org/extensions/tmp/xep-0198-1.3.html http://xmpp.org/extensions/diff/api/xep/0198/diff/1.3rc3/vs/1.3rc4 http:
Re: [Standards] XEP-0198 1.3rc2 amendments
On 20 June 2011 14:43, Peter Saint-Andre wrote: > > Fixed. > > http://xmpp.org/extensions/tmp/xep-0198-1.3.html > > http://xmpp.org/extensions/diff/api/xep/0198/diff/1.3rc2/vs/1.3rc3 > > http://xmpp.org/extensions/diff/api/xep/0198/diff/1.2/vs/1.3rc3 > +1 to all, thanks for the prompt service :) Regards, Matthew
Re: [Standards] XEP-0198 1.3rc2 amendments
On Jun 20, 2011, at 07:43 , Peter Saint-Andre wrote: > On 6/18/11 10:00 AM, Matthew Wild wrote: >> Hi, >> >> A few more small issues with XEP-0198 have come to my attention. >> >> The largest of them is that the XEP says the 'h' attribute is optional >> on , I don't think this should be allowed because the server >> needs to know which stanzas the client received before its old session >> was disconnected so it can re-send them. After a resume is usually the >> only time stanzas can and should ever be re-sent. If 'h' is made >> optional at resume time then the server has to special-case the first >> from a client after resumption, and also distinguish between >> stanzas it sent on the old connection(s) and on the new one. Many >> headaches lie this way, for a tiny convenience in the protocol. > > Having pondered it a bit, I think that's right. I suggest: > > ### > > To request resumption of the former stream, the initiating entity sends > a element qualified by the 'urn:xmpp:sm:3' namespace. The > element MUST include a 'previd' attribute whose value is the > SM-ID of the former stream and MUST include an 'h' attribute that > identifies the sequence number of the last handled stanza sent over the > former stream from the server to the client (in the unlikely case that > the client never received any stanzas, it would set 'h' to zero). > > Example 10. Stream resumption request > > C:h='some-sequence-number' > previd='some-long-sm-id'/> > > If the server can resume the former stream, it MUST return a > element, which MUST include a 'previd' attribute set to the SM-ID of the > former stream and MUST also include an 'h' attribute set to the sequence > number of the last handled stanza sent over the former stream from the > client to the server (in the unlikely case that the server never > received any stanzas, it would set 'h' to zero). > > Example 11. Stream resumed > > S: h='another-sequence-number' >previd='some-long-sm-id'/> > > ### > >> Also in several places the XEP mentions Stream Management needing to >> be explicitly enabled in "both directions". I can't recall if this was >> the case in a previous version of the spec, but I don't believe it to >> be the case now - when enabled, both parties send and receive and >> . > > Correct. After reading this rc3 draft twice, I think all of the "needs to be enabled in both directions" droppings are now gone. > >> Also some instances of "initiating entity" should be changed to >> "client" in the vein of the other recent edits to 1.3rc2. > > Done. > >> Additionally I think it might be worth adding a note at the very end >> of section 4, with words to the effect that there is no guarantee that >> an unacknowledged stanza was not in fact received by the peer - in >> other words, re-sending or otherwise dealing with unacknowledged >> stanzas has the potential to produce duplicates. > > How about this? > > ### > > Because unacknowledged stanzas might have been received by the other > party, resending them might result in duplicates; there is no way to > prevent such a result in this protocol, although use of the XMPP 'id' > attribute on all stanzas can at least assist the intended recipients in > weeding out duplicate stanzas. > > ### > >> Based on feedback I think we should add as the first item in the list >> at the end of section 5 something like: "The sequence values are >> carried over from the previous session and are not reset for the new >> stream.". > > Agreed. > >> The current first entry in that list (about retransmitting stanzas) >> may be deserve a little more explanation, e.g. with this text: >> >> [[ >> Upon receiving a or element the client and server >> use the 'h' attribute to retransmit any stanzas lost by the >> disconnection. In effect, it should handle the element's 'h' attribute >> as it would handle it on an element (i.e. marking stanzas in its >> outgoing queue as handled), except that after processing it MUST >> re-send to the peer any stanzas that are still marked as unhandled. >> ]] (this also changes re-sending from SHOULD to MUST, which I believe >> is required to stop things going very wrong) > > That's better, thanks. > >> The final issue is that the schema needs updating - it says can >> have a 'h' attribute, while the text (correctly) says it has none. > > Fixed. > > http://xmpp.org/extensions/tmp/xep-0198-1.3.html > > http://xmpp.org/extensions/diff/api/xep/0198/diff/1.3rc2/vs/1.3rc3 > > http://xmpp.org/extensions/diff/api/xep/0198/diff/1.2/vs/1.3rc3 > The changes look pretty good overall. I have the one nit from a different thread, which you've acknowledged already (-: - m&m smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] XEP-0198 1.3rc2 amendments
On 6/18/11 10:00 AM, Matthew Wild wrote: > Hi, > > A few more small issues with XEP-0198 have come to my attention. > > The largest of them is that the XEP says the 'h' attribute is optional > on , I don't think this should be allowed because the server > needs to know which stanzas the client received before its old session > was disconnected so it can re-send them. After a resume is usually the > only time stanzas can and should ever be re-sent. If 'h' is made > optional at resume time then the server has to special-case the first > from a client after resumption, and also distinguish between > stanzas it sent on the old connection(s) and on the new one. Many > headaches lie this way, for a tiny convenience in the protocol. Having pondered it a bit, I think that's right. I suggest: ### To request resumption of the former stream, the initiating entity sends a element qualified by the 'urn:xmpp:sm:3' namespace. The element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MUST include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the client (in the unlikely case that the client never received any stanzas, it would set 'h' to zero). Example 10. Stream resumption request C: If the server can resume the former stream, it MUST return a element, which MUST include a 'previd' attribute set to the SM-ID of the former stream and MUST also include an 'h' attribute set to the sequence number of the last handled stanza sent over the former stream from the client to the server (in the unlikely case that the server never received any stanzas, it would set 'h' to zero). Example 11. Stream resumed S: ### > Also in several places the XEP mentions Stream Management needing to > be explicitly enabled in "both directions". I can't recall if this was > the case in a previous version of the spec, but I don't believe it to > be the case now - when enabled, both parties send and receive and > . Correct. > Also some instances of "initiating entity" should be changed to > "client" in the vein of the other recent edits to 1.3rc2. Done. > Additionally I think it might be worth adding a note at the very end > of section 4, with words to the effect that there is no guarantee that > an unacknowledged stanza was not in fact received by the peer - in > other words, re-sending or otherwise dealing with unacknowledged > stanzas has the potential to produce duplicates. How about this? ### Because unacknowledged stanzas might have been received by the other party, resending them might result in duplicates; there is no way to prevent such a result in this protocol, although use of the XMPP 'id' attribute on all stanzas can at least assist the intended recipients in weeding out duplicate stanzas. ### > Based on feedback I think we should add as the first item in the list > at the end of section 5 something like: "The sequence values are > carried over from the previous session and are not reset for the new > stream.". Agreed. > The current first entry in that list (about retransmitting stanzas) > may be deserve a little more explanation, e.g. with this text: > > [[ > Upon receiving a or element the client and server > use the 'h' attribute to retransmit any stanzas lost by the > disconnection. In effect, it should handle the element's 'h' attribute > as it would handle it on an element (i.e. marking stanzas in its > outgoing queue as handled), except that after processing it MUST > re-send to the peer any stanzas that are still marked as unhandled. > ]] (this also changes re-sending from SHOULD to MUST, which I believe > is required to stop things going very wrong) That's better, thanks. > The final issue is that the schema needs updating - it says can > have a 'h' attribute, while the text (correctly) says it has none. Fixed. http://xmpp.org/extensions/tmp/xep-0198-1.3.html http://xmpp.org/extensions/diff/api/xep/0198/diff/1.3rc2/vs/1.3rc3 http://xmpp.org/extensions/diff/api/xep/0198/diff/1.2/vs/1.3rc3 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
