Subject: [Simple] "isComposing" and such using MSRP

From: "Orit Levin" <[email-masked]>
Date: Thu, 22 Apr 2004 14:55:35 -0700

I agree that it doesn't relate to the "isComposing" draft itself and
consequently to its last call.

It is not totally "orthogonal" because it directly feeds the MSRP
requirements, the MSRP mechanisms. and the probability that isComposing
and MSRP are going to be used together.

I would like to understand from the SIMPLE community why they would they
oppose to defining "a bit" in the SEND message (being set by the end
user) saying respond/don't respond to this message hop-by-hop???

Orit.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, April 22, 2004 1:57 PM
To: Orit Levin
Cc: Miguel Garcia; ext Paul Kyzivat; [email-masked];
[email-masked]
Subject: Re: [Simple] WGLC on isComposing draft

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.

Orit Levin wrote:

> 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
>>
> 
> 

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

---

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

> and MSRP are going to be used together.

My point was the first, that we should not confuse the isComposing wglc 
with this issue. I agree this discussion is relevant to MSRP.

> user) saying respond/don't respond to this message hop-by-hop???

The main problem I have with it is it creates protocol complexity. This 
would require an implementation to understand both transaction models 
(with or without responses) which adds size to the implementation and 
extra conditional processing for each request.

---

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