[Standards] XEP-0301 Question about Real-Time Text Message Editing

. - Scan backwards on both before-and-after strings to find last differing character. This allows you to generate action elements for mid-text modifications, without needing to erase backwards from the end of the string. Thanks, Mark Rejhon

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

my memory, XEP-0115 is a SHOULD rather than a REQUIRED. Yes, that's all a basic XEP-0301 implementations absolutely requires. Thanks, Mark Rejhon

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

On Mon, Oct 26, 2015 at 12:49 PM, Florian Schmaus wrote: > > XEP-0115 is Entity Capabilities > > http://xmpp.org/extensions/xep-0115.html > > It's a rather important standard that's still DRAFT. > > Entity Capabilities are important to avoid lookups. But they are only an >

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

+Cc: Christian Vogler For completeness sake, I'm very interested in seeing Christian follow up. He is the author of http://tap.gallaudet.edu/rtt/ supporting XEP-0301. On Thu, Oct 22, 2015 at 4:03 PM, Peter Saint-Andre - wrote: > [sending on behalf of the XSF's Editor Team] >

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

r needs them. These are necessary inclusions as an OPTIONAL feature as these are of interest to other implementers. In this case, again, it is an implementer's choice how to design the user interface: The protocol just simply makes it possible. Thanks, Mark Rejhon

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

I forgot to add: On Tue, Nov 3, 2015 at 10:37 PM, Mark Rejhon <marky...@gmail.com> wrote: > On Tue, Nov 3, 2015 at 9:02 PM, Christian Vogler < > christian.vog...@gallaudet.edu> wrote: > >> a. I don't see the use case for tracking RTT state by full JID. It seems >&

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

On Mon, Oct 26, 2015 at 12:34 PM, Dave Cridland <d...@cridland.net> wrote: > > On 25 Oct 2015 5:56 pm, "Mark Rejhon" <marky...@gmail.com> wrote: > >> 5. Should referenced/dependent XEPs (especially XEP-308) be Final > before this one becomes Final? >

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

On Sat, Oct 24, 2015 at 5:33 PM, Christian Schudt wrote: > XEP-0301 is one of the best written XEP out there (and I’ve read most of > them and implemented many)! It is very comprehensive and generally feels > well-thought-out and high quality. Development was fun and

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

. Fortunately, developer experience on 0301 has been overall generally more-positive-than-expected (considering size of standard); and we look forward to hearing more CfE feeback. Thanks, Mark Rejhon

[Standards] XEP-0301 Annual review (In-Band Real Time Text)

lementations comply with the latter schema. Therefore, implementations have correctly implied the correct usage. Thus, I don't think namespace should need to increment. Comments? Thanks, Mark Rejhon

Re: [Standards] Standard for Throttling/Queueing Stanzas

On Mon, Oct 28, 2013 at 11:47 AM, Peter Waher peter.wa...@clayster.comwrote: The envisioned XEP however is not IOS specific, but rather concerns battery-powered sensors, but can be applied to sensors in resource constrained networks (where bandwidth is constrained). The same solutions can be

Re: [Standards] XEP-0301 pre-draft feedback (MUC Discovery Addition)

it (See [[[Support for Groupchat]]]). Sincerely, Mark Rejhon

Re: [Standards] XEP-0301 pre-draft feedback

/CSharp/RealTimeText.cs JavaScript: https://github.com/cvogler/trophyjs/blob/master/trophy.js Thanks, Mark Rejhon

Re: [Standards] 301 feedback part1

Re: http://www.xmpp.org/extensions/xep-0301.html On Tue, Jul 16, 2013 at 4:20 PM, Peter Saint-Andre stpe...@stpeter.imwrote: Where do we stand on finishing this round of edits? We are finished with the edits, with the sole exception of Kevin's comment on the normative in Section 6.2. Keep

Re: [Standards] 301 feedback part1

to just follow (1). As a result, I want to word things in a way that allows the implementer to decide what is easiest; Thanks! Mark Rejhon

Re: [Standards] 301 feedback

, as mentioned in 4.3 Processing Rules. If this was unclear, let me know how to tweak this. It's still long, but I found the XEP much clearer and easier to read than I did the early versions, so thank you to the authors for the improvements they've made. Appreciated, Mark Rejhon

Re: [Standards] 301 feedback

On Tue, Jul 2, 2013 at 1:46 PM, Mark Rejhon marky...@gmail.com wrote: 4.7 For implementation simplicity, recipient clients MAY track incoming rtt/ elements per bare JID localp...@domain.tld to keep only one real-time message per sender Would this really help implementors? Trying to do bare

Re: [Standards] 301 feedback

of XEP-0085. Thanks Mark Rejhon On Tue, Jul 2, 2013 at 2:45 PM, Gunnar Hellstrom gunnar.hellst...@omnitor.se wrote: On 2013-07-02 20:28, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/2/13 11:46 AM, Mark Rejhon wrote: On Tue, Jul 2, 2013 at 12:23 PM, Kevin

Re: [Standards] XEP-0301 0.5 comments [Sections 6 and beyond]

sections)? Thanks! Mark Rejhon

[Standards] Fwd: XEP-0301 0.5 comments [Sections 6 and beyond]

Sending to the list, seems like one reply got off-list: -- Forwarded message -- From: Mark Rejhon marky...@gmail.com Date: Tue, Jul 2, 2013 at 4:35 PM Subject: Re: [Standards] XEP-0301 0.5 comments [Sections 6 and beyond] To: ke...@kismith.co.uk On Tue, Jul 2, 2013 at 4:28 PM

Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)

in the middle of section 6.5 SOLUTION: Delete right bracket from this phrase in the middle of 6.5. If Element w/ – Wait Interval] is supported ___ COMMENT 13: From Mark Rejhon: In 4.7 last paragraph, insert bare JID and full JID SOLUTION: Change: localbare; Into: bare jid localbare; Change: localfull

Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)

/correctness corrections: - One ] typo character, needs to be removed - Change per localp...@domain.tld into per bare JID (localp...@domain.tld) - Change per localp...@domain.tld/resource into per full JID (localp...@domain.tld/resource) Thanks! Mark Rejhon

Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)

. It was hard to avoid including the kitchen sink, but we all did it. Mark Rejhon

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

developed implementations is proof. I am hereby submitting a request to XSF to proceed with LAST CALL. Sincerely, Mark Rejhon Primary Author of XEP-0301

Re: [Standards] XEP-0301: Javascript implementation of in-band real-time text

-- it has a big font mode, useful for conference room projector demonstrations and for visually impaired usage. It is also licensed under Apache 2.0 too as well. Thanks Mark Rejhon

Re: [Standards] XEP-0301 (In-Band Real Time Text) - review observations

as a suggestion. I'll tweak Section 6.5 as that is an Implementation Note. Mark Rejhon

Re: [Standards] FMUC master/slave

On Fri, Mar 1, 2013 at 1:42 PM, Kevin Smith ke...@kismith.co.uk wrote: Hi folks, While I was originally writing 289, I misinterpreted a requirement I'd heard, and this led me to believe that master/slave mode was needed. I've since convinced myself that only the master/master mode is

Re: [Standards] XEP-0308 (Last Message Correction) correct last or any previous message

On Tue, Jan 15, 2013 at 5:52 PM, Gunnar Hellstrom gunnar.hellst...@omnitor.se wrote: On 2012-08-31 14:27, Kurt Zeilenga wrote: On Aug 31, 2012, at 4:09 AM, Dave Cridland d...@cridland.net wrote: I'm still concerned that replacing any but the author's last message is likely to cause problems

Re: [Standards] XEP-0301 Version 0.8 draft now being previewed

On Mon, Jan 14, 2013 at 1:16 PM, Mark Rejhon marky...@gmail.com wrote: I am happy to announce that the Version 0.8 draft of XEP-0301 is being reviewed before submission to XSF. The preview copy is now published on my website: http://www.realjabber.org/xep/xep-0301_v0.8.html I

[Standards] XEP-0301 Version 0.8 draft now being previewed

XSF team members, by making sure that Version 0.8 is really ready for submission. Sincerely, Mark Rejhon m...@realjabber.org

Re: [Standards] XEP-0301 Version 0.8 draft now being previewed

References: http://www.xmpp.org/extensions/xep-0301.html (This is the v0.7 version) XMPP In-Band Real-Time Text On Mon, Jan 14, 2013 at 1:16 PM, Mark Rejhon marky...@gmail.com wrote: I am happy to announce that the Version 0.8 draft of XEP-0301 is being reviewed before submission to XSF

Re: [Standards] NEW: XEP-0317 (Hats)

to be standardized at a future time) as granting permission to do certain things in in the chat software. A student raising a hand in a MUC (/me raises hand) can be temporarily given a special hat, that temporarily grants them these privelages of presenting rich media to the chatroom in a controlled way. Mark

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

protocol will be compatible with either method. As for my XEP-0301 updates, keep tuned. Workload and certain priorities has increased as of late, but I will be catching up. I know that the U.S. access board has inquired asking about when it'll be ready. Thanks, Mark Rejhon

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

On Thu, Sep 6, 2012 at 2:02 AM, Dave Cridland d...@cridland.net wrote: Oh, if you take it out of context like that, then yes... I was talking about my suggestion of a removable prefix Ok, my apologies -- I didn't realize it was sender-appended prefixes. Much like the me XEP-0245, where /me is

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

considered an acronym in general use. Government legislation about TTY http://www.access-board.gov/ada-aba/html/tech-07.html Do not even expand TTY. Why should we?? Thanks, Mark Rejhon On Thu, Aug 23, 2012 at 3:52 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-08-23 18:31

[Standards] Removal of company names from XEP-0301

-time text. (Reach 112, although a consortium, is in a major part, government funded) -- From this, I believe that all commercial names will have been removed from XEP-0301 to the best of my knowledge. Any comments? Thanks, Mark Rejhon

Re: [Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

Hello Peter, Thanks for clarifying the unclear areas -- appreciated! I do have some small further inquiries about Unicode handling: On Thu, Aug 23, 2012 at 11:20 AM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/22/12 1:24 PM, Mark Rejhon

Re: [Standards] review of XEP-0301, sections 6-14

) in any order. xs:choice minOccurs='0' maxOccurs='unbounded' xs:element ref='t' '/ xs:element ref='e' / xs:element ref='w' / /xs:choice Thanks for listening! You're welcome! Mark Rejhon

Re: [Standards] review of XEP-0301, sections 6-14 - #41 IM research

. one of them publicly commented -- Darren of Teligent U.K. expressed this concern) Thanks Mark Rejhon

Re: [Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

to deactivate real-time text, then resumes typing, etc). This is not covered in the spec, and might not be clear to all. (Context from Peter below) On Fri, Aug 17, 2012 at 11:00 PM, Mark Rejhon marky...@gmail.com wrote: What if the sending client disables RTT? Does it send a message with a body

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

On Wed, Aug 22, 2012 at 3:58 PM, Matthew Miller linuxw...@outer-planes.net wrote: What about URLs that are not in a/ elements? Frankly, too bad so sad. The sender really ought to have put them in anchors in the first place. It seems some XHTML-IM clients seem to URL-ize links that are not

Re: [Standards] Comments on XEP-0301 -- Section 1

. It's somewhat political behind the scenes in the various communities, so changes to this bullet will need to be done very carefully. I spent many hours rewording just the Introduction as a result. Mark Rejhon

Re: [Standards] Comments on XEP-0301 -- Section 1

On Wed, Aug 22, 2012 at 4:46 PM, Matthew Miller linuxw...@outer-planes.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 14:42, Mark Rejhon wrote: On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller linuxw...@outer-planes.net wrote: * Teletypewriter (TTY) and Text

Re: [Standards] Comments on XEP-0301 -- Section 1

Engineering and Biomedical Engineering University of Wisconsin-Madison On Aug 22, 2012, at 4:28 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-08-22 22:58, Mark Rejhon wrote: On Wed, Aug 22, 2012 at 4:46 PM, Matthew Miller linuxw...@outer-planes.net wrote: -BEGIN PGP SIGNED

Re: [Standards] review of XEP-0301 [ event='reset']

On 2012-08-20 3:32 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-08-19 21:21, Gunnar Hellström wrote: On 2012-08-19 19:11, Mark Rejhon wrote: My proposal has now become: event='new' Senders MUST use this value when transmitting the first rtt/ element containing Action

Re: [Standards] review of XEP-0301 [ event='reset']

On 2012-08-20 4:15 AM, Mark Rejhon marky...@gmail.com wrote: On 2012-08-20 3:32 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-08-19 21:21, Gunnar Hellström wrote: On 2012-08-19 19:11, Mark Rejhon wrote: My proposal has now become: event='new' Senders MUST

Re: [Standards] review of XEP-0301 [ event='reset']

On 2012-08-20 4:20 AM, Mark Rejhon marky...@gmail.com wrote: On 2012-08-20 4:15 AM, Mark Rejhon marky...@gmail.com wrote: 4.6.3 Refresh A message reset is a transmission of the sender's text from the beginning of the real-time message. The recipient can redisplay the real-time message

Re: [Standards] review of XEP-0301 [ event='reset']

tuned for 0.8 in a week or so. (After Peter's further review of section 6 onwards) Mark Rejhon

Re: [Standards] review of XEP-0301 [ event='reset']

between new/reset in presentation purposes (e.g. green flash or similar, for the start of a new message) On 2012-08-20 11:10 AM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/20/12 2:15 AM, Mark Rejhon wrote: On 2012-08-20 3:32 AM, Gunnar

Re: [Standards] review of XEP-0301 [ event='reset']

On 2012-08-20 11:47 AM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/20/12 9:39 AM, Mark Rejhon wrote: Well -- As it stands now, reprogramming RealJabber to use event=reset only (for both new and reset), or use event=new only (for both

Re: [Standards] review of XEP-0301 [ event='reset']

On Mon, Aug 20, 2012 at 12:55 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 2012-08-20 11:47 AM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/20/12 9:39 AM, Mark Rejhon wrote: Well -- As it stands now

Re: [Standards] review of XEP-0301 [ event='reset']

On Mon, Aug 20, 2012 at 2:48 PM, Mark Rejhon marky...@gmail.com wrote: On Mon, Aug 20, 2012 at 12:55 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 2012-08-20 11:47 AM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1

Re: [Standards] review of XEP-0301 [ event='reset']

On Mon, Aug 20, 2012 at 4:26 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-08-20 10:20, Mark Rejhon wrote: GH When the sender composes the part of the refresh that has been transmitted before, w/ elements shall not be included. MR I am not going to specifically disallow

Re: [Standards] review of XEP-0301 [ event='reset']

doing a time-smooth delay for the first t/. But give me a few days to test alternative protocol designs that resolves the confusion altogether, or alternative methods of wording the current protocol (using Message Refresh terminology instead of Message Reset terminology) Mark Rejhon I do

Re: [Standards] review of XEP-0301 [ event='reset']

On Sun, Aug 19, 2012 at 2:32 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-08-19 05:38, Mark Rejhon wrote: On 2012-08-18 10:08 PM, Peter Saint-Andre stpe...@stpeter.im wrote: To be fair, the event=new also exactly does the same thing -- it also clears the real-time

Re: [Standards] review of XEP-0301 [ event='reset']

On Sun, Aug 19, 2012 at 12:54 PM, Mark Rejhon marky...@gmail.com wrote: Not necessarily. The first element of 'reset' can be a e/ element (which would do nothing on a blank message, EXACTLY as if it were for 'new') The first element of 'reset' can be a w/ element (which would pause on a blank

Re: [Standards] review of XEP-0301 [ event='reset']

On Sun, Aug 19, 2012 at 12:58 PM, Mark Rejhon marky...@gmail.com wrote: When I say 'reset' is exactly the same as 'reset', I really mean it: I meant When I say 'reset' is exactly the same as 'new', I really mean it:' That was my intent for the spec. Exactly the same action element processing

Re: [Standards] review of XEP-0301 [ event='reset']

? And maybe introduce a separate (fourth) attribute for distinguishing message beginnings from message being reset/continued? Thanks, Mark Rejhon

Re: [Standards] review of XEP-0301, sections 1-5

On Sat, Aug 18, 2012 at 2:33 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-08-18 05:15, Mark Rejhon wrote: (for t/) and Basic Real-Time Text (whenever e/ is otherwise needed). A major potential implementer has indicated they prefer this method for simplicity (low CPU

Re: [Standards] review of XEP-0301 [ event='reset']

On 2012-08-18 6:50 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: The original issue 25. Note: There are no restrictions on using multiple Action Elements during a message reset (e.g. typing or backspacing occurring at the end of a retransmitted message). This seems potentially

Re: [Standards] review of XEP-0301, sections 1-5

-9725-3937Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Apple + Linux + Open Source software On Sun, Aug 19, 2012 at 1:44 AM, Mark Rejhon marky...@gmail.com wrote: On Sat, Aug 18, 2012 at 2:33 AM, Gunnar Hellström gunnar.hellst

Re: [Standards] review of XEP-0301 [ event='reset']

On 2012-08-18 10:08 PM, Peter Saint-Andre stpe...@stpeter.im wrote: To be fair, the event=new also exactly does the same thing -- it also clears the real-time message, so if I say what you say, I am also introducing a potential new confusion about the lack of distinction between event=new

Re: [Standards] review of XEP-0301, sections 1-5

OK, I proofread a second time, and noticed one more errata I need to make: On Fri, Aug 17, 2012 at 11:00 PM, Mark Rejhon marky...@gmail.com wrote: 16. Why is support for the e/ element only RECOMMENDED for senders? Given that most users will hit the backspace key (or equivalent) fairly

Re: [Standards] XEP-296 problem?

tradeoffs and compromises to decide. Mark Rejhon

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

) but I'd leave that out today -- and theoretically that can be dealt with separately someday (e.g. separate Message Correction Extensions XEP), provided the protocol is written generically enough today to be acceptable without that now, while being co-operative with future disco extensions. Mark Rejhon

[Standards] XEP-0308 and Linear Real-Time Text (TDD/textphones) - it is NOT a technical solution to social problem in this case.

(as agreed by me and Gunnar) is one solution to the linear real time text problem; it makes it possible to backspace across message boundaries, when gatewaying between linear real-time text to instant messaging, and vice-versa. Sincerely, Mark Rejhon

Re: [Standards] XEP-0308 and Linear Real-Time Text (TDD/textphones) - it is NOT a technical solution to social problem in this case.

On Tue, Aug 14, 2012 at 11:37 PM, Mark Rejhon marky...@gmail.com wrote: On Tue, Aug 14, 2012 at 3:21 PM, Kim Alvefur z...@zash.se wrote: On 2012-08-14T20:09:28 CEST, Kurt Zeilenga wrote: The more I think about it, the more I think I that this XEP is a bad idea. I think the concept itself

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

to a social problem), I believe it's just merely status quo feelings that is providing 0308 resistance. Thanks Mark Rejhon

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

Made] Thanks, I've queued this change. Thanks for all your suggestions, all of which are essentially minor changes and mostly implementation-notes related. With the exception of section 6.2, which warrants further discussion (Kevin, MM, Peter?) Thanks, Mark Rejhon

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

or alphabetically), though that's not always reliable. Thanks, Mark Rejhon

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

of replacing specific rtt/ elements. Mark Rejhon

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

On Mon, Aug 13, 2012 at 4:23 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.08.2012 22:05, schrieb Mark Rejhon: In addition, it would likely be non-backwards compatible in a graceful degrade manner, e.g. MUC [...] The way both me and Kevin has currently specified, ensures

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

On Mon, Aug 13, 2012 at 4:38 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.08.2012 19:06, schrieb Kurt Zeilenga: I rather the client simply add the replacement message to the message stream (as it would any other new message) and provide me some indication that it's a replacement

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

Apple + Linux + Open Source software On Tue, Aug 14, 2012 at 1:29 AM, Mark Rejhon marky...@gmail.com wrote: [ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ] Hello Gunnar, Thanks very much for the minor corrections to XEP-0301. I have queued your edits. My present judgement

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

, it now refers to a message 2 messages ago. (id is valid). So what you need to do, is essentially specify that unrecognized or unhandled 'id' should mean replace should be ignored and the re-transmitted message displayed as a brand new message. Probably the simplest solution. Thanks, Mark Rejhon

Re: [Standards] Comments on XEP-0301 (possible impact on -0308 in Section 4.2.3)

be done -- we're all ears! Thanks, Mark Rejhon

Re: [Standards] Comments on XEP-0301 (possible impact on -0308 in Section 4.2.3)

) -- follow UAX #9 for text directions in Unicode -- http://unicode.org/reports/tr9/ ... So text direction has gradually over the many years, become more and more of a GUI toolkit responsibility nowadays. Thanks Mark Rejhon

Re: [Standards] Comments on XEP-0301 (possible impact on -0308 in Section 4.2.3)

On Sat, Aug 4, 2012 at 4:06 AM, Mark Rejhon marky...@gmail.com wrote: Next, we use existing protocol (the way Kevin and I agreed) to allow the user to replace the word airlock with window: message to='jul...@capulet.net/balcony' id='good1' rtt event='reset' seq='4321' id='bad3' But soft, what

Re: [Standards] Comments on XEP-0301 (possible impact on -0308 in Section 4.2.3)

of Paul's example. On Sat, Aug 4, 2012 at 5:46 AM, Mark Rejhon marky...@gmail.com wrote: On Sat, Aug 4, 2012 at 4:06 AM, Mark Rejhon marky...@gmail.com wrote: Next, we use existing protocol (the way Kevin and I agreed) to allow the user to replace the word airlock with window: message to='jul

Re: [Standards] Comments on XEP-0301 (possible impact on -0308 in Section 4.2.3)

in rtt/ were already buffered) Regardless, in all cases, h will be 100ms before e in both correct scenario cases (assuming stable network ping :-) I didn't think I needed to explain these scenarios in the specbut should I? Comments? Cheers Mark Rejhon

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

Note: Precedent on image embeds exists -- an example image is embedded into XHTML-IM (XEP-0071). On 2012-08-01 8:53 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 7/23/12 1:17 PM, Mark Rejhon wrote: [Question] Understood -- animation really helps explains real-time text

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

of authority here. - - mm Matthew A. Miller http://goo.gl/LK55L On Aug 1, 2012, at 07:46, Mark Rejhon wrote: Note: Precedent on image embeds exists -- an example image is embedded into XHTML-IM (XEP-0071). On 2012-08-01 8:53 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 7/23/12 1:17

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

On 2012-08-01 11:15 AM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was suggesting that we host the image at xmpp.org but not embed it in the document -- I don't particularly want an animated GIF in the middle of the spec, but I'd like to have

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

0301 to use 'id' attribute -- for a client that implements both 0308 and 0301? Mark Rejhon GH A MUST for supporting reception of id= when you have negotiated both 0301 and 0308 is the logical conclusion. And if you transmit rtt during the correction then that MUST be marked with id

[Standards] Version 0.6 of XEP-0301 submitted -- copy posted at my site.

. Unified e/ element (Erase Text) to handle all possible text deletions. Clarify the Unicode terminology used in this specification, and move section 4.5.4 downwards to section 4.7 to improve reading order. (MDR) Thanks, Mark Rejhon P.S. One small note: The xep.ent file is slightly outdated

Re: [Standards] XEP-0301 0.5 comments -Unicode characters

, the terminology has been made more user-friendly and compatible with widespread usage, and the handy RFC5198 provides me a convenient reference. Thanks, Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments -Unicode characters

normal forms -- and I'll mention NFC it is. Yes, it's true that XML standard requires LF and RFC5198 requires CRLF. The RECOMMENDED's and SHOULD's are fine. Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments -xml:lang

captioning/translations in their languages. XSF: I need comments by the end of today, about whether it is OK to hold this off till 0.7. Gunnar: I need comments, is this related to the European procurement interests that you told me about? Thanks Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

that these are the same thing? This would seem helpful, if not. [Change Made] I've now added this clarification to Summary of Attribute Values I'm expecting to submit 0.6 by end of today (or tomorrow at latest). Thanks Mark Rejhon

[Standards] XEP-0301 0.5 comments [resetting versus randomizing 'seq' attribute]

#keeping_realtime_text_synchronized On Fri, Jul 27, 2012 at 10:19 AM, Mark Rejhon marky...@gmail.com wrote: The bounds of seq is 31-bits, the range of positive values of a signed integer - I'd be inclined to make this something like The seq attribute has an upper bound of 2147483647 (2^31 - 1). If this upper

Re: [Standards] XEP-0301 0.5 comments [resetting versus randomizing 'seq' attribute]

overflow. which already provides the umbrella for this. It's generic enough, and suggests exactly the same thing. I have made a minor change, for now: c/MAY/SHOULD/ -- I've upgraded it to SHOULD. Thanks, Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Unicode talk and 'seq' talk replied to, under their appropriate thread titles -- to compartmentalize the topics better. (those are potentially contentious items during reviews) The event attribute MAY be omitted from the rtt/ element during regular real-time text transmission - what is the the

Re: [Standards] XEP-0301 0.5 comments [resetting versus randomizing 'seq' attribute]

JID. (Note: full JID may not be available in all MUC's) Thanks, Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Thanks Mark rejhon

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

On Fri, Jul 27, 2012 at 5:35 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-07-27 23:24, Mark Rejhon wrote: On Fri, Jul 27, 2012 at 4:31 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: GHNo, please make a MUST for id= in edit previous. I can imagine presentation

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

More changes made, after thought and consultations. I think I've now addressed 90% of the section 1-5 concerns by Kevin. Some small unanswered questions in the original email (not included here), but this email aims to reduce workload for Kevin. On Mon, Jul 23, 2012 at 3:17 PM, Mark Rejhon marky

Re: [Standards] XEP-0301 0.5 comments -Unicode characters

a strict/fuller sender normalization standard (before the rtt encode) so that further normalization is unlikely to affect code points. Thanks Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments -Unicode characters

On Thu, Jul 26, 2012 at 6:04 PM, Mark Rejhon marky...@gmail.com wrote: On 2012-07-26 5:34 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: I think we have not solved this issue yet. On 2012-07-25 11:06, Kevin Smith wrote: 4.5.4.3 - A single UTF-8 encoded character equals one code

Re: [Standards] XEP-0301 0.5 comments [Clarification about Client Switching / Single JID Handling]

experience) details, such as what I described above? I have been told to avoid describing UX details. Thanks Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments [Clarification about Client Switching / Single JID Handling]

On Wed, Jul 25, 2012 at 12:01 PM, Mark Rejhon marky...@gmail.com wrote: There's no logging off involved -- They keep running simultaneous. References: http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized Due to the misunderstanding, I feel I might need to explain

  1   2   3   4   >