Subject: RE: [Simple] WGLC on isComposing draft

From: "Orit Levin" <[email-masked]>
Date: Thu, 22 Apr 2004 09:27:45 -0700

The "isComposing" (or the "isTyping" indication in its simplest use)
greatly improves user experience and is widely used today.

This is an example of data that does use bandwidth - for IM it can even
double it. On the other hand - this is a kind of data that you really
don't want any responses or acknowledges to: neither end-to-end nor
hop-by-hop.

I have this example in my "MSRP review" draft. By making hop-by-hop
responses optional per message you immediately reduce the traffic by 1/4
in this case (even if you response hop-by-hop to every user message)!

Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miguel Garcia
Sent: Thursday, April 22, 2004 7:25 AM
To: ext Paul Kyzivat
Cc: [email-masked]; [email-masked]
Subject: Re: [Simple] WGLC on isComposing draft

Well, so let me try to see if understand. We are adding a feature that 
just uses bandwidth, because it represents some information that is able

to change so oftenly that may require to be updated oftenly. 
Furthermore, it is not clear what the receiver can do with such 
information. Will an application at the receiver's indicate "Miguel is 
composing audio" or "Miguel is composing video" ? I don't think that is 
useful.

Mmmm... in these days of wireless devices and saving bandwidth, this 
element seems to go against those principles.

/Miguel

ext Paul Kyzivat wrote:

> 
> 
> Miguel Garcia wrote:
> [snip]
> 
>> Then I question the usage of the "contenttype" element. I can
envision 
>> systems where I can start typing a text message and then drag and
drop 
>> any object (audio or video file). The application will first generate

>> an istyping message with the "contenttype" element presumably set to 
>> text, which is not correct,
> 
> 
> It would be correct at the time it is sent. There is never any
guarantee 
> that the typing will result in a message being sent at all, much less 
> what type.
> 
>  > because I dragged some object later.
> 
> When you drag in an object of some other type, your client will need
to 
> reconsider what the content type is. Then it could send a new 
> isComposing message with the new content type.
> 
>  > I doubt about  the usability of this feature.
> 
> Well, I agree it isn't clear what the recipient would do with the 
> content type information. But other than consuming bandwidth it
doesn't 
> hurt.
> 
>> Furthermore, no application will be able to a priori determine
whether 
>> the user us typing text/plain or text/html, as a user could just add 
>> an html tag afterwords.
> 
> 
> Adding html tags doesn't make the content type html. The sending 
> application will have to decide to set the content type to text/html.
It 
> *might* do that by inspecting the message for html tags, but I would 
> find that surprising. I would imagine that some application control 
> would need to be selected to cause this to happen.
> 
> In any case, as with the drag/drop case above, if/when the application

> decides on a different content type than it previously communicated,
it 
> can send another isComposing with the new content type. But if the 
> decision isn't made until the message is sent then presumably it 
> wouldn't bother. It might not bother in any case.
> 
>     Paul
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Apr 2004 15:56:31 -0500

As the possibility of removing transaction responses is still a 
controversial issue in MSRP, I think we can consider it orthagonal to 
the isComposing draft. That is, we can progress the isComposing draft 
while still arguing that issue for MSRP.

I agree (and commented so in a separate thread.) that we probably don't 
want DSN/MDN reports for isComposing messages.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Apr 2004 15:56:31 -0500