I've finally had the chance to read this proposal, too. In this message I post some responses to the issues that Kevin raises, interspersed with a few of my own observations. To be clear, although I don't have a vote because I don't sit on the Council, I'm in favor of publishing this as an Experimental XEP. My comments are to be taken in the spirit of further improvement.
On 6/22/11 9:52 AM, Kevin Smith wrote: > I've performed a quick review of the new proposal. I have a handful of > comments on the spec; I don't currently intend these to be blocking, > for my part, when Council vote to Experimental. I consider this a vast > improvement over the first proposed version of the document. > > I apologise if my thoughts aren't as coherent as they might be, these > were made while going through it and haven't been wordsmithed. 2.3, point 1: "Reliable message delivery." Really? In what sense? Is this spec defining a new standard for reliable message delivery, or depending on existing methods? > 4.2.2 Why SHOULD 0 (rather than MUST)? +1 to MUST. > 4.2.3.3 - Start shouldn't be used for discovery, disco/caps should. Agreed. > 4.2.3.4 - Cancel would be more consistent with other specs No preference here. > 4.3.2 Seems inappropriate - we should only be suggesting UI > behaviours, where they're not security critical, not mandating them. That seems right. Looking at the text and examples, I wonder if just sending a message with a <body/> is enough information for the recipient to present the messages appropriately. Consider this example: <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a01'> <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'> <t>Hello, </t> </rtt> </message> <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a02'> <rtt xmlns='urn:xmpp:rtt:0' seq='1'> <t>my </t> </rtt> </message> <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a03'> <rtt xmlns='urn:xmpp:rtt:0' seq='2'> <t>Juliet!</t> </rtt> </message> <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a04'> <body>Dude, what happened to my message?</body> </message> How does the recipient know that the last message is related or unrelated to the previous RTT fragments? We might consider including something like this in the last message: <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a04'> <rtt xmlns='urn:xmpp:rtt:0' event='done'> <body>Hello, my Juliet!</body> </message> That raises the question of whether we need identifiers for each RTT "sequence", as so: <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a01'> <rtt xmlns='urn:xmpp:rtt:0' ruid='foo' seq='0' event='new'> <t>Hello, </t> </rtt> </message> <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a02'> <rtt xmlns='urn:xmpp:rtt:0' ruid='foo' seq='1'> <t>my </t> </rtt> </message> <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a03'> <rtt xmlns='urn:xmpp:rtt:0' ruid='foo' seq='2'> <t>Juliet!</t> </rtt> </message> <message to='[email protected]' from='[email protected]/orchard' type='chat' id='a04'> <rtt xmlns='urn:xmpp:rtt:0' ruid='foo' seq='4' event='done'> <body>Hello, my Juliet!</body> </message> There are several reasons why we might want to consider tracking each RTT sequence (e.g., because the recipient might be receiving messages from the sender via multiple paths -- say, via groupchat and via a one-to-one chat). > 4.5.1.1 insert is ambiguous - what does 'at position p' mean? > Forward delete should be explicitly rightwards, if that's the intent. > How does this play with RTL languages? Good questions. > 4.5.1.3 Why are we dealing with utf-16 when everything is mandated utf-8? UTF-8 FTW. Also, this seems inconsistent with the forward delete function: "If the p attribute is omitted, the default value for p is the length of the current real-time message." How is that applied to the <d/> element? Is the 'p' attribute REQUIRED in that context? (You can't forward delete beyond the end of the message.) > 4.5.2.1 Discussions of counting whitespace scare me where whitespace > isn't significant > Would benefit from real numbers, and an example, I think. Ah, > examples in section 6. Could do with a forward reference. > > 4.5.2.6 We already have a spec for this http://xmpp.org/extensions/xep-0224.html > 4.5.3 What does an empty rtt mean? > Tier 2 being SHOULD isn't compatible with 4.5.2.6 saying it's OPTIONAL > I have a feeling that we need to normalise, not relying on > transmission being unmodified. > > 4.6.2 MUST here seems overzealous, best efforts seem reasonable given > the ultimate <body> correction. > > 5.1.1 Non-normative recommmended. > SHOULD NOT here seems overzealous again. > > 5.2.1 seems like an implementation note > 5.2.2 Non-normative SHOULD NOT > 5.2.3 Non-normative SHOULD > Shouldn't be describing the programming model used Agreed on all of those. > 5.4.1 Where does this maximum stanza size come from? RFC 6120 says: 4. A server implementation SHOULD enable a server administrator to limit the size of stanzas it will accept from a connected client or peer server (where "size" is inclusive of all XML markup as defined in Section 2.4 of [XML], from the opening "<" character of the stanza to the closing ">" character). A deployed server's maximum stanza size MUST NOT be smaller than 10000 bytes, which reflects a reasonable compromise between the benefits of expressiveness for originating entities and the costs of stanza processing for servers. A server implementation SHOULD NOT blindly set 10000 bytes as the value for all deployments but instead SHOULD enable server administrators to set their own limits. If a connected resource or peer server sends a stanza that violates the upper limit, the receiving server MUST either return a <policy-violation/> stanza error (Section 8.3.3.12), thus allowing the sender to recover, or close the stream with a <policy-violation/> stream error (Section 4.9.3.14). > Why do you need the final transmission? An earlier section says MUST > be ignored, IIRC. > All of 5 seems to be implementation notes, in fact Perhaps that's why the section title is "Implementation Notes". ;-) In Section 6.4: <message to='[email protected]' from='[email protected]/home' type='chat' id='a01'> <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'> <t>Hello Bob, this is Alice!</t><d n='4' p='5'/> </rtt> </message> Why not send two stanzas? <message to='[email protected]' from='[email protected]/home' type='chat' id='a01'> <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'> <t>Hello Bob, this is Alice!</t> </rtt> </message> and <message to='[email protected]' from='[email protected]/home' type='chat' id='a01'> <rtt xmlns='urn:xmpp:rtt:0' seq='1'> <d n='4' p='5'/> </rtt> </message> I ask this question, because clearly things can become quite complex, as shown in Section 6.7: <message to='[email protected]' from='[email protected]/home' type='chat' id='a01'> <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'> <t>Helo</t> <e/> <t>lo...planet</t> <e n='6'/> <t> World</t> <d n='3' p='5'/> <t p='5'> there,</t> <c p='18'/> </rtt> </message> In Section 6.8: <message to='[email protected]' from='[email protected]/home' type='chat' id='b02'> <rtt xmlns='urn:xmpp:rtt:0' seq='1'> <t> Alice</t> </rtt> <body>Hello Alice</body> </message> Again, why not two stanzas? <message to='[email protected]' from='[email protected]/home' type='chat' id='b02'> <rtt xmlns='urn:xmpp:rtt:0' seq='1'> <t> Alice</t> </rtt> </message> and <message to='[email protected]' from='[email protected]/home' type='chat' id='b02'> <body>Hello Alice</body> </message> > 6.9 - not sure the note about sums-to-1 is beneficial. No opinion here. Section 7.1 talks about interoperability with RFC 4103 and T.140. How does an XMPP entity negotiate an RTT session with a SIP entity? (I'm wondering if we need a Jingle application type for RTT...) > 8. Should not be using UTF-16 Agreed. > Security considerations might note that this scheme breaks FLOT labelling. In Section 9, a reference to XEP-0205 seems in order. That's all for now. Good work! Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
