[Standards] XEP-0301 0.5 comments [Sections 6 and beyond]
gunnar.hellstrom at omnitor.se
Thu Jul 26 07:00:21 UTC 2012
On 2012-07-25 22:42, Mark Rejhon wrote:
>>>> > >>6.6.6 seems redundant.
<GH3>This is about the hint that XEP-0301 can be used together with
other real-time media to form Total Conversation or Text telephony and
an indication that Jingle is a suitable mechanism for this.
> [Change Made]
> Section moved to Interoperability Considerations, where it really
> belongs -- explanation below.
> (Side effect observed: Intriguingly, the section move apparently
> eliminates the weighty "6.6.6".)
> Before removal, I need to do consultations first, since parts of it is
> not redundant -- a part of XEP-0301 accessibility audience has never
> heard of Jingle before, so the reference is appropriate. In addition,
> several vendors including Gunnar Helstrom of Omnitor work with
> www.reach112.eu provide ITU-T F.703 (Total Conversation) compliant
> clients that are used for accessible emergency service in Europe. This
> isn't one package but multiple vendors adhering to standards. It's
> still a very vocal topic in a certain audience. This is a really
> small section, so I'd like to give it LAST CALL scrutiny before
> considering removal. I'll now do some consultations about removing
> this section, but it doesn't seem to be a blocker for LC.
<GH3> Yes, the application indication about combination with audio and
video needs to be kept.
The requirement is mentioned in 2.4.1, so it is not redundant to also
have a small section on how to fulfill it.
I have just gone through many other standards for real-time text and
seen that all, even the ones focusing on the transport of real-time
text, have some indication that they can be combined with other media in
the same session. That is important for usability.
And for XEP-0301 such indications should be in an implementation notes
style of chapter.
I agree that it might be placed in the interoperability section, even if
it more an "application environment" note.
I do not mind, as long as it is kept and placed somewhere visibly from
chapter 6 and onwards.
>>>> > >>10.1 - "It is important for implementers of real-time text to educate
>> >I think the first sentence could be removed and for the following to be
>> >"It is important for users of real-time text to be made aware..."
> [Change Made]
> "It is important for users to be made aware of real-time text (e.g.
> user consent, software notice, introductory explanation)"
>> >I suggest the following text.
>> >"An implementation MUST NOT activate sending sending of RTT without the user's consent".
>> >How implementers choose to interpret 'user's consent' is up to them,
>> >and seems to be a sensible balancing of allowing RTT-specific clients
>> >to behave sensibly when their users are expecting RTT while still
>> >requiring that mainstream clients don't start sending out people's
>> >passwords unexpectedly.
> [Change Made]
> Related change was already made, see above, without RFC2119 normative.
> (Peter Saint Andre suggested eliminating normatives beyond section 6)
> Note: Over a longer timescale, it is possible that people may get more
> familiar with real-time text (or "Fast Text") it can be acceptable to
> simply display a short software notice or such. (And putting the fine
> example, online customer support chat on a popular online shopping
> website circa 2020, or some other mainstream situation. If education
> about real-time text is widespread by then one way or another -- then
> real-time text might become largely expected and normal for various
> kinds of mainstream situations (such as this or others not foreseen)
> -- to the point where "user consent" merges with "just beginning to
> type" for certain specific situations. Because of this, I kept the
> recommended change very general (and the lawyers can handle the rest,
> if needed).
Yes, the warning and education must be a very short term need for
current IM users.
I have never seen a warning on a telephone saying "Remember that what
you say in this device can be immediately heard by the other party in
the call." ANd no consent question: "Do you accept to let your voice go
through to the other side in real-time?"
If this is the latest version of the paragraph( a bit hard to follow the
thread above), I agree: "It is important for users to be made aware of
real-time text (e.g. user consent, software notice, introductory
Good to see it converge.
More information about the Standards