-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/28/13 2:30 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0301 (In-Band Real Time Text). > > Abstract: This is a specification for real-time text transmitted > in-band over an XMPP session. Real-time text is text transmitted > instantly while it is being typed or created. > > URL: http://xmpp.org/extensions/xep-0301.html > > This Last Call begins today and shall end at the close of business > on 2013-06-28. > > Please consider the following questions during this Last Call and > send your feedback to the [email protected] discussion list:
I have one additional question: do both of the authors (re-)affirm that they are contributing this specification in conformance with the XSF's IPR Policy? http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ In addition, are the authors personally aware of any patents over their contribution, whether those patents might be held or applied for by the authors or any other persons or organizations they know of? > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? It does seem like a useful feature for certain populations and in certain scenarios, as outlined in the introduction. > 2. Does the specification solve the problem stated in the > introduction and requirements? I think it does. > 3. Do you plan to implement this specification in your code? If > not, why not? No, because I don't have client code in which to implement it. > 4. Do you have any security concerns related to this > specification? I request that the authors describe whether transmission timing attacks are possible even if message encryption is used. > 5. Is the specification accurate and clearly written? Overall the specification is clear, easy to read, and thorough. Good job! However, I have some technical and editorial comments... MAJOR ISSUES: None. MINOR ISSUES: Section 2: I think it would be worthwhile to mention both internationalization and security as goals. Section 4.2.1: "Recipients MUST monitor the seq value as an integrity check on received real-time text." In what sense does the seq value provide integrity, and what kind of integrity does it provide? What comes immediately to mind is data integrity, which RFC 4949 defines as follows: $ data integrity 1. (I) The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. (See: data integrity service. Compare: correctness integrity, source integrity.) 2. (O) "The property that information has not been modified or destroyed in an unauthorized manner." [I7498-2] Yet the seq value does not provide data integrity. Perhaps the authors mean something like in-order delivery? Section 4.3: "A random value is RECOMMENDED for improved integrity during Usage with Multi-User Chat and Simultaneous Logins." Here again I'm not sure the authors really mean 'integrity'. Section 6.3: Mention is made here of "remote cursor" but the term is not defined. NITS: Section 2.2 mentions "simultaneous logins". I assume this means "multiple simultaneous sessions associated with separate devices or user agents". This could also be clearer in Section 6.6.4.2. Section 4.3: "Sender clients MUST use either element as the first <rtt/> transmission of a new real-time message." What are the elements referred to here? Do you actually mean something like this? "Sender clients MUST use an <rtt/> element with an 'event' value of "new" or "reset" in the first stanza sent when starting composition of a new real-time message." Section 4.7.3: "When the recipient becomes available (e.g. presence changes to 'chat');" ... a change in presence to a <show/> value of "chat" does mean that the recipient has become available. This needs to be worded more carefully. Section 6.1.2: Please expand "VoIP" on first use. Section 8.1: With regard to address translation, please consider referencing draft-saintandre-sip-xmpp-core: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/ Section 10.3: Please expand "DoS" on first use, and consider adding a reference to XEP-0205. In addition, in my role as the XEP Editor I have made some small editorial corrections (e.g., subject-verb agreement) directly in the XML under source control at xmpp.org. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrqObAAoJEOoGpJErxa2pNUYP/RC9psX9MVK7MiqnM7PDJTHN 1NiBkjUG8Ab3Wgj9aXgSt85X5x6eu5E7BPLvysRCkeSGuWlLffAg+JntIl1m3yMi QMcGgK6GtLjX407Va64e5okp1/Cheb4aRm42vDmzRhALg4bvV4fn+a3C221xWJQt UUnYk/2l/BcdD1mbHKDGb/LW32F8InHxEx2J6lJvK/fKhWGF+7D04XBDG5e+h4KG yhuNqEGa0nwqRdPPYDW8m+QHWpbPtw27NqS2+Av16aNjomWV6kqndCvu9DKv6RTS ogOZO1XRh/8UZfTAVR+R2QEGv6QoxaZB7EXD0kj/MZlv/cKRsDjlS45df6h+aCsx CAApjtP+kuXl+j2KDeu1vhscqKfGEIPpIYRi4Giy9ZCPPEhmvp0VM0TagPKYL58/ Jqns7f/3UHt3dJEvFKJRxNIcz/U1W2Flx8YbHHp5g3AjejoTwv9tKuEo7xWjvvdJ yX3XzMlalZgALSWFmR5eI05BGe1qX/F47X5EEum2B2bEfxVwXyX8vx7o1eiv+Qu4 DtWf36NIKLQjTmOjmB918DWD1v+CtWCyB0y5UA4udpzSOP2V6n//K0rnz4qlkGja oX/7QVkGv/rKKRtPohAjUxb91B7TroFAe0IXaMtJ94R4giJa87lrJK8JSoA9CngI FdVF06U9h9cJtndiWoyU =A7oa -----END PGP SIGNATURE-----
