On Mon, Jun 25, 2012 at 10:19 PM, Peter Saint-Andre <[email protected]>wrote:
> I've had a chance to review XEP-0301 in some detail. > > First, overall I think it is in good shape, I don't have any major > concerns, and I think it is appropriate for advancement on the standards > track at the XSF. > Peter, Excellent comments, and I agree with most of your edits. I will be incorporating them during this week, along with the edits I have already mentioned I plan to make. I would like to address some certain comments you made: [Peter, I'd like your comment about the Unicode 'conundrum', see the bottom of message] In Section 4.6.4, why is it a SHOULD to retransmit a partially composed > message in the circumstances enumerated there? I don't see what difference > this makes regarding interoperability. > It was unexpectedly found to very important from the context of Next Generation 9-1-1 for obvious reasons. ...Retransmission is recommended because otherwise the real-time text is ignored until the next "event" attribute (new or reset). Clients that connects and begin seeing real time text in mid-message (i.e. <rtt/> without an event attribute), <rtt/> immediately is ignored (out of sync) until the next "event" attribute, because of section 4.6.2. <rtt/> does not get displayed at the start of a conversation, until an <rtt/> element with an 'event' attribute. ...This means if a client does not support retransmission, the recipient sees nothing until the sender begins typing the next message. This can lead to uncomfortably long delays before real time text becomes visible again. Danger, Will Robinson, Danger -- deaf sender trying to write to a 9-1-1 dispatcher over XMPP. Especially real-time text makes senders decide to hit Enter less often. A tendancy of typing longer messages have been observed whenever real time text is enabled, increasing the importance of retransmissions. Sometimes, people have even been observed idling waiting for a response without them hitting Enter first, too! ...As you notice, 4.6.4 also recommend regular retransmission every 10 seconds to cover wide variety of unavoidable scenarios, including someone logging on one computer and logging off a different computer, switching IM apps, situations where a client crashes (server doesn't see signoff) and the user reconnects, or want to repopulate real-time text buffers for people who logged onto MUC in the last 10 seconds (without needing to retransmit the real-time message everytime someone joined the MUC) Sometimes the full JID changes, sometimes not -- so it's possible to have situations where a real time message reset is needed. Peter, can you recommend some wording changes, that would reflect the critical importance of retransmission, while satisfying interop? > The spec provides few guidelines about when to send multiple <message/> > stanzas vs. when to include multiple actions in the same <message/> > stanza (e.g., see the difference between the examples in Section 7.2 and > Section 7.3). I was expecting to find some text about this in the > section on Congestion Control. I will clarify this in the spec; Section 7.2 would occur if the text was written fast enough to fit in one transmission inteval (i.e. 700ms, the default recommendation) Section 7.3 would occur if the text was written slow enough to cover four transmission interval cycles (i.e. 700ms x 4 = 2.8 seconds) This is unrelated to congestion control; can you give me context as to what made you think 7.2 vs 7.3 was a congestion control issue? > A similar concern applies to this text > from Section 6.4.1: "For long messages, the final <rtt/> transmission > may be made in a separate <message/> than the <message/> containing the > <body/>." Why? When is this appropriate and when not? > As you already know, it is allowed for <rtt/> to be in the same <message/> as <body/>. Some servers have a message length limit (i.e. say, 8K per XMPP message). A large <message/> that would normally succeed with just normal message, might fail if the real time text is included. Imagine a large 4K copy-and-paste operation rapidly followed by hitting Enter/Send, so you suddenly have 4K+ of <rtt/> combined with ~4K of <body/>, in the same <message/>. Suddenly, 8K text plus XML overhead. This becomes beyond some XMPP server limits. Message can fail to get there as a result (compared to just pasting, waiting a few seconds, then hitting Enter -- to allow clients to transmit pending <rtt/> separately due to the real-time text transmission interval recommended in section 4.4.) -- It is not really critical for interop, but lost messages is quite undesirable -- An alternative is to suggest that <rtt/> should always be in separate <message/> than <body/> transmissions. That'd shorten the spec text. -- Can you suggest an alternative idea/wording, to allay this concern? interoperability. I fully realize that user interface issues are > important to the author, but it's not correct to use conformance > terminology here. I provide detailed suggestions in the next section of > my comments. Also, personally I strenuously avoid lowercase versions of > the RFC 2119 conformance terms these days to avoid any possible > confusion. Thus I tend to change "may" to "might" or "can" or "it is > acceptable to", "should" to "ought to" or "it is best to", "must" to > "needs to", etc. I commend this convention to the author. > Thanks for the suggestions. As you already noticed, I've done my best to keep the "REQUIRED"'s and "MUST's" only to the protocol in section 4 and earlier. The remainder of the document does not use "MUST"/REQUIRED" (section 6 and beyond) But yes, I agree -- I will remove RFC 2119 in the non-protocol sections -- as you recommend. > In Section 6.1.3, we find that "If additional accuracy is required, it > is also possible to timecode the <rtt/> elements." How? Is this a matter > for implementation? Is it out of scope for this specification? > Actually, it's out of scope. Will remove this part. (Timecoding of <rtt/> elements can be done by a private attribute recording system clock with milliseconds, and be used optionally by aware clients, to smooth out 'ping jitter' if desired -- but it's not an interop issue -- and can be just a backwards-compatible private enhancement if implementors need such precision, such as making captioning immune to ping jitter, etc.) SECTION 4.5.5 > Please see RFC 6365 regarding the terminology here. For example, I think > you want: > s/glyph/character/ > s/character glyphs/characters/ > s/surrogate code units/surrogate pairs/ > I am using terminology from the www.unicode.org spec, and from www.unicode.org/glossary/ - They use phrase "Surrogate Code Units" and not "Surrogate Pairs" - They use phrase "glyph images" (graphical representations, i.e. multiple characters can combine to one displayable glyph) - Refer to unicode.org/glossary definition of "character" and how it distinguishes from "glyph" I do think you're right I should clarify the word "glyph". s/glyph/glyph images/ *or* s/glyph/glyph graphics/ What is your recommendation? The text here says that "calculations of p and n values MUST be based on > Unicode code points". Are you sure that you mean code points? Given that > XMPP mandates the use of UTF-8, I think it would be safer and easier to > say "UTF-8-encoded code points" (the point about "Some Unicode encodings > use a variable number of bytes per Unicode character" is true but > hopefully irrelevant here). Unfortunately it's critically relevant. UTF-8 is simply a transmission medium and not a storage/processing layer medium for most XMPP libraries. More than 75% of XMPP libraries do provide the original UTF-8 data, incoming text is already converted to the programming language's Unicode format. Library typically converts incoming text to the programming language's native string format, which is almost never UTF-8. .....However, UTF-8/UTF-16/UTF-16LE/UTF-16BE/UTF-32 all are exactly equal when all are processed as Code Points. Therefore, we get consistency, no matter how the XMPP library presents Unicode strings. Much safer! ....Java doesn't have a 'char' type -- it doesn't have an 8-bit character. ....One popular example, the Java 'smack' library (and Android 'asmack') stores incoming XMPP XML as a 16-bit Unicode string (UTF-16). Java does not have an 8-bit 'char' type, except as byte arrays, which aren't easily processable. Incoming XML in this Java library is converted to UTF-16 for internal processing by the library, and outgoing XML is converted back to UTF-8. ....If I theoretically used UTF-8, I can get corruption if I accidentally spliced a long UTF-8 character (i.e. during real-time editing in a poorly implemented UTF-8 client). Splicing via Unicode Code Points is much safer, and does not result in a character suddenly becoming a different character, and buggy clients will show very clear and easily-fixible splicing errors (i.e. off-by-one errors), such as text inserted/deleted that's one-character-off. ....Code Points, is therefore the safest and most interoperable method, that works irregardless of whatever Unicode format the programming langauge uses (XMPP library, language limitations, etc) and therefore, allows XEP-0301 to be compatible with virtually all XMPP libraries worldwide. Just look at Java -- it doesn't even have an 8-bit 'char' type! ....Code Points allow complete interop between clients of dissimilar Unicode storage formats. A client using char8 libpurple interops with char16 libpurple, a Java client using UTF16 interops with C++ UTF32, no problem -- because all strings convert to UTF-8 for transmission. ....See this flowchart: http://www.realjabber.org/flowchart_of_xmpp_rtt_path.pdf Can you suggest other alternatives, that would satisfy this situation? (we tried) Or given the info above, do you agree code points is the safest way? Sincerely, Mark Rejhon
