[Standards] RTT, take 2

Peter Saint-Andre stpeter at stpeter.im
Thu Jun 23 04:03:53 UTC 2011


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='juliet at capulet.lit' from='romeo at montague.lit/orchard'
type='chat' id='a01'>
  <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
    <t>Hello, </t>
  </rtt>
</message>

<message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
type='chat' id='a02'>
  <rtt xmlns='urn:xmpp:rtt:0' seq='1'>
    <t>my </t>
  </rtt>
</message>

<message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
type='chat' id='a03'>
  <rtt xmlns='urn:xmpp:rtt:0' seq='2'>
    <t>Juliet!</t>
  </rtt>
</message>

<message to='juliet at capulet.lit' from='romeo at montague.lit/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='juliet at capulet.lit' from='romeo at montague.lit/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='juliet at capulet.lit' from='romeo at montague.lit/orchard'
type='chat' id='a01'>
  <rtt xmlns='urn:xmpp:rtt:0' ruid='foo' seq='0' event='new'>
    <t>Hello, </t>
  </rtt>
</message>

<message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
type='chat' id='a02'>
  <rtt xmlns='urn:xmpp:rtt:0' ruid='foo' seq='1'>
    <t>my </t>
  </rtt>
</message>

<message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
type='chat' id='a03'>
  <rtt xmlns='urn:xmpp:rtt:0' ruid='foo' seq='2'>
    <t>Juliet!</t>
  </rtt>
</message>

<message to='juliet at capulet.lit' from='romeo at montague.lit/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='bob at example.com' from='alice at example.com/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='bob at example.com' from='alice at example.com/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='bob at example.com' from='alice at example.com/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='bob at example.com' from='alice at example.com/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='alice at example.com' from='bob at example.com/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='alice at example.com' from='bob at example.com/home' type='chat'
id='b02'>
  <rtt xmlns='urn:xmpp:rtt:0' seq='1'>
    <t> Alice</t>
  </rtt>
</message>

and

<message to='alice at example.com' from='bob at example.com/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/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110622/b12692d2/attachment.bin>


More information about the Standards mailing list