Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

[Gunnar Hellström]

On 2012-07-10 17:32, Mark Rejhon wrote:
The only one I'd be cautious about is that 6.4.3 needs to be a 
distinct section; because it is less confusing to vendors trying to 
transmit from key press events; that way they can understand the 
"gotchas" of doing that (i.e. missed autospell fixes, missed 
copy+paste events, etc.) ... I've gotten feedback that gave an 
excellent rationale for 6.4.3 being part of 6.4


I found it strange, that 6.4 intended to be about real-time 
methodologies, and then 6.4.3 tells about a non-recommended method, but 
does not tell what to do instead. ( that is found in 6.4.4. )


I did want to start the advice in 6.4 subsections with something 
positive to follow in the normal case. Therefore 6.4.4 with added 
precaution in the beginning about why not using keypresses seemed to 
cause the best flow.


But if you want, you could start with 6.4.4, changing a little in the 
beginning so that it does not refer to something earlier discussed.


then follow on with 6.4.3   and add a conclusion at the end "Therefore 
it is better to use change detection instead of keypresses."


Then 6.4.1 and 6.4.2

Gunnar

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

[Mark Rejhon]

On Tue, Jul 10, 2012 at 11:58 AM, Edward Tie  wrote:

>  I have found a information about larger sms :
>
> Edward, thanks -- but I'm already aware of this.  Message Resets has no
size limit, so implementers need to decide when too big is too big.  I do
warn about bandwidth issues in that paragraph already, so that is
sufficient. The implementer is responsible for determining the maximum size
of messages, as an implementation issue, and is beyond the scope of the
protocol.

P.S. We want to limit out-of-scope discussion, please.  We're hogging the
mailing list, and I'd like to refocus discussions.
Thanks
Mark Rejhon

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

[Edward Tie]

Op 10/07/2012 17:32, Mark Rejhon schreef:
On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström 
mailto:gunnar.hellst...@omnitor.se>> wrote:


Mark,
I see that you in this version have introduced a couple of "odd"
real-time text transmission strategies in sections 6.4.1 and
6.4.2, based on the  'reset' event.

http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies


Gunnar -- several are excellent suggestions.

An explanation at the beginning of 6.4 The transmission strategy in 
6.4.1 and 6.4.2 is not recommended for messages bigger than 
approximately SMS size, for mobile devices that want to write very 
compact & simple implementations of real-time text that does not 
require much processing or battery -- and they can take advantage of 
stream compression to eliminate the redundancy disadvantage of message 
resets.  It was explained to me that it may actually use less 
bandwidth and less CPU in certain situations.   Even though it means a 
disadvantage of losing key press intervals (the intervals demonstrated 
at www.realjabber.org/anim/real_time_text_demo.html 
 ) which I 
already mention.

I have found a information about larger sms :


 Message size

Transmission of short messages between the SMSC and the handset is done 
whenever using the Mobile Application Part 
 (MAP) of the SS7 
 protocol. Messages are 
sent with the MAP MO- and MT-ForwardSM operations, whose payload length 
is limited by the constraints of the signaling protocol to precisely 140 
octets  (140 octets 
= 140 * 8 bits = 1120 bits). Short messages can be encoded using a 
variety of alphabets: the default GSM 7-bit alphabet 
, the 8-bit 
 data alphabet, and the 16-bit UCS-2 
 alphabet.^[35] 
 
Depending on which alphabet the subscriber has configured in the 
handset, this leads to the maximum individual short message sizes of 160 
7-bit  characters, 140 8-bit 
characters, or 70 16-bit characters. GSM 7-bit alphabet support is 
mandatory for GSM handsets and network elements,^[35] 
 
but characters in languages such as Arabic, Chinese, Korean, Japanese or 
Cyrillic alphabet languages (e.g. Russian, Serbian, Bulgarian, etc.) 
must be encoded using the 16-bit UCS-2 
 character encoding 
 (see Unicode 
). Routing 
 data and other metadata 
 is additional to the payload size.


*Larger content (concatenated SMS 
, multipart or segmented 
SMS, or "long SMS") can be sent using multiple messages, in which case 
each message will start with a user data header (UDH) containing 
segmentation information. Since UDH is part of the payload, the number 
of available characters per segment is lower: 153 for 7-bit encoding, 
134 for 8-bit encoding and 67 for 16-bit encoding. The receiving handset 
is then responsible for reassembling the message and presenting it to 
the user as one long message. **While the standard theoretically permits 
up to 255 segments,^[36] 
 6 to 8 
segment messages are the practical maximum, and long messages are often 
billed as equivalent to multiple SMS messages.*

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

[Mark Rejhon]

On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

> Mark,
> I see that you in this version have introduced a couple of "odd" real-time
> text transmission strategies in sections 6.4.1 and 6.4.2, based on the
>  'reset' event.
> http://xmpp.org/extensions/**xep-0301.html#realtime_text_**
> transmission_methodologies


Gunnar -- several are excellent suggestions.

An explanation at the beginning of 6.4 The transmission strategy in 6.4.1
and 6.4.2 is not recommended for messages bigger than approximately SMS
size, for mobile devices that want to write very compact & simple
implementations of real-time text that does not require much processing or
battery -- and they can take advantage of stream compression to eliminate
the redundancy disadvantage of message resets.  It was explained to me that
it may actually use less bandwidth and less CPU in certain situations.
Even though it means a disadvantage of losing key press intervals (the
intervals demonstrated at
www.realjabber.org/anim/real_time_text_demo.html) which I already
mention.

Stream compression compensates for the bandwidth penalty of doing repeated
message resets as the method of a bare-bones implementation of XEP-0301.  I
also should additionally cite this as part of this paragraph, that if it's
done, it's a good idea to use stream compression, if available.   So when
done, the strategy isn't odd anymore :-)



> 3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method
> that is not recommended, and does not specify a solution, so it suits
> better as introductory warning words.  Use the title 6.4.3 Monitoring
> message changes.  delete title 6.4.4
>

The only one I'd be cautious about is that 6.4.3 needs to be a distinct
section; because it is less confusing to vendors trying to transmit from
key press events; that way they can understand the "gotchas" of doing that
(i.e. missed autospell fixes, missed copy+paste events, etc.) ... I've
gotten feedback that gave an excellent rationale for 6.4.3 being part of 6.4

Thanks
Mark Rejhon

Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

[Gunnar Hellström]

Mark,
I see that you in this version have introduced a couple of "odd" 
real-time text transmission strategies in sections 6.4.1 and 6.4.2, 
based on the  'reset' event.

http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies

I get the impression that you have introduced them after getting 
feedback that it is complicated to detect and convey real-time editing 
within a real-time message.


6.4.1 proposes to send the whole real-time message for every 
transmission interval that there has been any addition or modification 
to it.
6.4.2 proposes to send the whole real-time message repeatedly while the 
user is editing within the real-time message.


They are certainly possible to use, but have, as you point out in the 
last sentence of each section, some obvious disadvantages. One is that 
the length of these messages can be very long if the user has the habit 
of seldom indicating end of message.  That behavior maybe becomes a 
common habit when you get used to real-time text.


A new reader of the specification would however maybe not detect that 
the methods are odd, but read the headings and get the impression that 
this is the normal way of transmitting real-time text. 6.4.1 has the 
heading "Basic Real-Time Text." leading to the conclusion that this is 
normal.


I suggest some reordering, modifications of headers and slight wording 
changes to amend this.


1. Insert explanation in 6.4
"This section describes alternatives for how to detect and compose what 
shall be transmitted during real-time text operation.


2. In first line of 6.4.4 insert after "method" : "to detect what 
changes to transmit"


3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method 
that is not recommended, and does not specify a solution, so it suits 
better as introductory warning words.  Use the title 6.4.3 Monitoring 
message changes.  delete title 6.4.4


4. Replace the second sentence in 6.4.3 (starting with "However..."), 
with "However, this method has disadvantages."


5. Rename 6.4.1 to "Using 'reset' events to transmit changes.

6. Include a new first sentence in 6.4.1: "As an alternative to 
detecting and transmitting only the changes in the real-time message, 
the following method can be considered."


7. Move 6.4.3 to become 6.4.1, pushing earlier 6.4.1 and 6.4.2 down to 
become 6.4.2 and 6.4.3 respectively.






___
Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se
+46708204288