Subject: [XCON] Chatroom Gap Analysis

From: Adam Roach <[email-masked]>
Date: Fri, 17 Aug 2007 18:46:19 -0500

As we discussed in Chicago, I have produced a gap analysis document that 
discusses the features available in currently deployed chatroom systems 
and which of these can be achieved using protocols defined by or 
currently under definition within the IETF.

Until it appears in the archives, you can grab a copy from:

http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.txt
or
http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.html

(The document isn't as polished as I'd like, but I think it gets all the 
important information across).

/a

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 18 Aug 2007 05:37:05 +0200

Adam,
The draft gives a good overview over many chatroom features.
However, I would like to see more on media and mode aspects.
Now, the only place I found saying anything about contents is 
"2.1.9.  Sending Files and Images to a Chatroom." saying that you can send
anything to a chatroom.

Questions:

1. In your analysis of existing chat-room applications, have you found more
orderly support for audio, video and images in addition to the default
support for text?

2. Have you found planned support for text messages in other writing systems
than left-to right?

3. Have you found support for the media to be transmitted and displayed in
real-time as they are created?

4. Have you found support for ordered transition between message mode and
real time mode?

I think it would be valuable to cover such aspects as well. 

Gunnar Hellström

-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Saturday, August 18, 2007 1:46 AM
To: XCON-IETF; [email-masked]'
Subject: [Simple] Chatroom Gap Analysis

As we discussed in Chicago, I have produced a gap analysis document that
discusses the features available in currently deployed chatroom systems and
which of these can be achieved using protocols defined by or currently under
definition within the IETF.

/a

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

__________ NOD32 2468 (20070817) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 Aug 2007 12:18:17 -0500

> orderly support for audio, video and images in addition to the default

Not so much -- pretty much anything that isn't text tends to result in 
some variation on a dialog box popping up asking where you want to save 
the content. MSRP actually does a bit better (in theory, at least), 
since you can specify an "inline" disposition for (e.g.) images, which 
*should* cause clients to render the image in the chat window instead of 
saving it to disk.

Exactly how this ends up being implemented is yet to be seen.

> 2. Have you found planned support for text messages in other writing systems

To the same degree as we have support in XMPP/SIMPLE -- the use of 
UTF-8, in theory, provides all the support necessary for RTL text. In 
practice, what different clients do when they see an RTL mark varies 
widely and is often inexplicable.

That is: the protocol gets this right, but implementors do random things.

> real-time as they are created?

Not in chatroom scenarios, no -- at least, not since ytalk. Do you know 
of a modern chatroom system that supports this?

That said, there's nothing stopping clients from setting up RFC 4103 
streams towards a mixer -- the tricky part is rendering such mixed 
streams in a coherent fashion.

> 4. Have you found support for ordered transition between message mode and

Not in existing systems, no.

All four items you mention above appear to be supported by IETF 
protocols, although it may not be immediately clear to implementors how 
a user interface might present them -- perhaps there's room for a 
document that address, in particular, the interaction of real-time text 
with multi-user conferences. A "best current practice" of sorts. Is that 
something you might be interested in tackling?

/a

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Aug 2007 07:01:55 +0200

Adam,

You say
"All four items you mention above appear to be supported by IETF protocols,
although it may not be immediately clear to implementors how a user
interface might present them -- perhaps there's room for a document that
address, in particular, the interaction of real-time text with multi-user
conferences. A "best current practice" of sorts. Is that something you might
be interested in tackling?"

I have started on a document in that direction. 
See: 
http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-01.txt

It describes a way to present real-time text that feels very familiar for
the IM and chatroom user. It just adds the opportunity to see the entries
from selected parties in the session while they are created.

It says that RFC 4103 would be the natural transport protocol for the text,
while also MSRP would be suitable if you take care to not transmit more than
at most once per second from parties actively composing entries. 

You are right in that real-time text mixer for multi-user conferences may
need further elaboration. Especially the requirement to allow remote erasure
of already transmitted text is a challenge for a real-time text mixer.

Do you see XCON or SIMPLE to be a suitable group for further work on this
draft?

----

My question had not only real-time text background. I am equally interested
in for example seeing good support for video in chat rooms, where the video
entries are not seen just as attachments to the text entry, but are handled
with full support for easy recording, entry and display in the chatroom. So,
I would appreciate if you could expand the media section a bit with more on
planned handling of multimedia contents. 

-Gunnar

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Monday, August 20, 2007 7:18 PM
To: Gunnar Hellström
Cc: 'XCON-IETF'; [email-masked]
Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects

On 8/17/07 10:37 PM, Gunnar Hellström wrote:
> Questions:
>
> 1. In your analysis of existing chat-room applications, have you found 
> more orderly support for audio, video and images in addition to the 
> default support for text?
>   

Not so much -- pretty much anything that isn't text tends to result in some
variation on a dialog box popping up asking where you want to save the
content. MSRP actually does a bit better (in theory, at least), since you
can specify an "inline" disposition for (e.g.) images, which
*should* cause clients to render the image in the chat window instead of
saving it to disk.

> 2. Have you found planned support for text messages in other writing 
> systems than left-to right?
>   

To the same degree as we have support in XMPP/SIMPLE -- the use of UTF-8, in
theory, provides all the support necessary for RTL text. In practice, what
different clients do when they see an RTL mark varies widely and is often
inexplicable.

> 3. Have you found support for the media to be transmitted and 
> displayed in real-time as they are created?
>   

Not in chatroom scenarios, no -- at least, not since ytalk. Do you know of a
modern chatroom system that supports this?

That said, there's nothing stopping clients from setting up RFC 4103 streams
towards a mixer -- the tricky part is rendering such mixed streams in a
coherent fashion.

> 4. Have you found support for ordered transition between message mode 
> and real time mode?
>   

All four items you mention above appear to be supported by IETF protocols,
although it may not be immediately clear to implementors how a user
interface might present them -- perhaps there's room for a document that
address, in particular, the interaction of real-time text with multi-user
conferences. A "best current practice" of sorts. Is that something you might
be interested in tackling?

/a

__________ NOD32 2470 (20070819) Information __________

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Aug 2007 10:33:23 -0500

> Do you see XCON or SIMPLE to be a suitable group for further work on this

The draft you currently have isn't conference specific -- it seems aimed 
at one-to-one chat sessions. Between the two groups, I'd say SIMPLE is 
the more appropriate, if you want to drive it through a working group.

As a personal observation, this kind of work has generally received low 
participation in SIMPLE, so you might be able to save yourself some 
process overhead by publishing it as informational. I would contact the 
RAI ADs for advice on the topic, though.

> planned handling of multimedia contents. 

What I think I hear you describing isn't as much "video in a chatroom" 
as it is "multimodal conferencing", where the modes include (1) a text 
chatroom, and (2) a video RTP stream. Correct me if that's not what you 
mean.

/a

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Aug 2007 20:33:44 +0200

Adam,
You say:
"What I think I hear you describing isn't as much "video in a chatroom" 
as it is "multimodal conferencing", where the modes include (1) a text
chatroom, and (2) a video RTP stream. Correct me if that's not what you
mean." 

No, I mean well integrated multimedia chat-rooms, where for example video
entries may come up as for example a thumbnail picture that strts to play
when you click on it. Text and audio and images belonging to such entries
are also displayed, on request.

About the draft-hellstrom-text-preview, you say:
"The draft you currently have isn't conference specific -- it seems aimed at
one-to-one chat sessions. Between the two groups, I'd say SIMPLE is the more
appropriate, if you want to drive it through a working group."
It talks about hiding and displaying preview from different participants,
and labelling entries depending on the source etc. So, it is definitively
aiming at the multi-participant situation, with the minimum number of
participants being two. 
With this real-time preview, the border between a real-time conference and a
chat-room is disappearing.

.
Another item:

I also have experienced that some chat roomms may have one audio stream
playing in order to present an attractive environment for the room. The same
could be defined for video and text.

Gunnar

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2007 5:33 PM
To: Gunnar Hellström
Cc: 'XCON-IETF'; [email-masked]
Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects

On 8/21/07 12:01 AM, Gunnar Hellström wrote:
> You are right in that real-time text mixer for multi-user conferences 
> may need further elaboration. Especially the requirement to allow 
> remote erasure of already transmitted text is a challenge for a real-time
text mixer.
>
> Do you see XCON or SIMPLE to be a suitable group for further work on 
> this draft?
>   

The draft you currently have isn't conference specific -- it seems aimed at
one-to-one chat sessions. Between the two groups, I'd say SIMPLE is the more
appropriate, if you want to drive it through a working group.

As a personal observation, this kind of work has generally received low
participation in SIMPLE, so you might be able to save yourself some process
overhead by publishing it as informational. I would contact the RAI ADs for
advice on the topic, though.

> My question had not only real-time text background. I am equally 
> interested in for example seeing good support for video in chat rooms, 
> where the video entries are not seen just as attachments to the text 
> entry, but are handled with full support for easy recording, entry and 
> display in the chatroom. So, I would appreciate if you could expand 
> the media section a bit with more on planned handling of multimedia
contents.

/a

__________ NOD32 2472 (20070821) Information __________