Subject: [Simple] WGLC on isComposing draft

From: [email-masked]
Date: Wed, 21 Apr 2004 15:54:30 +0300

The WG chairs would like to start a Working Group Last Call on the following drafts:

http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt

This WGLC will end on May 5th.

Please send your comments to this mailing list and to the authors. 

If you reviewed the draft and found no issues, please indicate so also on the mailing list. This will help us evaluate the level of review and group consensus.

Thanks,
Hisham

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Apr 2004 15:37:17 -0700

I had a quick read of this and I like it.

One questions on correlating with the message. Say I opened a windows, a is
composing message was sent, call this M1, then I very quickly typed a
message and this got sent, call this M2. Not idle message is sent.

Now the network might deliver M2 ahead of M1. The client receiving these
would display the text from M2 then show that the other side was composing
when really it was not.

This might be a weird corner case not worth solving. It could be solved with
high resolution sender time in both M1 and M2. It could be solved with the
is Composing passing on the message ID of the message that was being
composed. 

I don't care if we choose to ignore this problem but thought it was worth
mentioning. 

On 4/21/04 5:54 AM, "[email-masked]"
<[email-masked]> wrote:

> If you reviewed the draft and found no issues, please indicate so also on the
> mailing list. This will help us evaluate the level of review and group
> consensus.
> 
> Thanks,
> Hisham
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Apr 2004 15:37:17 -0700

---

From: David Oran <[email-masked]>
Date: Thu, 22 Apr 2004 05:11:19 -0400

It would be solved more elegantly by adding causal ordering to CPIM, which 
would also solve about 100 other related problems and allow distributed 
mixing for chat rooms as well.

I suggested this a couple of years ago to Henning and others but we got 
sucked into a long thread about whether the combination of message-id and 
"in-reply-to" could do causal ordering and the inadequacies of message 
threading in email...

Dave.

--On Wednesday, April 21, 2004 3:37 PM -0700 Cullen Jennings 
<[email-masked]> wrote:

> One questions on correlating with the message. Say I opened a windows, a
> is composing message was sent, call this M1, then I very quickly typed a
> This might be a weird corner case not worth solving. It could be solved
> with high resolution sender time in both M1 and M2. It could be solved
> with the is Composing passing on the message ID of the message that was
> being composed.
>
>> If you reviewed the draft and found no issues, please indicate so also
>> on the mailing list. This will help us evaluate the level of review and
>> group consensus.
>>
>> Thanks,
>> Hisham
>>

---

From: David Oran <[email-masked]>
Date: Thu, 22 Apr 2004 05:11:19 -0400

Dave.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 22 Apr 2004 15:21:46 +0300

Henning:

Is there a reason why the schema does no have a maxOccurs attribute set 
to 1 for the "state" and "lastactive" elements, whereas other elements 
have it? I guess there should be just one state element, and if a 
lastactive element is present, there should be just one.

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, because I dragged some object later. I doubt about 
the usability of this feature.

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. A conservative application will notify only "text", 
which as I said before, might not even be true.

On the format of the draft, I believe newcomers will find hard to read 
the document with the current structure. It assumes a lot of previous 
reading. It is nowhere written that the isComposing indication is 
carried in an XML document composed according to the schema defined in 
section 6 (it is just assumed). The Content-Type is never introduced in 
the text, just registered in section 8. The example precedes the schema 
definition (I believe the example should be at the end of the document).

I am also missing the normative statements saying something on the 
following lines:

    An isComposing document is an XML document that MUST be
    well-formed and SHOULD be valid. isComposing documents MUST
    be based on XML 1.0 and MUST be encoded using UTF-8. This
    specification makes use of XML namespaces for identifying isComposing
    documents The namespace URI for elements defined for this purpose is
    a URN, using the namespace identifier 'ietf'. This URN is:

       urn:ietf:params:xml:ns:sip-iscomposing

BR,

    Miguel

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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 22 Apr 2004 15:21:46 +0300

Henning:

BR,

    Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 10:08:30 -0400

Miguel Garcia wrote:
[snip]
> 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.

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 10:24:52 -0400

David Oran wrote:
> It would be solved more elegantly by adding causal ordering to CPIM, 
> which would also solve about 100 other related problems and allow 
> distributed mixing for chat rooms as well.
> 
> sucked into a long thread about whether the combination of message-id 
> and "in-reply-to" could do causal ordering and the inadequacies of 
> message threading in email...

Well, we could resume that discussion. :-)

It would require a more sophisticated client application that is 
typically seen for IM before the application could even generate 
in-reply-to. That might be more complex than the typical IM user would want.

If we want to tackle this problem, then I think there will need to be 
flexible mechanisms that can be used by the client application based on 
what understanding it has of the ordering dependencies.

Its probably best to leave the solution of this problem to later.

Note that this is less of a problem with MSRP because it imposes an 
ordering on messages within the session. One might argue that 
isComposing is only appropriate with session oriented messaging and 
shouldn't be used with page mode.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 22 Apr 2004 17:24:35 +0300

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:

>> 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,
> 
> 
>> the user us typing text/plain or text/html, as a user could just add 
>> an html tag afterwords.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 10:08:30 -0400

Miguel Garcia wrote:
[snip]

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 10:24:52 -0400

Paul

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 22 Apr 2004 17:24:35 +0300

/Miguel

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 11:17:56 -0400

Two quick remarks:

- A UA can decide not to send media type information if ten bytes of 
bandwidth break the bank or if you consider it difficult to generate in 
your particular implementation.

- I don't see why this changes often unless you can't make up your mind 
whether you are composing a video, voice or text message and switch 
between those editors.

- If you are sending a video or audio note, it is likely to be several 
orders of magnitude larger than the indication.

Having the indication is helpful since it provides the receiver some 
warning. Think of an audio message - I can then turn the volume up or 
down before it blasts from my screen.

Henning

Miguel Garcia wrote:

>>> 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.
>>
>> 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 
>> 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.
>>
>>
>>
>> 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.
>>
>> decides on a different content type than it previously communicated, 
>> it can send another isComposing with the new content type. But if the

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 11:17:56 -0400

Two quick remarks:

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 12:09:48 -0400

I like it. I see one new thing that I consider small:

- I'm a little concerned about the idle timeout being as small as 10 
seconds. Personally, I am often inclined to stop and think in the middle 
of composing an IM, which could trigger the idle transition fairly 
often. This might generate more traffic than we might like.

Then there is the ordering issue that Cullen brought up. It is largely 
an issue because of the possibility of closely spaced messages, which in 
turn relates to more traffic. All in all I wonder if we mignt be better 
to recommend that isComposing SHOULD NOT be used with page mode.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 12:09:48 -0400

Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 13:17:54 -0400

> often. This might generate more traffic than we might like.

I'm happy to raise it to 30 seconds. It is a configured interval, so you 
could have a philosopher mode that triggers messages less frequently and 
an ADD mode that indicates idle sooner...

> to recommend that isComposing SHOULD NOT be used with page mode.

I don't see a message from Cullen in the discussion thread, so I'm 
probably missing the point.

End systems can detect, via the CSeq, that an isComposing message 
postdates the actual message.

Also, has somebody measured in real life how common reordering is? 
Packet-level re-ordering is very rare, only affects UDP-bessed messaging 
and unlikely to span more than a few milliseconds. Also, according to 
RFC 3428,

A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a
    given URI if there is a previous out-of-dialog transaction pending
    for the same URI.  Similarly, A UAC SHOULD NOT initiate overlapping
    MESSAGE transactions inside a dialog, and MUST NOT do so unless the
    route set for that dialog uses a congestion-controlled transport at
    every hop.

This further decreases the likelihood of re-ordering at the application 
layer.

In our implementation, we've found isComposing rather useful, even in 
page mode, thus I'm not sure that the drawbacks merit a SHOULD NOT 
restraint.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 13:17:54 -0400

Henning

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Thu, 22 Apr 2004 20:25:06 +0300

> to recommend that isComposing SHOULD NOT be used with page mode.

I agree. I think isComposing is very valuable for session-mode, but have 
  strong doubts about it being useful in page-mode. When I start 
composing a completely new IM, would the recipient first get a 
notification of this? What does it mean if the message is never sent 
(i.e., I decide it was a bad idea and trash it.)

To be useful, I think the isComposing indications need to be sent inside 
an explicit, existing dialogue, and with page-mode there is none, since 
the whole notion of a discussion exists only in the minds of the 
participants.

Cheers,
Aki

>> on the mailing list. This will help us evaluate the level of review 
>> and group consensus.
>>
>> Thanks,
>> Hisham
>>

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Thu, 22 Apr 2004 20:25:06 +0300

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 14:26:56 -0400

> (i.e., I decide it was a bad idea and trash it.)

This can happen in either page or session mode, unless session mode has 
a mechanism that forces uses to press the 'send' key once they have 
started typing.

One could argue that the indication is most useful after receiving a 
message from the party I'm typing to, rather than before sending the 
first message. A simple heuristic (only send indication if within some 
number of minutes since receiving a message from the other party) would 
seem sufficient, but doesn't need standardizing since it's a UI issue. 
It may be worth hinting at this, however.

I don't think the session aspect matters, since the lower-layer sessions 
could last for days and weeks without activity. What matters here is the 
'human' session, i.e., the notion that I'm responding to an earlier 
comment and that it avoids the equivalent of double-talking to have this 
indication available.

> the whole notion of a discussion exists only in the minds of the 

I don't see how this follows.

---

From: "Vikas Tandon" <[email-masked]>
Date: Fri, 23 Apr 2004 00:05:54 +0530

I too agree  with - no need for isComposing in page mode.
Regards,
-Vikas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Niemi Aki (Nokia-M/Espoo)
Sent: jeudi 22 avril 2004 22:55
To: ext Paul Kyzivat
Cc: [email-masked]; [email-masked]
Subject: Re: [Simple] WGLC on isComposing draft

Cheers,
Aki

>> Please send your comments to this mailing list and to the authors. If

>> you reviewed the draft and found no issues, please indicate so also 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/simple
>>
> 
>

---

From: David Oran <[email-masked]>
Date: Thu, 22 Apr 2004 14:40:17 -0400

--On Thursday, April 22, 2004 8:25 PM +0300 "Niemi Aki (Nokia-M/Espoo)" 
<[email-masked]> wrote:

> strong doubts about it being useful in page-mode. When I start composing
> a completely new IM, would the recipient first get a notification of
> this? What does it mean if the message is never sent (i.e., I decide it
> was a bad idea and trash it.)
>
Hmmm, I have an IM client which pops an incoming IM window as soon as the 
isComposing comes in. I can really freak people out by quickly typing them 
a message ad send it back. They think I'm clairvoyant!

Is this a really useful feature? Beats me, but why prohibit something which 
does no damage?

> the whole notion of a discussion exists only in the minds of the
Depends on your attitude about what's useful...

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 14:26:56 -0400

---

From: "Vikas Tandon" <[email-masked]>
Date: Fri, 23 Apr 2004 00:05:54 +0530

-----Original Message-----

Cheers,
Aki

---

From: David Oran <[email-masked]>
Date: Thu, 22 Apr 2004 14:40:17 -0400

---

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

Would the expiration of the "active" state cause this problem to self-heal?

---

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

Miguel Garcia wrote:

[...]

> the usability of this feature.

I think contenttype can be useful, as long as the receiver knows it is 
just a hint. This is true of is-Composing in general, as I might type 
something into an external editor and paste it into a message.

But if my messaging system happens to have sound recording features 
built in, and I use them instead of adding a sound attachment, it might 
be useful.

[...]

---

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

Henning Schulzrinne wrote:

>> seconds. Personally, I am often inclined to stop and think in the 
>> middle of composing an IM, which could trigger the idle transition 
>> fairly often. This might generate more traffic than we might like.
> 
> 

Now that you mention it, is there a conflict between saying this is a 
"configured interval" and saying it "SHOULD be X seconds"? Does that 
simply mean it should be X if the user chooses not to configure anything?

[...]

---

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

Niemi Aki (Nokia-M/Espoo) wrote:

>> an issue because of the possibility of closely spaced messages, which 
>> in turn relates to more traffic. All in all I wonder if we mignt be 
>> better to recommend that isComposing SHOULD NOT be used with page mode.
> 
> 

As I commented in a separate thread, endpoints using page-mode may still 
have a local idea of a "virtual confersation". isComposing may be useful 
in that context. But I think we may need more guidelines for using it in 
page-mode, if we support that at all.

How is the issue of the message not being sent differ for page-mode and 
session-mode?

> the whole notion of a discussion exists only in the minds of the 

But the notion _does_ exist, even if only in the minds. I have seen SMS 
clients that give a conversational user experience. If you can do it in 
SMS, you should be able to do it with page-mode IM.

>>> If you reviewed the draft and found no issues, please indicate so 
>>> also on the mailing list. This will help us evaluate the level of 
>>> review and group consensus.
>>>
>>> Thanks,
>>> Hisham
>>>

---

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

I like this in general.

Some minor comments and questions:

Am I correct in assuming you never need to refresh idle state?

The idea of the idle timeout seems pretty text centric. Would you expect 
the same behavior if they were recording audio? Maybe you would go to 
idle when they pressed stop or pause, rather than when a timeout occurred.

Nit: "Recipients of messages implementing this specification MUST treat 
state tokens other than "idle" and "active" as "idle"." You mean 
"unknown" state tokens, right?

Do we have enough guidelines for using with page-mode? It does not seem 
to make sense to send unsolicited is-composing messages, but it might 
make sense to create sort of a pseudo-session when one receives a 
pager-mode message, then send these within that context. By 
pseudo-session, I mean having the endpoints keep track of a 
conversation, event though the protocol may not be providing explicit 
session info.

Do you have thoughts about the interaction between is-composing and 
DSN/MDN? Would you ever want a delivery report for an is-composing message?

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 16:52:12 -0400

> simply mean it should be X if the user chooses not to configure anything?

Yes; I'll clarify.

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Fri, 23 Apr 2004 00:42:30 +0300

ext David Oran wrote:
> Hmmm, I have an IM client which pops an incoming IM window as soon as 
> the isComposing comes in. I can really freak people out by quickly 
> typing them a message ad send it back. They think I'm clairvoyant!
> 
> Is this a really useful feature? Beats me, but why prohibit something 
> which does no damage?

That's just it, it might do damage, because as you point out, the sender 
isn't aware that information about her messaging activities is leaking 
out before the send-button is even pushed.

Cheers,
Aki

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Fri, 23 Apr 2004 00:45:39 +0300

ext Ben Campbell wrote:
>> I agree. I think isComposing is very valuable for session-mode, but 
>> have  strong doubts about it being useful in page-mode. When I start 

In session-mode, the window that pops up can be kept up even if an 
isComposing never results in a message actually being received. The SIP 
BYE marks the end of the session very clearly.

For page-mode, it isn't as easy to determine when the UA should stop 
waiting for an IM after an isComposing was received.

There are also privacy issues about sending an isComposing before the 
actual IM.

But I agree with you that proper guidelines might solve these issues.

>> To be useful, I think the isComposing indications need to be sent 
>> inside an explicit, existing dialogue, and with page-mode there is 
>> none, since the whole notion of a discussion exists only in the minds 
>> of the participants.
>>
> 

Oh, by all means. I'm not arguing against having page-mode give a 
conversational user experience. It definitely should, but it doesn't 
necessarily require isComposing just like SMS doesn't.

Cheers,
Aki

---

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

---

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

Miguel Garcia wrote:

[...]

[...]

---

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

[...]

---

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

---

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

I like this in general.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 16:52:12 -0400

Yes; I'll clarify.

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Fri, 23 Apr 2004 00:42:30 +0300

Cheers,
Aki

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Fri, 23 Apr 2004 00:45:39 +0300

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 18:36:06 -0400

> conversation, event though the protocol may not be providing explicit 

I think this is just a glimse of a bigger iceburg lurking on the horizon:

I think there we are eventually going to have to provide some sort of 
guidelines for when to use page mode, when to use session mode, and when 
to transition between them. Whe we start to talk about pseudo-sessions 
that tie together page mode messages we are heading in that direction.

	Paul

---

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

Paul Kyzivat wrote:

> 
> 
> Ben Campbell wrote:
> 
>>
>> Do we have enough guidelines for using with page-mode? It does not 
>> seem to make sense to send unsolicited is-composing messages, but it 
>> might make sense to create sort of a pseudo-session when one receives 
>> a pager-mode message, then send these within that context. By 

Agreed. We have a lot of guidelines we need to write, and not just for 
this. The last SIPIT made it clear that we need to get the SIMPLE 
architecture work moving again. This is one item that probably should be 
addressed there.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2004 18:36:06 -0400

Paul

---

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 22:27:23 -0400

> waiting for an IM after an isComposing was received.

There wouldn't really be waiting. At least in our implementation, you 
just see a message "Alice is composing a message" or something like 
that, which disappears after a while.

> There are also privacy issues about sending an isComposing before the 

I can see this for the first IM in page mode, but otherwise I fail to 
see the difference between the two modes.

> necessarily require isComposing just like SMS doesn't.

You can certainly do page mode (or session mode) without isComposing, 
but I find the user experience much better with it. In both scenarios, 
it avoids 'double-talking', in that the sender of the last message is 
not sure if the other side is responding, if the conversation snippet is 
over or if the other side expects more.

As a practical matter, page-mode style systems (like MSN messenger) have 
the feature, and it doesn't seem to have caused a problem.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 22:35:51 -0400

> page-mode, if we support that at all.

I suppose this comes back to how much user interface guidance we want to 
provide. None of this is necessary for interoperability - if I want to 
send isComposing before the first bit of text, this will work just fine 
and there may even be scenarios where this makes sense. For example, for 
audio and video messages, a bit of warning before the message comes out 
of the speaker wouldn't hurt.

I think we should not assume that MSRP sessions correspond to human 
conversations. IM conversations seem to come in brief spurts, with 
pauses in between, but no formal farewell or 'ringing' (beyond, maybe, 
an initial Hi!).

I would imagine that the lower-layer sessions will often stay up 
indefinitely between co-workers, so that a sudden isComposing after two 
days of silence is not substantially different, from a user experience 
and privacy perspective, just because there is an on-going SIP session 
underneath that is largely invisible to the user. If a session has to be 
manually 'picked up' at the receiver, users aren't likely to tear them 
down. If they wanted a phone call experience, they would place a call. 
If the session is automatically accepted, the user experience doesn't 
differ from page mode.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 22:27:23 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 2004 22:35:51 -0400

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 23 Apr 2004 10:24:56 +0300

> your particular implementation.

This is not about difficulty in an implementation, and is not about the 
10 bytes that the contentype itself adds. Is about resource utilization 
when you consider the whole picture, which is: if an implementation uses 
the contenttype to give a hint during the composition of a message, 
whenever the contenttype changes, the implemenation has to send a new 
update with the new contentype. This is more than 10 bytes, specially if 
used in page mode.

Having said that, fortunately we are discussino a corner case that will 
not happen typically.

> whether you are composing a video, voice or text message and switch 

The case I have in my mind is when you start composing a text message, 
and then start recording an audio or video file that is embedded in the 
message.

> orders of magnitude larger than the indication.

Sure, no doubt.

> down before it blasts from my screen.

Ok, sounds reasonable.

    Miguel

>> just uses bandwidth, because it represents some information that is 
>> able to change so oftenly that may require to be updated oftenly. 
>> composing audio" or "Miguel is composing video" ? I don't think that 
>> is useful.
>>
>>> 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
>>>
>>

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 23 Apr 2004 10:24:56 +0300

Sure, no doubt.

Ok, sounds reasonable.

    Miguel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Apr 2004 09:16:00 -0400

> Having said that, fortunately we are discussino a corner case that will 

I'd agree - I just can't see as being close to common. After all, if 
you're composing an elaborate message, IM doesn't seem like the typical 
venue for it. I see audio and video messages primarily for devices that 
have limited text capabilities or situations where keyboarding is 
inappropriate (say, while driving), not as a way to create a home movie 
or multimedia documentary.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Apr 2004 09:16:00 -0400

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Apr 2004 09:55:06 -0700

> shouldn't be used with page mode.

Once we allow both small and large message to go over MSRP, We loose this
ordering of messages property. This should be in the next draft.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Apr 2004 09:57:08 -0700

Yes it would after some period of time but it's still sort of ugly.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Apr 2004 09:55:06 -0700

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Apr 2004 09:57:08 -0700

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2004 15:11:47 -0400

> ordering of messages property. This should be in the next draft. 

Hmm. Good point.

Its not really large and small that is the issue - its fragmentation, right?

There might still be well defined ordering even when there is 
fragmentation, if we make clear whether the ordering is based on receipt 
of the first fragment or the last. (I think the last makes most sense.)

So if the ordering of fragments was preserved end to end then it 
wouldn't be a problem.

BUT, given that we intend to permit fragmentation and reassembly by 
servers along the path, I think it would be difficult, and possibly 
undesirable, to preserve ordering.

This is an issue that goes far beyond isComposing. If A sends a number 
of messages to B, I think we must at least arrange so that both A and B 
agree on the order that those messages are to be displayed.

(That is a much weaker condition than having them both agree on the 
order in which the messages from A to B *and* the messages from B to A 
are interleaved.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2004 15:11:47 -0400

Hmm. Good point.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2004 17:45:01 -0400

Replying to myself. :-(

I thought about this a bit more, and now I think it is ok to require 
that a fragmentation algorithm preserve the ordering of the last 
fragment of messages. This in turn means that ordering of messages can 
be defined by the order in which their last fragment is sent/received.

This means that the sender of a long message can chose to fragment it, 
and insert a short message in the middle if it likes, with the 
understanding, by both parties, that it logically preceeds the large 
message.

A server in the middle can fragment and reassemble messages. It can even 
buffer a partial message that it is trying to reassemble while letting a 
smaller one that is interspersed flow thru. It can also hold a large 
message and trickle it out in fragments in order to share bandwidth with 
other streams. The only constraint is that when the last fragment of a 
message is received, it must be passed on before the last fragment of 
another message from the same source stream. This incurs no particular 
extra inefficiency that I can see.

Given a rule like this I think we can assume that an MSRP stream defines 
a total ordering on the messages that traverse it.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2004 17:45:01 -0400

Replying to myself. :-(

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Apr 2004 18:53:50 -0400

> order in which the messages from A to B *and* the messages from B to A 

Would CSeq in MESSAGE allow this to happen without much fuss?

(As I said before, the practical likelihood of reordering seems 
extremely low, even without such measures, given the NOTIFY 
window-size=1 constraint.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Apr 2004 18:53:50 -0400

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2004 22:46:47 -0400

Henning Schulzrinne wrote:
>> of messages to B, I think we must at least arrange so that both A and 
>> B agree on the order that those messages are to be displayed.
>>

CSeq is only relevant within a dialog, and we aren't supposed to be 
sending MESSAGEs within dialogs.

In any case, I was more concerned with Cullen's suggestion that messages 
might get reordered within an MSRP stream.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2004 22:46:47 -0400

Paul

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Mon, 26 Apr 2004 15:42:35 +0300

inline.

ext Henning Schulzrinne wrote:
>> As I commented in a separate thread, endpoints using page-mode may 
>> still have a local idea of a "virtual confersation". isComposing may 
>> be useful in that context. But I think we may need more guidelines for 
>> using it in page-mode, if we support that at all.
> 
> 

I guess my main concern is the potential information leak involved in a 
forward notice isComposing indication. Otherwise, I'm happy to use this 
also for page-mode. As long as we're clear that in page-mode it is to 
avoid users from talking past each other, and not to set up 
"pseudo-sessions".

Having said that though, I think the current draft is clear as it is 
already. I'd propose a couple of sentences in Security Considerations 
explaining the potential privacy issues in an isComposing being received 
before/without the actual "first" message of a conversation being received.

Perhaps something like:

"There are potential privacy issues in sending isComposing indications 
before an actual conversation has been established between the 
communicating users. It is RECOMMENDED that isComposing indications in 
page-mode are only sent when a message is being composed as a reply to 
an earlier message."

Additionally, you could say that implementations are free to use 
whatever mechanisms to determine when a message is in-reply-to a 
previous received message.

> pauses in between, but no formal farewell or 'ringing' (beyond, maybe, 

Similarly we should not assume MSRP sesions don't correspond to human 
conversations. For example, in conferencing the MSRP session very often 
would correspond to a human conversation, namely participation in a chat 
room.

> If the session is automatically accepted, the user experience doesn't 

I agree that session-mode with auto-answer isn't that different (from 
user's point of view) from page-mode. But I don't think it's a good idea 
to build the IM application assuming there is always auto-answer.

The caller/callee must also handle a case where a session mode call 
requires the same interaction from the user (perhaps something similar 
to talk in Unix), as a normal voice call. This is as reasonable an 
implementation of session-mode as is the auto-answer one.

Cheers,
Aki

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Mon, 26 Apr 2004 15:42:35 +0300

inline.

Perhaps something like:

Cheers,
Aki

---

From: Ben Campbell <[email-masked]>
Date: Mon, 26 Apr 2004 08:26:08 -0500

Niemi Aki (Nokia-M/Espoo) wrote:

>>> be useful in that context. But I think we may need more guidelines 
>>> for using it in page-mode, if we support that at all.
>>
>>
>>
>> I suppose this comes back to how much user interface guidance we want 
>> to provide. None of this is necessary for interoperability - if I want 
>> to send isComposing before the first bit of text, this will work just 
>> fine and there may even be scenarios where this makes sense. For 
>> example, for audio and video messages, a bit of warning before the 
>> message comes out of the speaker wouldn't hurt.
> 
> 

I agree here. I did not mean to imply that isComposing would set up such 
a pseudo-session, only that if you used this sort of user metaphor, 
isComposing could be useful.

> page-mode are only sent when a message is being composed as a reply to 

I agree.

>> indefinitely between co-workers, so that a sudden isComposing after 
>> two days of silence is not substantially different, from a user 
>> experience and privacy perspective, just because there is an on-going 
>> SIP session underneath that is largely invisible to the user. If a 
>> session has to be manually 'picked up' at the receiver, users aren't 
>> likely to tear them down. If they wanted a phone call experience, they 
>> would place a call. If the session is automatically accepted, the user 
>> experience doesn't differ from page mode.
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 26 Apr 2004 08:26:08 -0500

I agree.